Cross realm constrained delegation

Question

I have Red Hat IdM on RHEL8 with a two-way trust to AD on Windows 2019. What currently works:

Constrained delegation for NFS clients. NFS clients can impersonate users from the IdM realm (gssproxy).
Users from the AD domain can log on to the hosts in the IdM realm (the trust works).

Wat doesn't work is the NFS client trying to impersonate AD users. Getting s4u2proxy tickets only seems to work for users within the IdM domain:

$ kinit -k
$ kvno -I user01@IDM.EXAMPLE.COM -P nfs/nfs.idm.example.com
nfs/nfs.idm.example.com@IDM.EXAMPLE.COM: kvno = 1
$ klist
Ticket cache: KCM:0
Default principal: host/client.idm.example.com@IDM.EXAMPLE.COM

Valid starting       Expires              Service principal
05/26/2022 15:15:22  05/27/2022 14:24:21  host/client.idm.example.com@IDM.EXAMPLE.COM
        for client user01@IDM.EXAMPLE.COM
05/26/2022 15:14:54  05/27/2022 14:24:21  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
05/26/2022 15:15:22  05/27/2022 14:24:21  nfs/nfs.idm.example.com@IDM.EXAMPLE.COM
        for client user01@IDM.EXAMPLE.COM

Then trying to impersonate an AD user:

$ kdestroy  
$ kinit -k
$ kvno -I user02@AD.EXAMPLE.COM -P nfs/nfs.idm.example.com
kvno: TGT has been revoked while getting credentials for nfs/nfs.idm.example.com@IDM.EXAMPLE.COM
$ klist
Ticket cache: KCM:0
Default principal: host/client.idm.example.com@IDM.EXAMPLE.COM

Valid starting       Expires              Service principal
05/26/2022 15:15:37  05/27/2022 15:10:07  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
05/26/2022 15:15:50  05/27/2022 15:10:07  krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM

The krb5kdc.log has perhaps a hint. When impersonating a user within the realm of the KDC itself (s4u2self):

May 27 12:34:23 kerberos.idm.example.com krb5kdc[1732](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168.1.42: ISSUE: authtime 1653647627, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, host/client.idm.example.com@IDM.EXAMPLE.COM for host/client.idm.example.com@IDM.EXAMPLE.COM
May 27 12:34:23 kerberos.idm.example.com krb5kdc[1732](info): ... PROTOCOL-TRANSITION s4u-client=user01@IDM.EXAMPLE.COM
May 27 12:34:23 kerberos.idm.example.com krb5kdc[1732](info): closing down fd 12

When trying to impersonate the user from the remote "trusted" realm (s4u2self):

May 27 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168.1.42: ISSUE: authtime 1653647627, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, host/client.idm.example.com@IDM.EXAMPLE.COM for krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM
May 27 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): closing down fd 12
May 27 12:34:47 kerberos.idm.example.com krb5kdc[1732](Error): PAC issue: PAC has a SID different from what PAC requester claims. PAC [S-1-5-21-2772319413-1696261159-756038808-1602] vs PAC requester [S-1-5-21-956857513-2416212418-705989587-515]
May 27 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): TGS_REQ : handle_authdata (-1765328364)
May 27 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168.1.42: HANDLE_AUTHDATA: authtime 1653647627, etypes {rep=UNSUPPORTED:(0)} host/client.idm.example.com@IDM.EXAMPLE.COM for host/client.idm.example.com@IDM.EXAMPLE.COM, TGT has been revoked
May 27 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): ... PROTOCOL-TRANSITION s4u-client=user02@AD.EXAMPLE.COM
May 27 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): closing down fd 12

knvo shows this in debug mode:

