Home / server / Questions / 359949
Accepted
Sam Morris
Asked: 2012-02-15 04:34:01 +0800 CST

Windows 7 system won't talk to MIT Kerberos server

  • 772

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.

I've used 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 [email protected], 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 TGT:

>runas /user:[email protected] cmd
Enter the password for [email protected]:
Attempting to start cmd as user "[email protected]" ...

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!

windows kerberos mitkerberos

1 Answers

  1. Best Answer

    I discovered that if I enter the full username [email protected] at the Windows screen then logging on works fine; sam or EXAMPLE\sam don't cut the mustard. I can't find anything that confirms that this is the expected behaviour, but it is consistent with a careful reading of the output of ksetup:

    Mapping all users (*) to a local account by the same name (*).

    i.e., if you log in as [email protected] then the local account sam will be logged in; this does not imply that you can log in as sam and have the system authenticate you with the KDC as [email protected].

    • 2