Windows Xp authentication to MIT KDC

Sat May 27 12:59:53 EDT 2006

The steps below should apply to Windows XP as well as Windows Server
2003.  I would also confirm the case of your realm.  Usually realms are
upper case.  If it is you should reconfigure your realm settings on the
XP client to match the case of the MIT realm.

SRV records are not a requirement.  As long as you define the FQDN of
the KDCs with the ksetup /addkdc command, you don't need SRV records but
you do need to be able to resolve the FQDN of the KDCs you specified.

Using an MIT KDC with a Standalone Windows Server 2003 Client
For the Windows Server 2003 client to use a non-Windows KDC, you must
configure both the non-Windows KDC and the Windows Server 2003 client as
described next.
To configure the MIT KDC server and the Windows Server 2003 client
1.	On the MIT KDC, create a host principal for the computer. Use
the command:

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

Note: After executing the above command you will be prompted to provide
a password.  Provide a complex password and make note of it. You will be
required to provide the same password in a subsequent command on the
Windows Server 2003 client.

For example, if the Windows Server 2003 client name is WS03SRV1 and the
primary DNS suffix of this computer is realm.reskit.com, the principal
name is host/ws03srv1.realm.reskit.com.

Kadmin is a utility that is part of the MIT Kerberos distribution.
2.	Run the Ksetup utility to configure the Windows Server 2003
client to be aware of the non-Windows KDC and realm.
	Since the MIT realm is not an Active Directory domain, the
computer will be configured as a member of a workgroup. This is
automatic when you set the Kerberos realm and add a KDC server as
follows: 

C:> Ksetup /setrealm 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 
Replace password with the password you supplied above in step 1.

3.	Restart your computer for the changes to take effect. (This is a
required step.) Whenever changes are made to the realm or domain
membership, a restart is required. 
4.	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 at REALM.RESKIT.COM guest 
C:> Ksetup /mapuser * * 

Note that the second command maps clients to local accounts of the same
name. 
5.	Use Ksetup with no arguments to see the current settings. 

--Joey

-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
Behalf Of Quanah Gibson-Mount
Sent: Friday, May 26, 2006 6:39 PM
To: kerberos at mit.edu
Subject: Windows Xp authentication to MIT KDC

Hi,

I'm trying to get my Windows XP system to allow me to auth to our MIT
KDC. 
However, I'm running into some difficulty.

So far, I have:

C:\Documents and Settings\quanah>ksetup
default realm = stanford.edu (external)
stanford.edu:
        kdc = kerberos1.stanford.edu
        kdc = kerberos2.stanford.edu
        kdc = kerberos3.stanford.edu
        Realm Flags = 0x0 none
Mapping all users (*) to a local account by the same name (*).
Mapping quanah at stanford.edu to quanah.

I've set up a host principal between my windows box and the KDC, and
that 
part seems to be working correctly, as the KDC issues me a ticket:

May 26 16:15:56 kerberos1 krb5kdc[1385]: AS_REQ (7 etypes {23 -133 -128
3 1 
24 -135}) 171.66.155.86: NEEDED_PREAUTH: quanah at stanford.edu for 
krbtgt/stanford.edu at stanford.edu, Additional pre-authentication required
May 26 16:15:56 kerberos1 krb5kdc[1385]: AS_REQ (2 etypes {3 1}) 
171.66.155.86: ISSUE: authtime 1148685356, etypes {rep=3 tkt=1 ses=1}, 
quanah at stanford.edu for krbtgt/stanford.edu at stanford.edu
May 26 16:15:56 kerberos1 krb5kdc[1385]: TGS_REQ (7 etypes {23 -133 -128
3 
1 24 -135}) 171.66.155.86: ISSUE: authtime 1148685356, etypes {rep=1
tkt=1 
ses=1}, quanah at stanford.edu for 
host/sw-90-717-287-3.stanford.edu at stanford.edu

However, my login fails with:

"Windows cannot connect to the domain, either because the domain
controller 
is down or otherwise unavailable, or because your computer account was
not 
found."

I think this is related to a lack of SRV records for our KDC, because
when 
I go into the properties for "My Computer" and tell it to join the 
"stanford.edu" domain, I get:

The following error occurred when DNS was queried for the service
location 
(SRV) resource record to locate a domain controller for domain
stanford.edu:

The erro was: "DNS name does not exist."
(error cdoe 0x0000232B RCODE_NAME_ERROR)

The query was for the SRV record for _ldap._tcp.dc_msdcs.stanford.edu

Common causes of this error include the following:

- The DNS SRV record is not registered in DNS.

- One or more of the following zones do not include delegation to its
child 
zone:

stanford.edu
edu
. (the root zone)

Trying to connect to the domain from the command line gives me:

C:\Documents and Settings\quanah>ksetup /domain stanford.edu
Connecting to specified domain stanford.edu...
CallAuthPackage failed, status 0x0, substatus 0x8009030e.
Ticket cache query failed.  Error 0x8009030e
Could not guess user's domain.
  Please specify domain on command line and try again.
/Domain failed: 0x8009030e.

Any thoughts on where I can go from here?  Are SRV records an absolute 
requirement with windows?

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos