Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 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 TGT:

>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!

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

I discovered that if I enter the full username sam@EXAMPLE.COM 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 sam@EXAMPLE.COM 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 sam@EXAMPLE.COM.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.