跨域约束委托

Question

我在RHEL8上有红帽RHEL8，对Windows2019的AD有双向信任.目前起作用的是：

• NFS客户端受约束的委托。NFS客户端可以从IdM领域(gssproxy)模拟用户。
• AD域的用户可以登录到IdM领域中的主机(信任工作)。

Wat不起作用的是NFS客户端试图模拟AD用户。只获取s4u2proxy票证似乎只适用于IdM域中的用户：

$ 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

然后试图模拟AD用户：

$ 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

krb5kdc.log或许有一个暗示。当在KDC本身(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

当试图从远程“受信任”领域(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在调试模式下显示了这一点：

[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

有谁知道Red是否有可能从“其他”领域模拟用户？实际上，我不确定这是否是一个受支持的特性。如果它是支持的，它是否需要任何东西以外的双向信任？

Answer 1

这听起来像https://pagure.io/freeipa/issue/9031，应该在ipa-4.9.6-10中固定在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]

不过，这可能是修复中的一个问题。请用您的详细信息在https://pagure.io/freeipa/new_问题上创建一个问题。