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 <
jshivers@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.COM@AD.TOB.COM).
* Obtain the remote ticket granting server principal pointing towards the
child domain (krbtgt/TEST.AD.TOB.COM@AD.TOB.COM).
* Obtain the remote ticket granting server principal pointing back towards the
parent domain (krbtgt/AD.TOB.COM@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@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@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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)