Sumit, So in reviewing my notes, I see that the reason we set:
krb5_validate = false was during that krb5-libs race condition that appeared last year. That if the KVNO between AD and /etc/krb5.keytab file ever got off, then the client would no longer validate its krb5 host creds (that's what my notes say for our justification for setting this sssd.conf setting.) This might have been an early (misguided) attempt to work around this krb5-libs race condition. As we later discovered, the krb5-libs call would have AD update its machine creds on a 30 day cycle. But it would report back to sssd an error, so sssd would not update its local /etc/krb5.keytab file. Thus, the resulting KVNO in AD would be 1 more than the KVNO in /etc/krb5.keytab file. But this is a real problem; not just a problem with krb5 validation. Because those machine account creds in AD with the (N+1) KVNO are truly different than the (expiring) machine account creds in /etc/krb5.keytab with the (N) KVNO. So whether we set krb5_validate = true or krb5_validate = false, it should fail to validate its host creds (after the old creds expire). BTW, with your kind assistance and with that MIT krb5-libs developer's assistance, that krb5-libs race condition was fixed in a krb5-libs RPM update last year. At least for RHEL 7, 8 and (presumably) 9. So I don't think we need to specify krb5_validate = false any more (if we ever did). Agreed? Spike On Thu, Dec 15, 2022 at 1:09 AM Sumit Bose <[email protected]> wrote: > Am Wed, Dec 14, 2022 at 07:52:38PM +0000 schrieb Christian, Mark: > > 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? > > Hi, > > as mentioned below the PAC is part of the Kerberos ticket you receive > during authentication from an AD DC. Over the last year Microsoft added > some new information into the PAC and started to add more checks for the > consistency of the PAC and the mapping to the operation system account. > Since the Kerberos ticket is by design independent of the operating > system account there must be some additional information to map the > Kerberos ticket to the operating system account during authentication > and Microsoft is using the PAC for this. > > Since the mapping is also important for the login to Linux system we > implemented some of the checks as well. To be able to decode the PAC we > have to request a service ticket first. This is the same operation which > is done during the generic ticket validation (krb5_validate) and if this > is disabled we skip the PAC check as well since we assume that ticket > validation is disabled because there are issues requesting the service > ticket. > > So, coming back to your question 'Can we ignore these messages?'. The > message should make you aware that something which we consider as a > security feature is skipped due to a not strictly related configuration > option and it might be worth to reconsider if 'krb5_validate = False' is > really necessary. > > If you disabled the PAC check explicitly by setting > 'pac_check = no_check' in the [pac] section of sssd.conf, the log > message should go away, see man sssd.conf for details. > > > > 2. Are they due to this new sssd version? > > yes > > > > 3. Why does a pac service start up if we do not explicitly define > > > it in our list of services? > > Since we want to do the PAC checks by default if the AD provider is used > the PAC responder is started automatically if the AD provider is used. > If you do not want to have it running you can set > 'implicit_pac_responder = False' in the [sssd] section of sssd.conf, see > man sssd.conf for details. > > HTH > > bye, > Sumit > > > > > 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 > _______________________________________________ > 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 >
_______________________________________________ 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
