5

I've been wracking my brains trying to get Windows 7 authenticating against a MIT Kerberos 5 Realm (which is running on an Arch Linux server).

I've done the following on the server (aka dc1):

  • Installed and configured a NTP time server
  • Installed and configured DHCP and DNS (setup for the domain tnet.loc)
  • Installed Kerberos from source
  • Setup the database
  • Configured the keytab
  • Setup the ACL file with: *@TNET.LOC *
  • Added a policy for my user and my machine:
addpol users
addpol admin
addpol hosts
ank -policy users tom@TNET.LOC
ank -policy admin tom/admin@TNET.LOC
ank -policy hosts host/wdesk3.tnet.loc -pw MYPASSWORDHERE

I then did the following to the windows 7 client (aka wdesk3):

  • Made sure the ip address was supplied by my DHCP server and dc1.tnet.loc pings ok
  • Set the internet time server to my linux server (aka dc1.tnet.loc)
  • Used ksetup to configure the realm:
ksetup /SetRealm TNET.LOC
ksetup /AddKdc dc1.tnet.loc
ksetip /SetComputerPassword MYPASSWORDHERE
ksetip /MapUser * *
  • After some googl-ing I found that DES encryption was disabled by Windows 7 by default and I turned the policy on to support DES encryption over Kerberos
  • Then I rebooted the windows client

However after doing all that I still cannot login from my Windows client. :(

Looking at the logs on the server; the request looks fine and everything works great, I think the issue is that the response from the KDC is not recognized by the Windows Client and a generic login error appears: "Login Failure: User name or password is invalid".

The log file for the server looks like this (I tail'ed this so I know it's happening when the Windows machine attempts the login): Screen-shot: http://dl.dropbox.com/u/577250/email/login_attempt.png

If I supply an invalid realm in the login window I get a completely different error message, so I don't think it's a connection problem from the client to the server? But I can't find any error logs on the Windows machine? (anyone know where these are?)

If I try: runas /netonly /user:tom@TNET.LOC cmd.exe everything works (although I don't get anything appear in the server logs, so I'm wondering if it's not touching the server for this??), but if I run: runas /user:tom@TNET.LOC cmd.exe I get the same authentication error.

Any Kerberos Gurus out there who can give me some ideas as to what to try next? pretty please?

tommed
  • 289
  • 1
  • 3
  • 10

4 Answers4

3

Check out pGina. It doesn't have a Kerberos plugin, so you'll have to write one. Alternatively you can use OpenLDAP as a proxy and use the pGina LDAP plugin.

ptman
  • 27,124
  • 2
  • 26
  • 45
  • Yes thanks that's what I've ended up doing. The reason my method above didn't work was because Microsoft clients require a custom footer in the Kerberos ticket. When the ticket is returned from MIT Kerberos, this footer is missing and the client says login has failed. Damn M$ and their non-standard ways! :( Have Kerberos login working nicely now with Kerberos 5, thanks! :) – tommed May 03 '10 at 07:24
  • 1
    Please mark the question as answered, I was going through the list of unanswered questions when I stumbled on this. – ptman May 03 '10 at 08:54
2

Apparently AD is absolutely required if you have Windows clients as the Windows clients require a small extension to the standard Kerberos ticket which AD appends.

MIT Kerberos Server cannot authenticate Windows clients on it's own at this time.

(Information retrieved on the MIT Kerberos Newsgroup)

tommed
  • 289
  • 1
  • 3
  • 10
1

@jyvenard - what tommed likely ended up doing was to use SSH or some other method to authenticate his box. If he used SSH (what I would probably do in this circumstance), then he likely has the host he authenticated against use kerberos.

In a Method like this:

[client] --ssh--> [host] --pam support for ssh--> [KDC server]

[client] <--ssh-- [host] <--success or failure-- [KDC server]

This uses kerberos to authenticate the user to his client system by attempting to ssh to a host that attempt to verify his credentials against a KDC, but a kerberos ticket is never actually acquired by the client, only a success or failure on the ssh session.

1

It is possible, but as the below document indicates, you will need to map local users to kerberos pricipals.

I suppose some form of a login script could be used to do this dynamically. Logging onto windows is a separate process. pGina may help with that, as indicated by ptman.

Using an MIT KDC with a Standalone Windows 2000 Workstation

For the Windows 2000 workstation to use a Kerberos KDC, you must configure both the Kerberos KDC server and the workstation as described next.

To configure the Kerberos KDC server and the Windows 2000 workstation

  1. Run the Ksetup utility to configure the Kerberos KDC server and realm (for details, see the Ksetup section later in this document).

    • In the Kerberos realm, create a host principal for the computer. Use the command:

    Kadmin q "ank pw password host/machine-name.dns-domain_name"

    For example, if the Windows 2000 workstation name is W2KW and the Kerberos realm name is REALM.RESKIT.COM, the principal name is host/w2kw.realm.reskit.com.

    Kadmin is a utility that is part of the MIT Kerberos distribution.

    • Since a Kerberos realm is not a Windows 2000 domain, the computer must be configured as a member of a workgroup. This is automaticwhen you set the Kerberos realm and add a KDC server as follows:
    C:> Ksetup /setdomain REALM.RESKIT.COM
    C:> Ksetup /addkdc REALM.RESKIT.COM kdc.realm.reskit.com
    • Set the local machine account password, as follows:
    C:> Ksetup /setmachpassword password

  2. Restart your computer for the changes to take effect. (This is a required step.) Whenever changes are made to the external KDC and realm configuration, a restart is required.

  3. Use Ksetup to configure single sign on to local workstation accounts. Define the account mappings; this will map local machine accounts to Kerberos principals. For example:

    C:> Ksetup /mapuser auser@REALM.RESKIT.COM guest C:> Ksetup /mapuser * *

    Note that the second command maps clients to local accounts of the same name.

  4. Use Ksetup with no arguments to see the current settings. (Note that the KDC server[s] is not shown.)

d-_-b
  • 1,104
  • 3
  • 11
  • 23