Then again, I could be wrong, but I'm not sure how I'd check. The authorization data is encrypted with the server key (cifs/[EMAIL PROTECTED]), which I don't know. I suppose I could look at the packet traces to at least see how big the packets are. The PAC looks like it would add at least a couple KB to the tickets.
--On Sunday, November 02, 2003 10:16 AM -0500 Karl Kowallis <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hello Ben,
Microsoft's non-standard implementation of Kerberos includes account information from the Microsoft DC. This is done to assist with domain wide authorization. (This is my understanding) MIT Kerberos only deals with the authentication part and authorization must be managed seperately.
My guess, as a novice, is that the windows file share knows who you are because it received your credentials, but the ticket from the MIT realm is missing the Microsoft specific stuff and therefore either blocks you or requests a downgraded NTLM style authentication.
Confirmation of this, and possible work arounds may come from the list. I don't think it can be fixed though. Your setup is the very one that Microsoft doesn't want to work. Microsoft wants you to pay for all of those client access licenses on a W2K server in an AD, not use a free version of MIT Kerb.
Karl
Friday, October 31, 2003, 4:31:40 PM, you wrote:
BC> For the past few days, I have been trying to research whether it's possible BC> to successfully implement a particular Active Directory architecture. BC> However, I can't get working what we want to do. I'm not sure if I'm doing BC> something wrong, or if Microsoft's code simply does not support it - BC> whether by design or by accident.
BC> It boils down to this: BC> When using pass-through authentication from a Kerberos Realm to a Win2k3 BC> forest, is it possible to use existing credentials to access a resource in BC> another Win2k3 forest?
BC> To display it visually in a sad little ascii diagram:
BC> [MIT_BASED_REALM] (User's account is here) BC> /|\ BC> | - Transitive Realm Trust BC> | BC> [AD_FOREST_A] (User's workstation is here) BC> /|\ BC> | - Transitive Forest Trust BC> | BC> [AD_FOREST_B] (Server with file share is here)
BC> Ideally, the user uses an account @MIT_BASED_REALM to log into a BC> workstation belonging to a domain in AD_FOREST_A. The workstation gets a BC> cross-realm TGT from the MIT_BASED_REALM and uses that to authenticate in BC> AD_FOREST_A. This lets the user log in.
BC> Once logged in, the user tries to access a file share on a server in BC> AD_FOREST_B. The user's workstation chases a multiple-domain referral to BC> eventually get an SGT for cifs/[EMAIL PROTECTED] Now, the user can send BC> that SGT to the server and successfully access the file share.
BC> I have been trying to do proof-of-concept of this setup using 5 machines in BC> a testbed (one Linux KDC running krb5 1.3.1, two DCs running Win2k3 server, BC> two member machines running WinXP). Unfortunately, it will not work for BC> me. Below I describe what I've tried. In every case, the user can BC> successfully log in to the workstation in AD_FOREST_A, but can never get BC> access to the file share in AD_FOREST_B without getting a password prompt. BC> Also, when logging in using an account located directly in AD_FOREST_A BC> (actually using the same account but not in name-mapped fashion), the BC> workstation can access the share - using the krb5 mechanism - with no BC> problem.
BC> I can produce libpcap packet traces of any of this if anyone's interested.
BC> ---Stock krb5 1.3.1 in setup described above--- BC> The user's workstation tries to get a referral for cifs/[EMAIL PROTECTED] BC> from the Linux KDC. Linux KDC understandably returns principal unknown. BC> Workstation tries again from its domain controller in AD_FOREST_A. This BC> time, it does get a referral ticket to AD_FOREST_B.
BC> However, after sending a krbtgt/[EMAIL PROTECTED] to the DC for BC> AD_FOREST_B, the DC returns KRB5KDC_ERR_POLICY. I cannot for the life of BC> me figure out why. It would seem that for some reason the DC has decided BC> it will not grant an SGT for cifs/[EMAIL PROTECTED] to BC> [EMAIL PROTECTED] I have checked the "allowed to authenticate" flag on BC> the computer object in the domain, and also tried changing the forest trust BC> to "domain-wide authentication". The same error persists. Turning on BC> Kerberos logging on the server does log the error in the event log, but BC> with no more information than I can get out of Ethereal.
BC> So to summarize, the workstation can follow the referral chain down to the BC> target forest, but the DC mysteriously refuses to grant the requested SGT.
BC> ---UMICH-referral-patched krb5 1.3.1 in setup described above--- BC> The user's workstation again tries to get a referral for BC> cifs/[EMAIL PROTECTED] from the Linux KDC. Linux KDC, now patched to do BC> so, give the workstation a referral ticket for AD_FOREST_A.
BC> However, the rest is the same as before. After successfully climbing down BC> the referral chain, the workstation still gets a a mysterious BC> KRB5KDC_ERR_POLICY from DC for AD_FOREST_B.
BC> ---Same setup, but now with an additional trust directly from AD_FOREST_B BC> to MIT_BASED_REAM with the addition registered in [domain_referrals] in BC> kdc.conf--- BC> Here, when the workstation goes for a referral ticket from the Linux KDC, BC> it gets a referral straight to the AD_FOREST_B domain. For some reason, BC> this referral ticket is good enough for the DC, which then grants an SGT BC> for cifs/[EMAIL PROTECTED]
BC> That done, the user's workstation then sends the SGT off to the server. BC> The server accepts the SGT. However, a few packet exchanges later, the BC> workstation tries to call NetShareGetInfo on \\server\sharename, and the BC> server returns access denied. I cannot find any information as to why BC> access is denied. All the permissions that should be there are there (a BC> fact that can be verified by using the user's "real" non-mapped account). BC> I have tried opening up every conceivable access control setting and BC> policy, to no effect. Auditing everything in sight returns no useful BC> information.
BC> To summarize this failed attempt, authentication succeeds, but for some BC> reason I don't understand, authorization fails.
BC> So, in conclusion, does anyone have any idea why what I'm doing does not BC> work? Has anyone tried this before? Is anyone still reading this?
BC> Thanks, BC> Ben Creech BC> NCSU ITECS
BC> ________________________________________________ BC> Kerberos mailing list [EMAIL PROTECTED] BC> https://mailman.mit.edu/mailman/listinfo/kerberos
- -- Best regards, Karl mailto:[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE----- Version: PGP 6.5i
iQCVAwUBP6Ufwn5l5J8I3iJJAQFUIgP/TnyZ4KuiUDEq4w3at6Mvn8UndqQYG06r zxqTTK/AJagaZoRU7o7lETOia6xYE7uJVRwN6clsmNpxB/E8YNstdHydwgkIl8Ro TX4cBVnN/k/Zr3CP8AdDKELpfnJAxbJCMIT2rty/iZ3kGrYK329Vzj+2k+uSXYZC 4HYyr85QqWc= =Dwb0 -----END PGP SIGNATURE-----
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
