On Wed, 2022-12-14 at 13:00 -0600, Spike White wrote: > Sssd experts, > We have been running sssd to AD integrate to a cross-domain AD forest > for ~2 years now. With RHEL 7, 8 and (now) 9 servers. Has worked > great. > Just this week, we have a new message appearing in /var/log/messages > related to sssd that we’ve never seen before: > Dec 10 06:11:19 pshnldur01.amer.company.com sssd_be[343144]: PAC > check is requested but krb5_validate is set to false. PAC checks will > be skipped. > This is a RHEL8 server, running sssd 2.7.3-4.0.1.el8_7.1 -- installed > Fri 02 Dec 2022. We notice a new sssd_pac process running, even > though in /etc/sssd/sssd.conf, we did not explicitly define any “pac” > service. > In RHEL7 servers, we do not see any such sssd_pac process. We do see > this process in RHEL9 servers. > In the change log for this new RHEL8 sssd version, I notice this > recent entry: > [2.7.3-4.1] > - Resolves: rhbz#2128902 - Cannot SSH with AD user to ipa-client > (krb5_validate and pac_check settings conflict) [rhel-9.1.0.z] > > Yes, in our /etc/sssd/sssd.conf file we set: > krb5_validate = False > > All seems to be behaving. The server appears to be able to > communicate fine with this local domain. All expected logins appear > to work. > 1. Can we ignore these messages? > 2. Are they due to this new sssd version? > 3. Why does a pac service start up if we do not explicitly define > it in our list of services?
PAC[1] provides authorization info within a Kerberos ticket. I believe it can be more efficient and/or secure to query the PAC for authorization information rather than using LDAP to query a user's group information. It sounds like your sssd clients don't need to use the PAC to provide user/group identity and you shouldn't be concerned with these messages. Check out [2] for more details. Mark [1]: http://msdn.microsoft.com/en-us/library/cc237917.aspx [2]: https://www.freeipa.org/page/Howto/Inspecting_the_PAC _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
