Discussion:
Cross-realm S4U2Self with AD trust
(too old to reply)
Jonathan Calmels
2023-04-13 21:51:38 UTC
Permalink
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\@***@AD_REALM for ***@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 ***@AD_REALM service/host.mit.realm

Getting initial credentials for service/***@MIT_REALM
Getting credentials ***@AD_REALM -> service/***@MIT_REALM
Getting credentials service/***@MIT_REALM -> krbtgt/***@MIT_REALM
Starting with TGT for client realm: service/***@MIT_REALM -> krbtgt/***@MIT_REALM
Requesting tickets for krbtgt/***@MIT_REALM, referrals on
TGS reply is for service/***@MIT_REALM -> krbtgt/***@MIT_REALM with session key aes256-sha2/E5C5
Received creds for desired service krbtgt/***@MIT_REALM
Get cred via TGT krbtgt/***@MIT_REALM after requesting service\/host.mit.realm\@***@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/***@MIT_REALM

$ klist

Default principal: service/***@MIT_REALM

Valid starting Expires Service principal
04/12/2023 14:32:02 04/13/2023 00:32:02 krbtgt/***@MIT_REALM
renew until 04/19/2023 14:32:02
04/12/2023 14:32:02 04/13/2023 00:32:02 krbtgt/***@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/***@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,
Jonathan Calmels
2023-04-22 05:03:43 UTC
Permalink
I guess a better question would be:

Does MIT Kerberos support S4U2Self with an Active directory cross-realm 2-way trust as is, or does it require Samba with a cross-forest 2-way trust?

________________________________
From: Jonathan Calmels <***@nvidia.com>
Sent: Thursday, April 13, 2023 2:51 PM
To: ***@mit.edu <***@mit.edu>
Subject: Cross-realm S4U2Self with AD trust

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\@***@AD_REALM for ***@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 ***@AD_REALM service/host.mit.realm

Getting initial credentials for service/***@MIT_REALM
Getting credentials ***@AD_REALM -> service/***@MIT_REALM
Getting credentials service/***@MIT_REALM -> krbtgt/***@MIT_REALM
Starting with TGT for client realm: service/***@MIT_REALM -> krbtgt/***@MIT_REALM
Requesting tickets for krbtgt/***@MIT_REALM, referrals on
TGS reply is for service/***@MIT_REALM -> krbtgt/***@MIT_REALM with session key aes256-sha2/E5C5
Received creds for desired service krbtgt/***@MIT_REALM
Get cred via TGT krbtgt/***@MIT_REALM after requesting service\/host.mit.realm\@***@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/***@MIT_REALM

$ klist

Default principal: service/***@MIT_REALM

Valid starting Expires Service principal
04/12/2023 14:32:02 04/13/2023 00:32:02 krbtgt/***@MIT_REALM
renew until 04/19/2023 14:32:02
04/12/2023 14:32:02 04/13/2023 00:32:02 krbtgt/***@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/***@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,

Loading...