On Wed, Sep 18, 2019 at 06:25:31PM -0700, Jim Burwell wrote:
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
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
There is a lot of information about PAC in the PFD linked here:
and a more readable version e.g. here:
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.
2. 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.
3. Is there any impact in turning off PAC if the architecture
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.
4. 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
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.
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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