Slow local user login when SSSD is configured and there is no connectivity to global catalog server

Posted by eidercollider@reddit | linuxadmin | View on Reddit | 5 comments

Hi, I have SSSD configured on Ubuntu 24.04 (via realm join) This works fine However, during testing I noticed that in the situation where the system lacked connectivity to the global catalog server (domain controller, tcp/3268) then attempting to log in with a local account was extremely slow (10s+)

This felt like it was attempting to query the username on the network first before timing out and falling back to checking locally

I've checked /etc/nsswitch.conf and it's as expected:

passwd, group, shadow: files systemd sss gshadow: files systemd

Does anyone know where this delay might be coming from?

I am not using fully qualified names for logins so that may be part of the problem...

Many thanks!

[-]

dodexahedron@reddit

If you're using sssd with ad, the no-nonsense and most automatic means of joining the system and having it do things that need to be done is adcli join yourdomain.tld

realm join is only part of the process (it does that part for you though).

When did this start happening? This month?
How long has this system been joined?
Is the kerberos keytab up to date?
Did it reset its machine account password when it was supposed to according to domain controller policy?
Are you using DNS and no IP addresses for all things related to kerberos, cifs/smb, and LDAP?
What does the journal say?
Have you turned up sssd's logging and taken a look at what it tells you? If not, use sssctl to do that without having to restart sssd.
Have you checked logs on the domain controller around the time of the login attempts?
Is every root CA and every CA that issued the certs being used by the netlogon, server, and kdc services on every domain controller trusted on this machine?
Are you using RC4 TGT or setvice ticket encryption types?

[-]

eidercollider@reddit (OP)

Thanks! I was under the impression that realm join would invoke adcli join so I've only been using that, and then making some minor tweaks to the sssd.conf.

It's a newly deployed machine and I only noticed the issue becausae it was deployed in a network that didn't have tcp/3268 connectivity to the DCs. This caused rather odd behaviour in which I was able to join the domain, but it couldn't retrieve group membership for accounts.

Allowing tcp/3268 makes it work just fine, so I don't think the issue is the kerberos config.

What I'm trying to work out is why it seemed to be checking the network server before the local passwd file for a specific username, when the nss config implies that it should check the file first!

I'll try and recreate the situation and check the logs you mention, but as the issue only manifests when there isn't full connectivity to the domain controller, I'm not sure how much use it will be...

[-]

dodexahedron@reddit

What does pam say?

Also note: Auth goes pam -> nss -> sssd -> AD, and is done via kerberos for the actual auth and normal ldap first (for identity) from sssd to AD. GC is a fallback, used after things like bad password or lockout. It switches to GC then to make sure it isn't just the result of a change or something like that, by ensuring it has the most up to date answer it can get.
UDP and TCP 389 for that (it will attempt to use starttls on tcp 389).

Windows clients will also explicitly try the PDCe for the domain as a last resort for some scenarios, but that also happens over normal ldap. I don't know if the sssd-ad module mirrors that behavior or not.

[-]

eidercollider@reddit (OP)

Thank you very much, I didn't realise the auth chain went to pam first! I have a lot to learn in this area. I'll check logs and firewall settings carefully.