Join Log in
Score:1
avatar Server

Cross realm constrained delegation

pe flag
KrisVandenbergh

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 [email protected] -P nfs/nfs.idm.example.com
nfs/[email protected]: kvno = 1
$ klist
Ticket cache: KCM:0
Default principal: host/[email protected]

Valid starting       Expires              Service principal
05/26/2022 15:15:22  05/27/2022 14:24:21  host/[email protected]
        for client [email protected]
05/26/2022 15:14:54  05/27/2022 14:24:21  krbtgt/[email protected]
05/26/2022 15:15:22  05/27/2022 14:24:21  nfs/[email protected]
        for client [email protected]

Then trying to impersonate an AD user:

$ kdestroy  
$ kinit -k
$ kvno -I [email protected] -P nfs/nfs.idm.example.com
kvno: TGT has been revoked while getting credentials for nfs/[email protected]
$ klist
Ticket cache: KCM:0
Default principal: host/[email protected]

Valid starting       Expires              Service principal
05/26/2022 15:15:37  05/27/2022 15:10:07  krbtgt/[email protected]
05/26/2022 15:15:50  05/27/2022 15:10:07  krbtgt/[email protected]

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/[email protected] for host/[email protected]
May 27 12:34:23 kerberos.idm.example.com krb5kdc[1732](info): ... PROTOCOL-TRANSITION [email protected]
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/[email protected] for krbtgt/[email protected]
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/[email protected] for host/[email protected], TGT has been revoked
May 27 12:34:47 kerberos.idm.example.com krb5kdc[1732](info): ... PROTOCOL-TRANSITION [email protected]
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 [email protected]  host/client.idm.example.com
[8389] 1653672526.395590: Getting credentials [email protected] -> host/[email protected] using ccache KCM:0
[8389] 1653672526.395591: Retrieving host/[email protected] -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:0 with result: -1765328243/Matching credential not found
[8389] 1653672526.395592: Retrieving [email protected] -> host/[email protected] from KCM:0 with result: -1765328243/Matching credential not found
[8389] 1653672526.395593: Getting credentials host/[email protected] -> krbtgt/[email protected] using ccache KCM:0
[8389] 1653672526.395594: Retrieving host/[email protected] -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:0 with result: -1765328243/Matching credential not found
[8389] 1653672526.395595: Retrieving host/[email protected] -> krbtgt/[email protected] from KCM:0 with result: -1765328243/Matching credential not found
[8389] 1653672526.395596: Retrieving host/[email protected] -> krbtgt/[email protected] from KCM:0 with result: 0/Success
[8389] 1653672526.395597: Starting with TGT for client realm: host/[email protected] -> krbtgt/[email protected]
[8389] 1653672526.395598: Requesting tickets for krbtgt/[email protected], 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/[email protected] -> krbtgt/[email protected] with session key aes256-cts/D9C7
[8389] 1653672526.395612: TGS request result: 0/Success
[8389] 1653672526.395613: Received creds for desired service krbtgt/[email protected]
[8389] 1653672526.395614: Storing host/[email protected] -> krbtgt/[email protected] in KCM:0
[8389] 1653672526.395615: Get cred via TGT krbtgt/[email protected] after requesting host\/client.idm.example.com\@[email protected] (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/[email protected] differs from requested host\/client.idm.example.com\@[email protected]
[8389] 1653672526.395634: TGS reply is for host/[email protected] -> krbtgt/[email protected] with session key aes256-cts/F05E
[8389] 1653672526.395635: Got cred; 0/Success
[8389] 1653672526.395636: Get cred via TGT krbtgt/[email protected] after requesting host/[email protected] (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/[email protected]

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?

58
0 + 0
idm
Calchas avatar
br flag
Calchas
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).
0
Reply
mx flag
strongline
the answer may be in line "[8389] 1653672526.395633". How come "requesting host\/client.idm.example.com" has a back slash \ in the string?
0
Reply
pe flag
KrisVandenbergh
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.
0
Reply
Score:0
avatar Server
ng flag
abbra

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.

0 + 0
pe flag
KrisVandenbergh
Thanks abbra, I'm on RHEL 8.5 with IPA 4.9.8-7. I logged the issue on pagure.io.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.