Hello All,
Has anyone successfully enrolled an Ubuntu 22 client into an AlmaLinux 9 IdM or Rocky Linux 9 IdM domain in a trust with AD _and_ managed to have consistently fast and reliable logins into that Ubuntu 22 client with AD users? I sure haven't.
I have been smashing my head into a wall trying to get stupid Ubuntu 22 to work. After enabling debug_level 9, I managed to figure out that my test client was missing the krb5-pkinit package so I installed that. I also noticed errors in sssd_pac.log about the backend being offline. I eventually figured out that I needed to add "services = pac" to the client's sssd.conf. Note: I had removed the services line because in Ubuntu 22, the various services are instead started as needed via their sockets (e.g. sssd-autofs.socket, sssd-nss.socket, etc.). If you leave them defined in the services line, you get tons of errors during system startup.
I've resolved those errors, but I'm still seeing extremely slow logins when it works. Usually, the login just fails. However, if I login as root and lookup AD users, they are found and returned to the terminal.
The sssd.conf from the client running sssd 2.6.3 is below. If anyone has any pointers, please send them over. I wish I didn't have to get Ubuntu 22 clients working with freeipa, but I do. :(
[domain/idm.domain.com] id_provider = ipa ipa_server = _srv_, p1idma01.idm.domain.com ipa_domain = idm.domain.com ipa_hostname = u22test.idm.domain.com auth_provider = ipa chpass_provider = ipa access_provider = ipa cache_credentials = True ldap_tls_cacert = /etc/ipa/ca.crt ldap_deref_threshold = 0 krb5_store_password_if_offline = True selinux_provider = none sudo_provider = ipa autofs_provider = ipa subdomains_provider = ipa session_provider = ipa hostid_provider = ipa ipa_automount_location = yow debug_level = 9
[domain/idm.domain.com/corp.ad.domain.com] ad_site = ottawa
[sssd] #services = nss, pam, ssh, sudo, autofs services = pac domains = idm.domain.com debug_level = 9
[nss] default_shell = /bin/bash homedir_substring = /home debug_level = 9
[pam] debug_level = 9
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
[session_recording]
Hi,
No probs in Ubuntu 22.04.1 thats for shore. Ever tired with real thing?
SH
On 25/08/2022 07:41, Ranbir via FreeIPA-users wrote:
Hello All,
Has anyone successfully enrolled an Ubuntu 22 client into an AlmaLinux 9 IdM or Rocky Linux 9 IdM domain in a trust with AD _and_ managed to have consistently fast and reliable logins into that Ubuntu 22 client with AD users? I sure haven't.
I have been smashing my head into a wall trying to get stupid Ubuntu 22 to work. After enabling debug_level 9, I managed to figure out that my test client was missing the krb5-pkinit package so I installed that. I also noticed errors in sssd_pac.log about the backend being offline. I eventually figured out that I needed to add "services = pac" to the client's sssd.conf. Note: I had removed the services line because in Ubuntu 22, the various services are instead started as needed via their sockets (e.g. sssd-autofs.socket, sssd-nss.socket, etc.). If you leave them defined in the services line, you get tons of errors during system startup.
I've resolved those errors, but I'm still seeing extremely slow logins when it works. Usually, the login just fails. However, if I login as root and lookup AD users, they are found and returned to the terminal.
The sssd.conf from the client running sssd 2.6.3 is below. If anyone has any pointers, please send them over. I wish I didn't have to get Ubuntu 22 clients working with freeipa, but I do. :(
[domain/idm.domain.com] id_provider = ipa ipa_server = _srv_, p1idma01.idm.domain.com ipa_domain = idm.domain.com ipa_hostname = u22test.idm.domain.com auth_provider = ipa chpass_provider = ipa access_provider = ipa cache_credentials = True ldap_tls_cacert = /etc/ipa/ca.crt ldap_deref_threshold = 0 krb5_store_password_if_offline = True selinux_provider = none sudo_provider = ipa autofs_provider = ipa subdomains_provider = ipa session_provider = ipa hostid_provider = ipa ipa_automount_location = yow debug_level = 9
[domain/idm.domain.com/corp.ad.domain.com] ad_site = ottawa
[sssd] #services = nss, pam, ssh, sudo, autofs services = pac domains = idm.domain.com debug_level = 9
[nss] default_shell = /bin/bash homedir_substring = /home debug_level = 9
[pam] debug_level = 9
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
[session_recording]
'TRIED' vs 'TIRED' I do not do this kind of spelling mistakes. That is the reason nothing works on your system.
SH
On 25/08/2022 09:42, Sami Hulkko via FreeIPA-users wrote:
Hi,
No probs in Ubuntu 22.04.1 thats for shore. Ever tired with real thing?
SH
On 25/08/2022 07:41, Ranbir via FreeIPA-users wrote:
Hello All,
Has anyone successfully enrolled an Ubuntu 22 client into an AlmaLinux 9 IdM or Rocky Linux 9 IdM domain in a trust with AD _and_ managed to have consistently fast and reliable logins into that Ubuntu 22 client with AD users? I sure haven't.
I have been smashing my head into a wall trying to get stupid Ubuntu 22 to work. After enabling debug_level 9, I managed to figure out that my test client was missing the krb5-pkinit package so I installed that. I also noticed errors in sssd_pac.log about the backend being offline. I eventually figured out that I needed to add "services = pac" to the client's sssd.conf. Note: I had removed the services line because in Ubuntu 22, the various services are instead started as needed via their sockets (e.g. sssd-autofs.socket, sssd-nss.socket, etc.). If you leave them defined in the services line, you get tons of errors during system startup.
I've resolved those errors, but I'm still seeing extremely slow logins when it works. Usually, the login just fails. However, if I login as root and lookup AD users, they are found and returned to the terminal.
The sssd.conf from the client running sssd 2.6.3 is below. If anyone has any pointers, please send them over. I wish I didn't have to get Ubuntu 22 clients working with freeipa, but I do. :(
[domain/idm.domain.com] id_provider = ipa ipa_server = _srv_, p1idma01.idm.domain.com ipa_domain = idm.domain.com ipa_hostname = u22test.idm.domain.com auth_provider = ipa chpass_provider = ipa access_provider = ipa cache_credentials = True ldap_tls_cacert = /etc/ipa/ca.crt ldap_deref_threshold = 0 krb5_store_password_if_offline = True selinux_provider = none sudo_provider = ipa autofs_provider = ipa subdomains_provider = ipa session_provider = ipa hostid_provider = ipa ipa_automount_location = yow debug_level = 9
[domain/idm.domain.com/corp.ad.domain.com] ad_site = ottawa
[sssd] #services = nss, pam, ssh, sudo, autofs services = pac domains = idm.domain.com debug_level = 9
[nss] default_shell = /bin/bash homedir_substring = /home debug_level = 9
[pam] debug_level = 9
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
[session_recording]
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, 2022-08-25 at 09:42 +0300, Sami Hulkko via FreeIPA-users wrote:
No probs in Ubuntu 22.04.1 thats for shore.
Well, that's encouraging.
What does your sssd.conf look like? Which version of freeipa are you using? Also, is your freeipa domain in a trust with AD?
My CentOS, Rocky Linux and AlmaLinux clients all work as I expect them to (as long as I don't use ID Views).
Ever tired with real thing?
I don't understand what you mean. Are you asking if I've used IdM in RHEL?
Ranbir via FreeIPA-users wrote:
Hello All,
Has anyone successfully enrolled an Ubuntu 22 client into an AlmaLinux 9 IdM or Rocky Linux 9 IdM domain in a trust with AD _and_ managed to have consistently fast and reliable logins into that Ubuntu 22 client with AD users? I sure haven't.
I have been smashing my head into a wall trying to get stupid Ubuntu 22 to work. After enabling debug_level 9, I managed to figure out that my test client was missing the krb5-pkinit package so I installed that. I also noticed errors in sssd_pac.log about the backend being offline. I eventually figured out that I needed to add "services = pac" to the client's sssd.conf. Note: I had removed the services line because in Ubuntu 22, the various services are instead started as needed via their sockets (e.g. sssd-autofs.socket, sssd-nss.socket, etc.). If you leave them defined in the services line, you get tons of errors during system startup.
I've resolved those errors, but I'm still seeing extremely slow logins when it works. Usually, the login just fails. However, if I login as root and lookup AD users, they are found and returned to the terminal.
The sssd.conf from the client running sssd 2.6.3 is below. If anyone has any pointers, please send them over. I wish I didn't have to get Ubuntu 22 clients working with freeipa, but I do. :(
[domain/idm.domain.com] id_provider = ipa ipa_server = _srv_, p1idma01.idm.domain.com ipa_domain = idm.domain.com ipa_hostname = u22test.idm.domain.com auth_provider = ipa chpass_provider = ipa access_provider = ipa cache_credentials = True ldap_tls_cacert = /etc/ipa/ca.crt ldap_deref_threshold = 0 krb5_store_password_if_offline = True selinux_provider = none sudo_provider = ipa autofs_provider = ipa subdomains_provider = ipa session_provider = ipa hostid_provider = ipa ipa_automount_location = yow debug_level = 9
[domain/idm.domain.com/corp.ad.domain.com] ad_site = ottawa
[sssd] #services = nss, pam, ssh, sudo, autofs services = pac domains = idm.domain.com debug_level = 9
[nss] default_shell = /bin/bash homedir_substring = /home debug_level = 9
[pam] debug_level = 9
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
[session_recording]
I'd suggest you open Ubuntu bugs on the missing dependency and services issue.
There is also an sssd-users list you might try for help. Here or there logs are going to be necessary to troubleshoot.
rob
On Thu, 2022-08-25 at 09:35 -0400, Rob Crittenden wrote:
I'd suggest you open Ubuntu bugs on the missing dependency and services issue.
I've already found bug entries about the services problem; I don't recall if they were closed. But, considering I'm seeing the same issue as described in the bug reports, I'm assuming the problem hasn't been fixed.
There is also an sssd-users list you might try for help. Here or there logs are going to be necessary to troubleshoot.
I'll try the sssd-users list. For this list, which logs should I provide?
On 25/08/2022 05:41, Ranbir via FreeIPA-users wrote:
After enabling debug_level 9, I managed to figure out that my test client was missing the krb5-pkinit package so I installed that.
I thought krb5-pkinit is only needed if you want to use PKINIT? sssd uses the host/$HOSTNAME principal to establish a FAST channel for pre-authentication, so I don't see how krb5-pkinit affects things?
also noticed errors in sssd_pac.log about the backend being offline. I eventually figured out that I needed to add "services = pac" to the client's sssd.conf. Note: I had removed the services line because in Ubuntu 22, the various services are instead started as needed via their sockets (e.g. sssd-autofs.socket, sssd-nss.socket, etc.). If you leave them defined in the services line, you get tons of errors during system startup.
I thought 'services = pac' was the default in Debian & that Ubuntu would inherit this?
I did try socket-activating the pac responder, but I found that sssd would always launch its own pac responder in addition to the socket-activated one, so sssd-pac.socket is left disabled by default.
I've resolved those errors, but I'm still seeing extremely slow logins when it works. Usually, the login just fails. However, if I login as root and lookup AD users, they are found and returned to the terminal.
This could be caused by Ubuntu's extremely annoying login script that looks up every member of every AD group that you're a member of when you log in.
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1863894
Apply my modification to my script or just disable it and see if your logins are any quicker.
On Thu, 2022-08-25 at 18:44 +0100, Sam Morris via FreeIPA-users wrote:
I thought krb5-pkinit is only needed if you want to use PKINIT? sssd uses the host/$HOSTNAME principal to establish a FAST channel for pre-authentication, so I don't see how krb5-pkinit affects things?
My goal there was to just get rid of the error. We're not using smartcards so it didn't really matter that an error for the missing shared library was recorded. It's hard to tell when an error in the log is actually just informational or causing other real problems.
I thought 'services = pac' was the default in Debian & that Ubuntu would inherit this?
On a fresh Ubuntu 22 host after installing freeipa-client and enrolling it into freeipa, the services line that gets added to sssd.conf contains more than just "pac". That in and of itself is a problem in Ubuntu because the sockets for the responders are enabled by default. After figuring out why I was seeing startup errors in the journal, I nuked the whole line. But, that broke the pac responder and I didn't catch that until a couple of days ago.
I did try socket-activating the pac responder, but I found that sssd would always launch its own pac responder in addition to the socket-activated one, so sssd-pac.socket is left disabled by default.
Yes, that's what I ended up doing a couple of days ago.
This could be caused by Ubuntu's extremely annoying login script that looks up every member of every AD group that you're a member of when you log in.
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1863894
Apply my modification to my script or just disable it and see if your logins are any quicker.
Ah, that explains why I was seeing in the logs every single user of every group being looked up. I was trying to figure out why Ubuntu was doing that. I surmised it had to do with some customization in Ubuntu's login procedure. I just didn't know where to look.
Thank you for that tip. I'll give your changes a shot.
On 25/08/2022 19:06, Ranbir via FreeIPA-users wrote:
On Thu, 2022-08-25 at 18:44 +0100, Sam Morris via FreeIPA-users wrote:
I thought krb5-pkinit is only needed if you want to use PKINIT? sssd uses the host/$HOSTNAME principal to establish a FAST channel for pre-authentication, so I don't see how krb5-pkinit affects things?
My goal there was to just get rid of the error. We're not using smartcards so it didn't really matter that an error for the missing shared library was recorded. It's hard to tell when an error in the log is actually just informational or causing other real problems.
I thought 'services = pac' was the default in Debian & that Ubuntu would inherit this?
On a fresh Ubuntu 22 host after installing freeipa-client and enrolling it into freeipa, the services line that gets added to sssd.conf contains more than just "pac". That in and of itself is a problem in Ubuntu because the sockets for the responders are enabled by default. After figuring out why I was seeing startup errors in the journal, I nuked the whole line. But, that broke the pac responder and I didn't catch that until a couple of days ago.
Interesting. After installing sssd on a fresh system there isn't an /etc/sssd/sssd.conf file. I guess ipa-client-install ultimately needs to make sure it's not enabling services that are already enabled via socket activation. Then again I don't know if having duplicates of these responders is actaully causing a problem or whether it just results in a bit of wasted memory and extra log messages.
I did try socket-activating the pac responder, but I found that sssd would always launch its own pac responder in addition to the socket-activated one, so sssd-pac.socket is left disabled by default.
Yes, that's what I ended up doing a couple of days ago.
This could be caused by Ubuntu's extremely annoying login script that looks up every member of every AD group that you're a member of when you log in.
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1863894
Apply my modification to my script or just disable it and see if your logins are any quicker.
Ah, that explains why I was seeing in the logs every single user of every group being looked up. I was trying to figure out why Ubuntu was doing that. I surmised it had to do with some customization in Ubuntu's login procedure. I just didn't know where to look.
Thank you for that tip. I'll give your changes a shot.
No problem. Ubuntu's login script is really idiotic and caused no end of pain for me & my users. But it seems no one is reading the bug reports...
You'll also want to tell sssd to not include group members when group info is looking up--that tweak also makes a huge difference the 1st time a user logs in. You want:
ignore_group_members = true subdomain_inherit = ignore_group_members
See https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ for more info.
On Thu, 2022-08-25 at 19:41 +0100, Sam Morris via FreeIPA-users wrote:
Interesting. After installing sssd on a fresh system there isn't an /etc/sssd/sssd.conf file. I guess ipa-client-install ultimately needs to make sure it's not enabling services that are already enabled via socket activation. Then again I don't know if having duplicates of these responders is actaully causing a problem or whether it just results in a bit of wasted memory and extra log messages.
I think it actually breaks sssd and prevents it or the responders from working properly. If I'm bored, I'll have to try it out again.
No problem. Ubuntu's login script is really idiotic and caused no end of pain for me & my users. But it seems no one is reading the bug reports...
It worked for me. This is awesome. Thanks again.
I took it to the next step and applied an ID View for an AD user to change the user's UID and GID. The user could no longer login and that group enumeration problem popped up again: sssd_idm.domain.com.log was spitting out groups and group members like it was before the change to /etc/bash.bashrc. I couldn't even look up the user anymore. I had to stop sssd, delete everything in /var/lib/sss/db/, unapply the ID View on the host and start sssd to get logins and user lookups working again. :/
You'll also want to tell sssd to not include group members when group info is looking up--that tweak also makes a huge difference the 1st time a user logs in. You want:
ignore_group_members = true subdomain_inherit = ignore_group_members
I did that on the masters. I believe it's helping, but the test Ubuntu 22 client is still slower than a CentOS 7 server I converted from NIS auth to a freeipa client.
BTW, I have 26 masters spread out all over the planet. I'm using ad sites and ipa locations to make sure clients aren't reaching out to sites that are far away. I don't know for sure if this setup is causing any issues, though so far it seems to be OK.
freeipa-users@lists.fedorahosted.org
-
Ranbir -
Rob Crittenden -
Sam Morris -
Sami Hulkko