New sssd-related message this week in /var/log/messages

[Spike White]

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
http://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?

Spike White

[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?  
> 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

[Sumit Bose]

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
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Spike White]

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  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.
> > > 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.
> > > Are they due to this new sssd version?
>
> yes
> > > 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
> >
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail].o...
> > Do not reply to spam, report it:
>
> https://pagure.io/fedora-infrastructure/new_issue
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue