Resource access across forest trusts with pass-through realm authentication

Ben Creech bpcreech at eos.ncsu.edu
Mon Nov 3 11:53:16 EST 2003 

Ok, looking at the packet sizes, it's evident that in one of the failing 
scenarios, the PAC data is not being inserted by the DC.  This still 
doesn't explain the first one.  See below for what I mean, along with 
packet traces.

<http://www4.ncsu.edu/~bpcreech/passthru/#traces>


--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