Resource access across forest trusts with pass-through realm authentication

[Ben Creech]

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