[root@client ~]# kvno -I user02@AD.EXAMPLE.COM  host/client.idm.example.com
[8389] 1653672526.395590: Getting credentials user02@AD.EXAMPLE.COM -> host/client.idm.example.com@IDM.EXAMPLE.COM using ccache KCM:0
[8389] 1653672526.395591: Retrieving host/client.idm.example.com@IDM.EXAMPLE.COM -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:0 with result: -1765328243/Matching credential not found
[8389] 1653672526.395592: Retrieving user02@AD.EXAMPLE.COM -> host/client.idm.example.com@IDM.EXAMPLE.COM from KCM:0 with result: -1765328243/Matching credential not found
[8389] 1653672526.395593: Getting credentials host/client.idm.example.com@IDM.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM using ccache KCM:0
[8389] 1653672526.395594: Retrieving host/client.idm.example.com@IDM.EXAMPLE.COM -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:0 with result: -1765328243/Matching credential not found
[8389] 1653672526.395595: Retrieving host/client.idm.example.com@IDM.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM from KCM:0 with result: -1765328243/Matching credential not found
[8389] 1653672526.395596: Retrieving host/client.idm.example.com@IDM.EXAMPLE.COM -> krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM from KCM:0 with result: 0/Success
[8389] 1653672526.395597: Starting with TGT for client realm: host/client.idm.example.com@IDM.EXAMPLE.COM -> krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
[8389] 1653672526.395598: Requesting tickets for krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM, referrals on
[8389] 1653672526.395599: Generated subkey for TGS request: aes256-cts/4F09
[8389] 1653672526.395600: etypes requested in TGS request: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[8389] 1653672526.395602: Encoding request body and padata into FAST request
[8389] 1653672526.395603: Sending request (1941 bytes) to IDM.EXAMPLE.COM
[8389] 1653672526.395604: Initiating TCP connection to stream 192.168.1.40:88
[8389] 1653672526.395605: Sending TCP request to stream 192.168.1.40:88
[8389] 1653672526.395606: Received answer (1860 bytes) from stream 192.168.1.40:88
[8389] 1653672526.395607: Terminating TCP connection to stream 192.168.1.40:88
[8389] 1653672526.395608: Response was from master KDC
[8389] 1653672526.395609: Decoding FAST response
[8389] 1653672526.395610: FAST reply key: aes256-cts/7017
[8389] 1653672526.395611: TGS reply is for host/client.idm.example.com@IDM.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM with session key aes256-cts/D9C7
[8389] 1653672526.395612: TGS request result: 0/Success
[8389] 1653672526.395613: Received creds for desired service krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM
[8389] 1653672526.395614: Storing host/client.idm.example.com@IDM.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM in KCM:0
[8389] 1653672526.395615: Get cred via TGT krbtgt/AD.EXAMPLE.COM@IDM.EXAMPLE.COM after requesting host\/client.idm.example.com\@IDM.EXAMPLE.COM@AD.EXAMPLE.COM (canonicalize on)
[8389] 1653672526.395616: Generated subkey for TGS request: aes256-cts/4CB0
[8389] 1653672526.395617: etypes requested in TGS request: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[8389] 1653672526.395619: Encoding request body and padata into FAST request
[8389] 1653672526.395620: Sending request (2303 bytes) to AD.EXAMPLE.COM
[8389] 1653672526.395621: Sending DNS URI query for _kerberos.AD.EXAMPLE.COM.
[8389] 1653672526.395622: URI answer: 0 100 "krb5srv:m:udp:belfast.ad.home."
[8389] 1653672526.395623: URI answer: 0 100 "krb5srv:m:tcp:belfast.ad.home."
[8389] 1653672526.395624: Resolving hostname belfast.ad.home.
[8389] 1653672526.395625: Resolving hostname belfast.ad.home.
[8389] 1653672526.395626: Initiating TCP connection to stream 192.168.1.50:88
[8389] 1653672526.395627: Sending TCP request to stream 192.168.1.50:88
[8389] 1653672526.395628: Received answer (1852 bytes) from stream 192.168.1.50:88
[8389] 1653672526.395629: Terminating TCP connection to stream 192.168.1.50:88
[8389] 1653672526.395630: Response was from master KDC
[8389] 1653672526.395631: Decoding FAST response
[8389] 1653672526.395632: FAST reply key: aes256-cts/9CCA
[8389] 1653672526.395633: Reply server krbtgt/IDM.EXAMPLE.COM@AD.EXAMPLE.COM differs from requested host\/client.idm.example.com\@IDM.EXAMPLE.COM@AD.EXAMPLE.COM
[8389] 1653672526.395634: TGS reply is for host/client.idm.example.com@IDM.EXAMPLE.COM -> krbtgt/IDM.EXAMPLE.COM@AD.EXAMPLE.COM with session key aes256-cts/F05E
[8389] 1653672526.395635: Got cred; 0/Success
[8389] 1653672526.395636: Get cred via TGT krbtgt/IDM.EXAMPLE.COM@AD.EXAMPLE.COM after requesting host/client.idm.example.com@IDM.EXAMPLE.COM (canonicalize on)
[8389] 1653672526.395637: Generated subkey for TGS request: aes256-cts/3CAC
[8389] 1653672526.395638: etypes requested in TGS request: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[8389] 1653672526.395640: Encoding request body and padata into FAST request
[8389] 1653672526.395641: Sending request (2128 bytes) to IDM.EXAMPLE.COM
[8389] 1653672526.395642: Initiating TCP connection to stream 192.168.1.40:88
[8389] 1653672526.395643: Sending TCP request to stream 192.168.1.40:88
[8389] 1653672526.395644: Received answer (432 bytes) from stream 192.168.1.40:88
[8389] 1653672526.395645: Terminating TCP connection to stream 192.168.1.40:88
[8389] 1653672526.395646: Response was from master KDC
[8389] 1653672526.395647: Decoding FAST response
[8389] 1653672526.395648: Decoding FAST response
[8389] 1653672526.395649: Got cred; -1765328364/TGT has been revoked
kvno: TGT has been revoked while getting credentials for host/client.idm.example.com@IDM.EXAMPLE.COM

Anyone who knows whether it is possible with Red Hat IdM to impersonate users from the "other" realm? I'm actually not sure whether this is a supported feature. If it is supported, does it require anything beyond the two-way trust?

It would be useful to see the KDC logs (from both the Windows and MIT KDCs) and the client log (set KRB5_TRACE=/dev/stderr in the environment). — Calchas, May 27 '22 at 05:55
the answer may be in line "[8389] 1653672526.395633". How come "requesting host\/client.idm.example.com" has a back slash \ in the string? — strongline, May 31 '22 at 14:37
The issue was apparently observed here as well: https://pagure.io/freeipa/issue/9124 . An alternative way to trigger the "PAC issue: PAC has a SID different from what PAC requester claims." in krb5kdc.log is to run a "ipa-print-pac impersonate" for a user in the remote domain. — KrisVandenbergh, Jun 04 '22 at 08:56

score 0 · Answer 1 · answered May 28 '22 at 09:47

This sounds like https://pagure.io/freeipa/issue/9031 which should be fixed in ipa-4.9.6-10 in RHEL 8.5+.

May 27 12:34:47 kerberos.idm.example.com krb5kdc[1732](Error): PAC issue: PAC has a SID different from what PAC requester claims. PAC [S-1-5-21-2772319413-1696261159-756038808-1602] vs PAC requester [S-1-5-21-956857513-2416212418-705989587-515]

This might be a problem in the fix, though. Please create an issue at https://pagure.io/freeipa/new_issue with your details.

Thanks abbra, I'm on RHEL 8.5 with IPA 4.9.8-7. I logged the issue on pagure.io. — KrisVandenbergh, May 28 '22 at 15:20

Cross realm constrained delegation

1 Answers1