Ben- Have you correctly mapped an AD account to a Kerberos Principal? As Karl below points out, the PAC is necessary, and this information comes from an AD account that is mapped to your Kerberos Principal.
http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp Although I have not done a cross-forest trust in 2003, which should, in theory, work (since 2003 supports Kerberos for cross-forest trust, where 2000 only supported NTLM, I believe), I have done this numerous times for a single 2000 AD forest. I do not know, however, if the 2003 cross-forest trust implementation will support transitive trust, or if each realm will still need an explicit trust. -Matt Ben Creech wrote: > The thing is, in every case where the authentication or authorization > fails, the Windows server (be it file server or DC) is balking at a > ticket generated by ANOTHER Windows server. I would think that the DC's > would (or should?) add the Microsoft-specific PAC data to the tickets > once the authentication path goes through a Windows domain. > > 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 > ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
