Hi,
I recently encountered issues where logins on Linux clients using SSSD and the AD provider, pointed directly to an AD server were randomly slow. Randomly meaning, some clients experienced no slowness at all, other clients consistently had slow logins (30+ seconds sometimes), and yet other clients had random normal/fast logins, and frequent slow logins.
Through troubleshooting, log analysis and experimentation, it appears the fix for this issue is to turn off the PAC service. Once "pac" was removed from the "services =" line in sssd.conf, the problem client boxes were suddenly consistently fast in terms of user logins.
This deployment has the clients talking directly to AD servers it looks up via the normal AD DNS entries, and uses Unix POSIX attributes in AD for uidnumber and gidnumber etc (e.g. it's not doing any SID -> unix ID translations, it's just pulling them directly from LDAP attributes).
I guess my questions are:
1. What does PAC actually do? I've read that it lists a users group as part of a KRB5 response, but also that it might be involved in cross-domain trusts. 2. When is PAC needed. Is it only needed for deployments using IPA? 3. Is there any impact in turning off PAC if the architecture doesn't involve IPA in the mix? 4. Why would PAC slow down such a architecture seemingly randomly?
I've done a bit of searching and have only found sparse information on sssd_pac, some in Jakob's blog! I'm trying to understand its role.
Thanks,
- Jim
On Wed, Sep 18, 2019 at 06:25:31PM -0700, Jim Burwell wrote:
Hi,
I recently encountered issues where logins on Linux clients using SSSD and the AD provider, pointed directly to an AD server were randomly slow. Randomly meaning, some clients experienced no slowness at all, other clients consistently had slow logins (30+ seconds sometimes), and yet other clients had random normal/fast logins, and frequent slow logins.
Through troubleshooting, log analysis and experimentation, it appears the fix for this issue is to turn off the PAC service. Once "pac" was removed from the "services =" line in sssd.conf, the problem client boxes were suddenly consistently fast in terms of user logins.
This deployment has the clients talking directly to AD servers it looks up via the normal AD DNS entries, and uses Unix POSIX attributes in AD for uidnumber and gidnumber etc (e.g. it's not doing any SID -> unix ID translations, it's just pulling them directly from LDAP attributes).
I guess my questions are:
- What does PAC actually do? I've read that it lists a users group as part of a KRB5 response, but also that it might be involved in cross-domain trusts.
There is a lot of information about PAC in the PFD linked here: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064... and a more readable version e.g. here: https://www.freeipa.org/page/Howto/Inspecting_the_PAC
In general, Windows gives you the authoritative set of groups the user is a member of only after login, so parsing the groups out of the PAC is the most reliable way. And in older versions of SSSD, especially with IPA-AD trusts, it was even the only way, IOW 'id' would only display groups after you log in. Newer versions try to approximate the groups with other means, mostly the tokenGroups attribute.
- When is PAC needed. Is it only needed for deployments using IPA?
It was strictly needed with some quite old IPA provider versions and recommeded at some point for AD provider also, but in the meantime, we improved the tokenGroups codepath,so the PAC provider is no longer used for AD provider, at least by default.
- Is there any impact in turning off PAC if the architecture doesn't involve IPA in the mix?
As said above, it is the most reliable way, but if sssd is giving you the group membership you expect also w/o using the PAC, then feel free to not use it.
- Why would PAC slow down such a architecture seemingly randomly?
I guess you might be using an older version of SSSD? In the older versions, the PAC was processed as part of the krb5_child process, so if the PAC processing was taking too long, the krb5_child was timing out. In newer versions, the PAC handling was reworked and is now evaluated differently.
The PAC data is cached iirc, so when the slowdown occured, I guess it was when the PAC data was out of date in the cache.
I've done a bit of searching and have only found sparse information on sssd_pac, some in Jakob's blog! I'm trying to understand its role.
Thanks,
- Jim
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-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/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org