• Cross-realm S4U2Self with AD trust

    From Jonathan Calmels@21:1/5 to All on Thu Apr 13 21:51:38 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@AD_REALM for user@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@AD_REALM service/host.mit.realm

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

    $ klist

    Default principal: service/host.mit.realm@MIT_REALM

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Calmels@21:1/5 to All on Sat Apr 22 05:03:43 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@nvidia.com>
    Sent: Thursday, April 13, 2023 2:51 PM
    To: kerberos@mit.edu <kerberos@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@AD_REALM for user@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@AD_REALM service/host.mit.realm

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

    $ klist

    Default principal: service/host.mit.realm@MIT_REALM

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)