I've installed MIT Kerberos 1.10 on a Debian server and happily have my Debian clients authenticating with it. I'm having some trouble getting my Windows 7 machine to do the same, however.
ksetup to configure the machine as follows:
default realm = EXAMPLE.COM (external) EXAMPLE.COM: (no kdc entries for this realm) Realm Flags = 0x5 SendAddress Delegate Mapping all users (*) to a local account by the same name (*).
This also changed the system's name and workgroup settings:
Computer name: lysander Full computer name: lysander.EXAMPLE.COM Workgroup EXAMPLE.COM
According to the documentation, if there are no KDC or password entries for a realm, Windows will use the DNS, so I also have the following entries configured:
_kerberos._udp.example.com. 300 SRV 10 100 88 kdc.example.com. _kerberos-adm._tcp.example.com. 300 SRV 10 100 749 kdc.example.com.
kdc has an A record that points at the server's IP address.
After configuring the Windows system I rebooted it and tried to log in, noting that the login screen offered to log me into the
EXAMPLE domain. However, when I attempt to log in as the local user
sam, which should be mapped to
sam@EXAMPLE.COM, after a brief pause I am told that there are no logon servers available to service the logon request. I can't see anything relevant in the Windows event log, and having examined the network traffic between the client and the server, I can't even see that the Windows machine is trying to contact the KDC.
It's not all bad news, however. What gives me hope is that I can use
runas to get a
>runas /user:sam@EXAMPLE.COM cmd Enter the password for sam@EXAMPLE.COM: Attempting to start cmd as user "sam@EXAMPLE.COM" ...
And in the new window that appears:
>klist Current LogonId is 0:0x14e6649 Cached Tickets: (1) #0> Client: sam @ EXAMPLE.COM Server: krbtgt/EXAMPLE.COM @ EXAMPLE.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 2/14/2012 11:54:24 (local) End Time: 2/14/2012 21:54:24 (local) Renew Time: 2/21/2012 11:54:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96
If I then launch PuTTY from that command prompt, I can ssh into the other servers using SSPI to authenticate just fine!