Re: cross-realm delegation via attempted RBCD fails with KRB5KRB_AP_ERR_ILL_CR_TKT

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 <[email protected]> wrote:
>
> Sending this to the dev list to hope to get some traction there.
>
> Any input on this will be greatly appreciated.
>
> ---------- Forwarded message ---------
> From: Jacob Shivers <[email protected]>
> Date: Fri, Apr 8, 2022 at 11:49 AM
> Subject: Re: cross-realm delegation via attempted RBCD fails with
> KRB5KRB_AP_ERR_ILL_CR_TKT
> To: <[email protected]>
>
>
> 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 <[email protected]> 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/[email protected]).
> >
> >  * Obtain the remote ticket granting server principal pointing towards the
> >    child domain (krbtgt/[email protected]).
> >
> >  * Obtain the remote ticket granting server principal pointing back towards the
> >    parent domain (krbtgt/[email protected]).
> >
> >  * Authenticate on behalf of the user in the child domain to the parent domain
> >    using the cross realm TGT ticket (krbtgt/[email protected]) for the
> >    proxy_impersonator ([email protected]).
> >
> >  * Use the proxy_impersonator key to obtain the endpoint credentials for the
> >    NFS server's nfs service (nfs/[email protected]) 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

-- 

Jacob Shivers

_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev