• cross-realm delegation via attempted RBCD fails with KRB5KRB_AP_ERR_ILL

    From Jacob Shivers@21:1/5 to All on Mon Mar 28 11:08:08 2022
    Hello All,

    My setup:

    * Parent realm (AD.TOB.COM) and child realm (TEST.AD.TOB.COM) with a
    two-way
    transitive trust in Active Directory.
    * NFS client (f35.ad.tob.com) in AD.TOB.COM
    * NFS server (8x1-nfs.ad.tob.com) in AD.TOB.COM exporting a Kerberized NFS
    share
    * User (data) in AD.TOB.COM
    * User (lore) in TEST.AD.TOB.COM

    I am trying to setup cross-realm Kerberos delegation via Resource Based Constrained Delegation (RBCD) within Active Directory 2K16. In this test,
    there
    are two domains that have a parent/child relationship. User in both the
    parent
    and the child domain are logging into a NFS client within the parent realm
    that
    has mounted a Kerberized NFS share from a NFS server also within the parent realm. No user logging in has a Kerberos ticket and there are no stored
    keytabs
    for users on the NFS client.

    Configuring gssproxy with 'impersonate = yes', users within the parent realm are able to access the Kerberized NFS share with no issue. However, users in the child realm are unable to access the share and gssproxy logs 'Illegal cross-realm ticket' as returned by krb5 libraries. I observe this behavior
    in
    RHEL 8.5 as well as Fedora 35 with Alexander Bokovoy's upstream copr build
    for
    krb5-libs that includes RBCD patches not yet in Fedora proper.

    I have found some sample packet captures from wireshark.org for RBCD, but
    even
    after viewing the captures, I still am not sure what the exact behavior
    should
    be for cross-realm delegation. That being said, the NFS client logs KRB5KRB_AP_ERR_ILL_CR_TKT before the point of delegation for the user in the child domain to the local NFS server.


    My limited understanding, and please excuse any misnaming, is that when the user in the child domain on the NFS client attempts to access the Kerberized NFS share with impersonation active the NFS client should:

    * Authenticate and receive a ticket granting service principal for its
    local
    realm which is the parent realm (krbtgt/AD.TOB.COM@AD.TOB.COM).

    * Obtain the remote ticket granting server principal pointing towards the
    child domain (krbtgt/TEST.AD.TOB.COM@AD.TOB.COM).

    * Obtain the remote ticket granting server principal pointing back towards
    the
    parent domain (krbtgt/AD.TOB.COM@TEST.AD.TOB.COM).

    * Authenticate on behalf of the user in the child domain to the parent
    domain
    using the cross realm TGT ticket (krbtgt/AD.TOB.COM@TEST.AD.TOB.COM) for
    the
    proxy_impersonator (F35$@AD.TOB.COM).

    * Use the proxy_impersonator key to obtain the endpoint credentials for the
    NFS server's nfs service (nfs/8x1-nfs.ad.tob.com@AD.TOB.COM) for the
    user in
    the child domain

    The client does _not_ reach the point of the actual RBCD bits of requesting
    the
    NFS ticket granting service ticket for the user based on comparing this
    failing
    traffic to that of a user in the same realm. `$ tshark` flags kerberos.KDCOptions.constrained.delegation and kerberos.PAC.OPTIONS.FLAGS.resource.based.constrained.delegation are set
    once
    this occurs.


    The below is present in /etc/krb5.conf by way of /var/lib/sss/pubconf/krb5.include.d/domain_realm_ad_tob_com:

    [capaths]
    TEST.AD.TOB.COM = {
    AD.TOB.COM = AD.TOB.COM
    }
    AD.TOB.COM = {
    TEST.AD.TOB.COM = AD.TOB.COM
    }


    I have collected a network trace, a `# strace` of gssproxy, journalctl
    output,
    as well as a KRB5_TRACE of gssproxy with debug_level set to 3. This lab contains no confidential data so I can capture and share any tracing.

    I can also perform any additional tests should it be requested.


    Thank you very much for any guidance that can be offered.



    --

    Jacob Shivers

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