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