MIT Kerberos cross realm authentication with Windows Active Directory

[Duffey, Blake A.]

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.  When I boot the server and logon using a domain ID, the cross
realm works great.   I log on with an AD account (which is mapped to a
Kerberos princ in the MIT realm) and connect using Kerberos-aware clients
(putty, Firefox, IE) to resources in the MIT realm.  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 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.
 
Thanks and I appreciate your time.
 
Blake
 
 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 8271 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20081121/b20b5c1a/attachment.bin