Resource access across forest trusts with pass-through realmauthentication

Matt Smith matt.smith at uconn.edu
Mon Nov 3 11:44:30 EST 2003


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/servername at domain), 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 
> <kowallis at alum.mit.edu> 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/server at FOREST_B.  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/server at AD_FOREST_B
>> 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/AD_FOREST_B at AD_FOREST_A 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/server at AD_FOREST_B to
>> BC> user at MIT_BASED_REALM.  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/server at AD_FOREST_B 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/server at AD_FOREST_B.
>>
>> 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           Kerberos at mit.edu
>> BC> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>
>> - --
>> Best regards,
>>  Karl                            mailto:kowallis at alum.mit.edu
>>
>> -----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           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 



More information about the Kerberos mailing list