MIT Kerberos cross realm authentication with Windows Active Directory

Douglas E. Engert deengert at anl.gov
Mon Nov 24 11:50:39 EST 2008



Duffey, Blake A. wrote:
> Thanks for your reply Douglas.  Sorry if I was unclear, I'll try to clarify.
> The user ID exists in AD.  The resources I want to access exist in the MIT
> realm.  I log on to my Windows 2003 server using an ID/password which exists
> in AD (effectively it is ADDOMAIN\user).  I have a one-way trust between my
> AD and my MIT realm (the user blake at ADDOMAIN is mapped to blake at MITream
> under NAME MAPPINGS in AD).  As I understand it this is the correct way to
> handle SSO when the users are in the AD and the resources are in the MIT
> realm. 

This might be the problem. The user principals are not needed in the MIT realm
and the name mappings are not need in AD. Only the service principals are in the
MITrealm.  The name mappings in AD were to allow AD to use an external
Kerberos realm for authentication. Some sites had preexisting Kerberos realms
before AD, and wanted to continue to use the Kerberos realm for authentication,
but use AD only for authorization. So if AD saw a request for a cross realm
ticket from an MIT user, it could map this to a local account
in AD and could add the PAC to the cross realm TGT.


> If there is a better way I'd love to hear it.
> 
> I am using a PuTTY which uses the MS SSPI, as well as Firefox configured to
> use SSPI, as well as IE (so everything is coming from the registry as
> configured by ksetup).  I don't even have Kerberos for Windows installed
> (although I am open to that if I can get this working).
> 

So the user at ADDOMAIN has a ticket for krbtgt at ADDOMAIN, and when ittries to get
a ticket for: host/bobo.mit.realm the client lib has to figure out what realm
the host is in. Once it figures out the realm is MITrealm,  the lib then needs
to get a cross realm TGT:  krbtgt/MITrealm at ADDOMAIN  from AD. This TGT can then
be used to get the service ticket for host/bobo.mit.realm at MITrealm from the MITrealm.

The issue is how does the client lib determine the realm of bobo. The Microsoft
SSPI can use "referrals" to ask user's AD what realm. The SSPI can also be passed
the realm, as SSPI can be passed "host at bobo.mit.realm@MITrealm" It might now
be able to use the registry HostToRealm.

When we were running an AD and MIT realm like you, the MIT client lib code on
the other hand did not understand referrals, or the HostToRealm registry, but
used the krb5.ini [domain_realm] section. ("referrals" are being added.)
And the gssapi name routines could only accept "host at bobo.mit.realm"

We also used a PuTTY that could use either SSPI or the MIT gssapi, and
the PuTTY had a option for providing the server realm to pass to SSPI.

But today the users and servers are all defined in AD, and we don't have an
external MIT realm.

If you have not seen the W2000 document on Kerberos and Windows interoperability,
it is worth reading as it covers a lot of these issues.
http://technet.microsoft.com/en-us/library/bb742433.aspx


> Yes, those are obfuscated.  "bobo" is the name of the resource machine.  The
> DNS name of the resource server matches the realm name, yes.  The names of
> the AD domain and MIT resource realm are not the same, however.  I haven't
> tried an XP machine as my current production configuration demands a server
> (it is a terminal services configuration).
> 
> 
> I appreciate any insight that can be provided.
> 
> -----Original Message-----
> From: Douglas E. Engert [mailto:deengert at anl.gov] 
> Sent: Friday, November 21, 2008 4:51 PM
> To: Duffey, Blake A.
> Cc: kerberos at mit.edu
> Subject: Re: MIT Kerberos cross realm authentication with Windows Active
> Directory
> 
> 
> 
> Duffey, Blake A. wrote:
>> I have encountered a peculiar problem and would like to know if anyone 
>> has seen it (or can duplicate it) and has a work around.
>>  
>> I have a cross-realm trust between a Windows 2008 Active Directory and 
>> an MIT Kerberos Realm.  The resources (apache, sshd, postgresql) are 
>> in the MIT realm and the users are in the AD (at the moment this setup 
>> cannot be changed).
>>  
>> While my domain controller is Windows 2008, my current 'client' is a 
>> Windows
>> 2003 server. 
> 
> You mean the client machine is W2003, but the Kerberos "client" is a user in
> AD?
> 
>>  When I boot the server and logon using a domain ID,
> 
> Do you give DOMAIN\user or user at DOMAIN or user at MITrealm or just user?
> Can you try other combinations?
> 
> 
>> the cross
>> realm works great.   I log on with an AD account (which is mapped to a
>> Kerberos princ in the MIT realm)
> 
> But you said the user's were in AD.
> 
> So why did you map the princ to the MIT realm?  This would only be used if
> the user's were in the MIT realm if you did not want AD to do the Kerberos
> AS processing but have the user get the TGT from the MIT realm.
> Are you sure you want to do the princ mapping?
> 
> 
>>  and connect using Kerberos-aware clients (putty, Firefox, IE) to 
>> resources in the MIT realm.
> 
> Which PuTTY? Is putty using the MS SSPI or the GSSAPI from MIT Kerberos For
> Windows? i.e. what kerberos libs and which krb5 configuration is being used
> to get the service ticket, krb5.ini or the Registry as set by ksetup?
> 
>> Doing a network
>> capture, I see my client send a request for the tgt to my domain 
>> controller, I get the correct ticket which is then passed along, and all
> is well.
>>  
>> If I log off, and then log back on as the same user (or the screen 
>> locks, which on Windows clears the Kerberos cache), the cross realm does
> NOT work.
>> (in fact, my network capture shows my client asking for 
>> host/bobo.mit.realm at MIT.REALM rather than the tgt).
> 
> I assume these are obfuscated names. Does the real DNS name match the MIT
> realm name? Is bobo the name of your "client" Windows 2003 server or the
> name of resource machines?
> 
> 
>   I have replicated this
>> on different servers and on different AD domains.  This is a standard 
>> Windows 2003 server install, I have just used ksetup to set the KDC 
>> for the MIT realm and implemented a registry hack (see below).
>>  
>> If I use a Windows 2008 server as my client, it works perfectly.  The 
>> 'ksetup' program in Windows 2008 has a switch called 'AddHostToRealmMap'
>> which does what it sounds like.  (I believe this acts like the 
>> krb5.conf settings under the [domain_realm] section).  This switch 
>> doesn't exist in the Windows 2003 version of ksetup, but MS claims I 
>> can add the registry keys thusly:  
>> http://technet.microsoft.com/en-us/library/cc738673.aspx
>>  
>> But it doesn't work after a log off and it doesn't work after a screen
> lock.
>> If I reboot the machine and log in, it all works again.  I am baffled 
>> by this behavior and, since I can't be the first person to try to 
>> implement this scenario, would love to hear if anyone has any insight.
>>  
> 
> Does this work in an XP client machine?
> 
>> Thanks and I appreciate your time.
>>  
>> Blake
>>  
>>  
>>  
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



More information about the Kerberos mailing list