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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
