cross-realm delegation via attempted RBCD fails with KRB5KRB_AP_ERR_ILL_CR_TKT

[Jacob Shivers]

Hello,

Reaching out again.

If something is poorly worded or requires further
clarification/explanation I am more than willing to try to elaborate.
I am a bit stuck on this issue and would greatly appreciate any
feedback of things to test or to look at further.

Thank you _very_ much.

On Mon, Mar 28, 2022 at 11:08 AM Jacob Shivers <jshivers at redhat.com> wrote:
>
> 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 at AD.TOB.COM).
>
>  * Obtain the remote ticket granting server principal pointing towards the
>    child domain (krbtgt/TEST.AD.TOB.COM at AD.TOB.COM).
>
>  * Obtain the remote ticket granting server principal pointing back towards the
>    parent domain (krbtgt/AD.TOB.COM at 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 at 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 at 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



-- 

Jacob Shivers