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