SSSD checks PAC from MIT Kerberos and fails

[sigmaris]

I have a small collection of machines which are using, via SSSD, a central MIT Kerberos + OpenLDAP server for a user directory (and to store autofs and sudoers information). I have recently noticed password-based authentication for users stored in the directory server, no longer works on the machines that are clients of the directory server. It's infrequent that I use password authentication, so I'm not sure which version of SSSD this worked with in the past, but the current SSSD version I'm using with this issue is 2.10.1 (via the Debian package 2.10.1-2+b1).

For example, if I log in using SSH (with GSSAPI authentication, though that's probably not relevant) to one machine, then run sudo -i, it prompts for my password, then after I enter the correct password it rejects it with "Sorry, try again."

In the system journal on the machine running sudo -i I see

Dec 13 14:18:18 nas64 sudo[1258338]: pam_unix(sudo-i:auth): authentication failure; logname=sigmaris uid=1000 euid=0 tty=/dev/pts/3 ruser=sigmaris rhost=  user=sigmaris
Dec 13 14:18:18 nas64 krb5_child[1258339]: Unknown code UUz 104
Dec 13 14:18:18 nas64 sudo[1258338]: pam_sss(sudo-i:auth): authentication failure; logname=sigmaris uid=1000 euid=0 tty=/dev/pts/3 ruser=sigmaris rhost= user=sigmaris
Dec 13 14:18:18 nas64 sudo[1258338]: pam_sss(sudo-i:auth): received for user sigmaris: 4 (System error)

Looking at the krb5_child logs shows messages like

(2025-12-13 14:18:18): [krb5_child[1258339]] [get_and_save_tgt] (0x0020): [RID#28] 2389: [1432158312][Unknown code UUz 104]
(2025-12-13 14:18:18): [krb5_child[1258339]] [map_krb5_error] (0x0040): [RID#28] [1432158312][PAC check failed].

I also tried to turn on debugging and looking at the sssd_pac.log shows some more information about the PAC validation:

   *  (2025-12-13 10:54:25): [pac] [accept_fd_handler] (0x0400): [CID#1] Client [cmd /usr/libexec/sssd/krb5_child][uid 0][0xaaaaca86a270][17] connected!
   *  (2025-12-13 10:54:25): [pac] [sss_cmd_get_version] (0x0200): [CID#1] Received client version [1].
   *  (2025-12-13 10:54:25): [pac] [sss_cmd_get_version] (0x0200): [CID#1] Offered version [1].
   *  (2025-12-13 10:54:25): [pac] [ad_get_data_from_pac] (0x4000): [CID#1] Unhandled PAC buffer type [10].
   *  (2025-12-13 10:54:25): [pac] [ad_get_data_from_pac] (0x4000): [CID#1] Unhandled PAC buffer type [16].
   *  (2025-12-13 10:54:25): [pac] [ad_get_data_from_pac] (0x0020): [CID#1] LOGON_INFO pac buffer missing.
********************** BACKTRACE DUMP ENDS HERE *********************************

(2025-12-13 10:54:25): [pac] [pac_add_pac_user] (0x0040): [CID#1] ad_get_data_from_pac failed.
(2025-12-13 10:55:03): [pac] [ad_get_data_from_pac] (0x0020): [CID#2] LOGON_INFO pac buffer missing.

I suspect the problem started when I upgraded the KDC to MIT Kerberos 1.20; in the release notes for that version it says:

Beginning with release 1.20, the KDC will include minimal PACs in tickets instead of AD-SIGNEDPATH authdata

I suspect SSSD is trying to validate the PAC as if it's created by an Active Directory KDC, but it's actually a "minimal" PAC created by MIT Kerberos that only contains buffer types 10 and 16, but doesn't contain the expected LOGON_INFO buffer like an Active Directory PAC would.

I also tried to disable the PAC checking entirely by adding

[pac]
pac_check = no_check

to sssd.conf, but it seems to make no difference.

[alexey-tikhonov]

[ad_get_data_from_pac] (0x0020): [CID#2] LOGON_INFO pac buffer missing.
...
I suspect the problem started when I upgraded the KDC to MIT Kerberos 1.20

@jrisc, @abbra, does this ring a bell?

[abbra]

For a raw MIT Kerberos 1.20+ there will be a set of PAC buffers but indeed no LOGON_INFO or any other buffers expected by AD/IPA as required by the MS-PAC spec.

no_check is enforcing the fact that PAC should not checked at all.

pac_present should be used when we ensure that the PAC must be present but we should not be validating its content beyond what krb5_pac_verify() does. I'd recommend using this one.

Perhaps, SSSD internal logic is flawed for no_check case when PAC is present but does not contain other buffers we check? Ideally, it should not even result in caling into krb5_pac_verify(), e.g. into sss_extract_pac().

[abbra]

krb5_child does not use [pac] section. It uses domain configuration, so add pac_check = no_check to the domain section as well.

[abbra]

But it is better to add pac_check = pac_present for both sections. You really want to have PAC present, even without LOGON_INFO and other informational buffers because PAC contains signatures that an attacker cannot modify.

[sumit-bose]

Hi,

unfortunately, it looks like pac_check = no_check does not work as expected in this case, the LOGON_INFO buffer is checked unconditionally. This has to be fixed.

As a workaround you can remove pac from the services option in your sssd.conf so that the PAC responder is not started at all.

HTH

bye,
Sumit

[sigmaris]

krb5_child does not use [pac] section. It uses domain configuration, so add pac_check = no_check to the domain section as well.

I tried this, but it doesn't seem to make any difference.

But it is better to add pac_check = pac_present for both sections. You really want to have PAC present, even without LOGON_INFO and other informational buffers because PAC contains signatures that an attacker cannot modify.

I agree, ideally sssd could just check the "minimal PAC" signatures and so on.

unfortunately, it looks like pac_check = no_check does not work as expected in this case, the LOGON_INFO buffer is checked unconditionally. This has to be fixed.

As a workaround you can remove pac from the services option in your sssd.conf so that the PAC responder is not started at all.

OTOH this does workaround the problem for me, I am using the Debian package which socket-activates everything so I have disabled sssd-pac.socket. Now krb5_child can't contact the PAC responder, skips validating the PAC and accepts the password.

[abbra]

The minimal PAC signatures are checked automatically by krb5_pac_verify() call already. As @sumit-bose acknowledged, there is an issue in SSSD logic, so I think this bug needs to be fixed.

https://github.com/SSSD/sssd/blob/master/src/util/pac_utils.c#L103 only accepts pac_check in the [pac] section. The domain section is only accepted for id_provider = ipa or id_provider = ad. Otherwise the default is already no_check.
When no_check is specified or derived, no attempt to call into krb5_pac_verfiy() will happen, so this is something we need to address, for sure.

What puzzles me is that we somehow end up calling into the validation code despite the fact that pac_check = no_check setting is present. All codepaths in krb5_child assume such calls under check_pac_flags != 0 while no_check is exactly setting the check_pac_flags to 0.

When SSSD authdata plugin is enabled, the client side of it will attempt to extract the PAC and send it to the sssd_pac process. Prior to that, it will call krb5_pac_verify(), so the PAC is at least known to be correct. sssd_pac will probably ignore or reject the PAC anyway if it comes from untrusted PID (default).

[sumit-bose]

What puzzles me is that we somehow end up calling into the validation code despite the fact that pac_check = no_check setting is present. All codepaths in krb5_child assume such calls under check_pac_flags != 0 while no_check is exactly setting the check_pac_flags to 0.

Hi,

there is a second switch send_pac which is used for the original purpose of the PAC responder, to extract group memberships from the PAC. But due to the logic bug the PAC responder tries to check the PAC as well.

HTH

bye,
Sumit