Resource access across forest trusts with pass-through realm authentication
Ben Creech
bpcreech at eos.ncsu.edu
Fri Oct 31 16:31:40 EST 2003
For the past few days, I have been trying to research whether it's possible
to successfully implement a particular Active Directory architecture.
However, I can't get working what we want to do. I'm not sure if I'm doing
something wrong, or if Microsoft's code simply does not support it -
whether by design or by accident.
It boils down to this:
When using pass-through authentication from a Kerberos Realm to a Win2k3
forest, is it possible to use existing credentials to access a resource in
another Win2k3 forest?
To display it visually in a sad little ascii diagram:
[MIT_BASED_REALM] (User's account is here)
/|\
| - Transitive Realm Trust
|
[AD_FOREST_A] (User's workstation is here)
/|\
| - Transitive Forest Trust
|
[AD_FOREST_B] (Server with file share is here)
Ideally, the user uses an account @MIT_BASED_REALM to log into a
workstation belonging to a domain in AD_FOREST_A. The workstation gets a
cross-realm TGT from the MIT_BASED_REALM and uses that to authenticate in
AD_FOREST_A. This lets the user log in.
Once logged in, the user tries to access a file share on a server in
AD_FOREST_B. The user's workstation chases a multiple-domain referral to
eventually get an SGT for cifs/server at FOREST_B. Now, the user can send
that SGT to the server and successfully access the file share.
I have been trying to do proof-of-concept of this setup using 5 machines in
a testbed (one Linux KDC running krb5 1.3.1, two DCs running Win2k3 server,
two member machines running WinXP). Unfortunately, it will not work for
me. Below I describe what I've tried. In every case, the user can
successfully log in to the workstation in AD_FOREST_A, but can never get
access to the file share in AD_FOREST_B without getting a password prompt.
Also, when logging in using an account located directly in AD_FOREST_A
(actually using the same account but not in name-mapped fashion), the
workstation can access the share - using the krb5 mechanism - with no
problem.
I can produce libpcap packet traces of any of this if anyone's interested.
---Stock krb5 1.3.1 in setup described above---
The user's workstation tries to get a referral for cifs/server at AD_FOREST_B
from the Linux KDC. Linux KDC understandably returns principal unknown.
Workstation tries again from its domain controller in AD_FOREST_A. This
time, it does get a referral ticket to AD_FOREST_B.
However, after sending a krbtgt/AD_FOREST_B at AD_FOREST_A to the DC for
AD_FOREST_B, the DC returns KRB5KDC_ERR_POLICY. I cannot for the life of
me figure out why. It would seem that for some reason the DC has decided
it will not grant an SGT for cifs/server at AD_FOREST_B to
user at MIT_BASED_REALM. I have checked the "allowed to authenticate" flag on
the computer object in the domain, and also tried changing the forest trust
to "domain-wide authentication". The same error persists. Turning on
Kerberos logging on the server does log the error in the event log, but
with no more information than I can get out of Ethereal.
So to summarize, the workstation can follow the referral chain down to the
target forest, but the DC mysteriously refuses to grant the requested SGT.
---UMICH-referral-patched krb5 1.3.1 in setup described above---
The user's workstation again tries to get a referral for
cifs/server at AD_FOREST_B from the Linux KDC. Linux KDC, now patched to do
so, give the workstation a referral ticket for AD_FOREST_A.
However, the rest is the same as before. After successfully climbing down
the referral chain, the workstation still gets a a mysterious
KRB5KDC_ERR_POLICY from DC for AD_FOREST_B.
---Same setup, but now with an additional trust directly from AD_FOREST_B
to MIT_BASED_REAM with the addition registered in [domain_referrals] in
kdc.conf---
Here, when the workstation goes for a referral ticket from the Linux KDC,
it gets a referral straight to the AD_FOREST_B domain. For some reason,
this referral ticket is good enough for the DC, which then grants an SGT
for cifs/server at AD_FOREST_B.
That done, the user's workstation then sends the SGT off to the server.
The server accepts the SGT. However, a few packet exchanges later, the
workstation tries to call NetShareGetInfo on \\server\sharename, and the
server returns access denied. I cannot find any information as to why
access is denied. All the permissions that should be there are there (a
fact that can be verified by using the user's "real" non-mapped account).
I have tried opening up every conceivable access control setting and
policy, to no effect. Auditing everything in sight returns no useful
information.
To summarize this failed attempt, authentication succeeds, but for some
reason I don't understand, authorization fails.
So, in conclusion, does anyone have any idea why what I'm doing does not
work? Has anyone tried this before? Is anyone still reading this?
Thanks,
Ben Creech
NCSU ITECS
More information about the Kerberos
mailing list