Resource access across forest trusts with pass-through realm authentication
Ben Creech
bpcreech at eos.ncsu.edu
Mon Nov 3 10:02:51 EST 2003
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-----
>
More information about the Kerberos
mailing list