Cross-realm S4U2Self with AD trust

Jonathan Calmels jcalmels at nvidia.com
Sat Apr 22 01:03:43 EDT 2023


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 <jcalmels at nvidia.com>
Sent: Thursday, April 13, 2023 2:51 PM
To: kerberos at mit.edu <kerberos at 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\@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