--On Saturday, May 27, 2006 9:59 AM -0700 Joey Seifert <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
