Resource access across forest trusts with pass-through realm authentication

[Karl Kowallis]

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