cross-realm delegation via attempted RBCD fails with KRB5KRB_AP_ERR_ILL_CR_TKT

[Jacob Shivers]

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