[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

inter-Windows 2003/non-Windows Kerberos realm referrals [Re: Single DNS domain for Multiple Kerberos V5 Realms ?]



On Fri, Sep 16, 2005 at 09:58:13AM -0500, Douglas E. Engert wrote:

> But there is:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-06.txt
> 
> which allows a client to ask the user's KDC for a service ticket. If the KDC
> can't do it, the KDC will refer the client to the realm the KDC thinks the 
> server
> is in. The client will then try that realm.
> 
> Windows clients and the Windows AD can do this, where all the realms in 
> question
> are in the forest. The KDC uses the Global catalog to look up the realm of 
> host.
> (SSPI on windows knows how to use this.)

just thought i would document some recent experience with this, since
i haven't seen it explicitly noted anywhere else when i went searching
for it and since a heavyweight Kerberos guru evidently does not know
about it either (or maybe was just being mercifully succinct)[0]. if you
don't care about Active Directory interoperability etc., please ignore
this

if you aren't using MIT Kerberos for Windows and just have Microsoft
stuff on your clients and other Windows boxen, you can cook up something
like the following, so long as your Active Directory forest is running at
the ``Windows 2003 functional'' level, to get AD-forest-to-UNIX-Kerberos-
realm referrals:

we wanted to be able to refer members of our Windows 2003 Active Dir-
ectory, single-domain forest to our UNIX-hosted, Heimdal 0.6.x realm.
e.g.,

1. Win XP client: IE wants to get https://www.unix.example.com/ and
   IE's policies are set up to allow integrated authentication (or
   whatever it's called) to any service in *.example.com

2. IE asks adc1.win2003.example.com for ticket for
   HTTP/www.unix.example.com@WIN2003.EXAMPLE.COM

3. adc1.win2003.example.com returns a referral response with a cross-
   realm TGT for krbtgt/UNIX.EXAMPLE.COM@WIN2003.EXAMPLE.COM

4. XP client uses cross-realm TGT to ask kdc1.unix.example.com for
   ticket for HTTPS/www.unix.example.com@UNIX.EXAMPLE.COM

5. XP client does authentication with these credentials with the web
   server on www.unix.example.com, which is running mod_auth_kerb
   (http://modauthkerb.sourceforge.net/)

to do this,

- on the XP client

  1. ksetup.exe /addkdc UNIX.EXAMPLE.COM

     where not specifying the KDC's explicitly means that XP will use
     DNS SRV lookups to find a KDC. you can explicitly configure, of
     course, if you prefer

  2. optionally, add realm flags:

     ksetup.exe /addrealmflags UNIX.EXAMPLE.COM tcpsupported delegate

- on UNIX

  1. heimdal/kadmin> ank krbtgt/UNIX.EXAMPLE.COM@WIN2003.EXAMPLE.COM

     and give it a suitable password and other properties

  2. optionally,

     heimdal/kadmin> ank krbtgt/WIN2003.EXAMPLE.COM

     if you are going to make the trust two-way and have WIN2003
     trust UNIX. give it the same password, if you are going to do
     as below and use the /twoway option. (i'm not sure you can do
     otherwise)

- on Windows 2003, assuming you are doing the two-way, single-pass-
  word trust set-up, and that you have the relevant privileges via
  your current Windows logon token to do the following:

  1. netdom.exe trust WINDOWS.EXAMPLE.COM /add /domain:UNIX.EXAMPLE.COM ^
  	/realm /twoway /passwordt:the_suitable_password

  2. optionally,
  
     netdom.exe trust WINDOWS.EXAMPLE.COM /domain:UNIX.EXAMPLE.COM ^
  	/transitive:yes

  3. netdom.exe trust WINDOWS.EXAMPLE.COM /domain:UNIX.EXAMPLE.COM ^
  	/foresttransitive:yes

     if this gives you an enigmatic error, maybe your forest isn't
     at the Windows 2003 functional level, or maybe you are trying
     to configure this on a non-forest-root domain

  4. netdom.exe trust WINDOWS.EXAMPLE.COM /domain:UNIX.EXAMPLE.COM ^
	/addtln:unix.example.com

     this is where you're adding the [domain_realm]-ish stuff to the
     Active Directory, so continue to add as required.
	     netdom.exe help trust | more
     will give you more info on how to enable and disable and exclude
     domains

  5. netdom.exe trust WINDOWS.EXAMPLE.COM /namesuffixex UNIX.EXAMPLE.COM

     should list something like
        Name, Type, Status, Notes
     1. *.unix.example.com, Name Suffix, Enabled

  the carets/circumflexi at the ends of the above lines indicate line-
  continuation

- if you want the integrated web authentication stuff to work, you have
  to configure your IE security policy or whatever browser you're using.
  (for IE, search for the section beginning ``Client Side'' in
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/http-sso-1.asp
  )

- if you want to try to SSH to a server in UNIX.EXAMPLE.COM that supports
  GSSAPI-Kerberos V5-mechanism user authentication, one that works with
  just the above set-up is http://rc.vintela.com/topics/putty/

if you check out that netdom.exe help info, you'll see there's lots of
special-casing for non-Windows stuff, so many thanks to the Microsoft-
niks who added all these hooks

apologies in advance for any of the foregoing that i messed up or any
missing ingredients or provisos[1]

---------------
[0] although this belongs on some sort of howto page out there on the
    net, i figure google should be able to pull it out of the mailing-
    list archive web sites, until somebody dresses up something pret-
    tier and more correct and gives it a home of its own. likewise, if
    Stuff Changes and it ends up becoming obsolete, well, the fact
    that it's from an archive should be a warning to that effect

[1] in that sense, it'd be better if somebody took it upon him-/herself
    to maintain a howto. please feel free to incorporate any of this you
    find worthwhile, if that would be you, although that's not induce-
    ment to abuse anybody's trademarks or anything i shouldn't have done