Windows Xp authentication to MIT KDC

[Quanah Gibson-Mount]

--On Saturday, May 27, 2006 9:59 AM -0700 Joey Seifert 
<jseifert at microsoft.com> wrote:

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

Thanks for the reply.  Other than the "guest" mapping in step #4, none of 
these steps differ from what I already did.  As you can see from the logs I 
supplied from my KDC, the host keytab is aleady set up, and both the 
windows box & the KDC are happily talking to one another, as the KDC logs 
me getting a tgt.  I simply cannot log into my system.  Is the "guest" 
mapping required?  I'd thought that my two mappings I already have defined 
would cover things:


Mapping all users (*) to a local account by the same name (*).
Mapping quanah at stanford.edu to quanah.


And yes, our K5 domain name is lower case. ;)


--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html