Cross-realm S4U2Self with AD trust
Jonathan Calmels
jcalmels at nvidia.com
Thu Apr 13 17:51:38 EDT 2023
Hi,
We have a 2-way trust between a MIT KDC and MS AD.
In the MIT realm, we have a service than needs to perform protocol transition (S4U) on behalf of a user from the AD realm.
However, we're currently experiencing issues with S4U2Self whereby AD can't find said service in its database.
>From our limited understanding of cross-realm S4U, we expect AD to issue a TGT referral for the MIT service with the PAC of the user as described in
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/f35b6902-6f5e-4cd0-be64-c50bbaaf54a5
However it seems like the remote MIT service is being looked up in AD's DB (maybe to check for TrustedToAuthForDelegation).
We tried configuring an account in AD with same SPN as the one in the MIT realm, but it didn't change anything, requests always fails on step 3.
Looking at the request, libkrb5 seems to use a canonicalized enterprise principal name of the form "service/host.mit.realm\@MIT_REALM at AD_REALM for user at AD_REALM" to perform the request.
Is this accurate? (I couldn't find the reference in the S4U spec), and if so why does AD think this principal is part of its realm?
Are we missing anything configuration wise?
Logs and excerpt of the request:
$ kvno -I user at AD_REALM service/host.mit.realm
Getting initial credentials for service/host.mit.realm at MIT_REALM
Getting credentials user at AD_REALM -> service/host.mit.realm at MIT_REALM
Getting credentials service/host.mit.realm at MIT_REALM -> krbtgt/AD_REALM at MIT_REALM
Starting with TGT for client realm: service/host.mit.realm at MIT_REALM -> krbtgt/MIT_REALM at MIT_REALM
Requesting tickets for krbtgt/AD_REALM at MIT_REALM, referrals on
TGS reply is for service/host.mit.realm at MIT_REALM -> krbtgt/AD_REALM at MIT_REALM with session key aes256-sha2/E5C5
Received creds for desired service krbtgt/AD_REALM at MIT_REALM
Get cred via TGT krbtgt/AD_REALM at MIT_REALM after requesting service\/host.mit.realm\@MIT_REALM at AD_REALM (canonicalize on)
Got cred; -1765328377/Server not found in Kerberos database
kvno: Server not found in Kerberos database while getting credentials for service/host.mit.realm at MIT_REALM
$ klist
Default principal: service/host.mit.realm at MIT_REALM
Valid starting Expires Service principal
04/12/2023 14:32:02 04/13/2023 00:32:02 krbtgt/MIT_REALM at MIT_REALM
renew until 04/19/2023 14:32:02
04/12/2023 14:32:02 04/13/2023 00:32:02 krbtgt/AD_REALM at MIT_REALM
renew until 04/19/2023 14:32:02
===============
PA-DATA pA-FOR-USER
padata-type: pA-FOR-USER (129)
padata-value: 304fa0153013a003020101a10c300a1b086a63616c6d656c73a10c1b0a4e56494449412e…
name
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 1 item
KerberosString: user
realm: AD_REALM
cksum
cksumtype: cKSUMTYPE-HMAC-MD5 (-138)
checksum: d7a3ce0060dc9de668771aa397593450
auth: Kerberos
req-body
Padding: 0
kdc-options: 40810000
0... .... = reserved: False
.1.. .... = forwardable: True
..0. .... = forwarded: False
...0 .... = proxiable: False
.... 0... = proxy: False
.... .0.. = allow-postdate: False
.... ..0. = postdated: False
.... ...0 = unused7: False
1... .... = renewable: True
.0.. .... = unused9: False
..0. .... = unused10: False
...0 .... = opt-hardware-auth: False
.... 0... = unused12: False
.... .0.. = unused13: False
.... ..0. = constrained-delegation: False
.... ...1 = canonicalize: True
0... .... = request-anonymous: False
.0.. .... = unused17: False
..0. .... = unused18: False
...0 .... = unused19: False
.... 0... = unused20: False
.... .0.. = unused21: False
.... ..0. = unused22: False
.... ...0 = unused23: False
0... .... = unused24: False
.0.. .... = unused25: False
..0. .... = disable-transited-check: False
...0 .... = renewable-ok: False
.... 0... = enc-tkt-in-skey: False
.... .0.. = unused29: False
.... ..0. = renew: False
.... ...0 = validate: False
realm: AD_REALM
sname
name-type: kRB5-NT-ENTERPRISE-PRINCIPAL (10)
sname-string: 1 item
SNameString: service/host.mit.realm at MIT_REALM
till: 2023-03-31 03:38:22 (UTC)
nonce: 29027264
etype: 2 items
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA384-192 (20)
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
Thanks,
More information about the Kerberos
mailing list