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.TO...@AD.TOB.COM).

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

* Obtain the remote ticket granting server principal pointing back towards
the
parent domain (krbtgt/AD.TO...@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.TO...@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.a...@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]

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.

--

Jacob Shivers

[Jacob Shivers]

Hello,

Reaching out again. Requesting any further input.

As I have said, if something is poorly worded or requires further
clarification I will be happy to elaborate and reword as necessary.

Regards,

On Wed, Apr 27, 2022 at 4:19 PM Jacob Shivers <jshi...@redhat.com> wrote:
>
> Sending this to the dev list to hope to get some traction there.
>
> Any input on this will be greatly appreciated.

--

Jacob Shivers