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/[EMAIL PROTECTED] 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/[EMAIL PROTECTED] 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/[EMAIL PROTECTED] 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/[EMAIL PROTECTED] to [EMAIL PROTECTED] 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/[EMAIL PROTECTED] 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/[EMAIL PROTECTED]
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
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
