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 <jshiv...@redhat.com> 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 <jshiv...@redhat.com> > 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: <kerberos@mit.edu> > > > 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 <jshiv...@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....@ad.tob.com). > > > > * Obtain the remote ticket granting server principal pointing towards the > > child domain (krbtgt/test.ad.tob....@ad.tob.com). > > > > * Obtain the remote ticket granting server principal pointing back towards > > the > > parent domain (krbtgt/ad.tob....@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....@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....@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 -- Jacob Shivers ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos