Windows Authentication using UTORauth (AKA Kerberos)

This document was prepared by Terry Jones.

Windows Authentication using UTORauth


Server Setup

Here are the steps you should follow to set up the server that will be authenticating users.

Note: If you are setting up a test 2003 server, please ensure that the domain name and the workstation computer name are not the same. This may cause confusion for netbios.
  1. Install Windows Server 2003. It should be a Domain Controller.
  2. Register the server in the DNS so that it can be properly resolved by an external machine by name. For example, the test server I set up was called, the server name was test and the domain was called kdcw2k.
    Note: With Kerberos, accurate time is crucial. Make sure the server is in the correct time zone and make sure the clock is accurate. More than 5 minutes out and it will NOT work. NTP (Network Time Protocol) is a worthy suggestion!
  3. Install the Support Tools found on the Windows Server 2003 CD in \support\tools. This gets us the command line utility ksetup required later. You should be able to type ksetup at a CMD prompt and get some output if installed properly. You will Probably need a reboot to get the path set properly. In my test server typing ksetupreturned that the default realm was and there were no maps
  4. In Active Directory users and Computer you need to enable the Advanced Features. This is done inView>>Advanced Features. This will make Name Mappings available for later mapping kerberos names (UTORid’s) to Windows account names.
  5. In Active Directory Domains and Trusts you need to view the properties for the server (kdcw2k in my test server) and add a new trust. The trust name is UTORONTO.CA all in upper case. It is a Realm Trust, it is Non Transitiveand it is a One Way trust Outgoing. (we trust the UTORONTO.CA realm is what we are saying). This trust must be set up in co-operation with the I+TS Network Services group, that maintain the UTORONTO.CA Kerberos realm. They will add a “principal” for your server with the appropriate dns name for the server and they will set a trust password. You will use that I+TS provided password for that principal to create your trust.
    Note: For my testing we were using rather simple trust passwords and I was forced to disable the strict password rules on the Windows 2003 server. Now that we know it works, more complex passwords can be used for the trust to avoid having to relax the password rules. So far we have only been able to make the Kerberos authentication work in what is called single DES mode. For example, for my working test server the principal krbtgt/KDCW2K.CNS.UTORONTO.CA@UTORONTO.CA has the following key only:
    Key: vno 1, DES cbc mode with CRC-32, no salt
  6. You must tell the Windows server where to find the UTORONTO.CA Domain Controllers At a command prompt on the server type:
    	ksetup /addkdc UTORONTO.CA
    	ksetup /addkdc UTORONTO.CA
  7. As a test, I would recommend creating a generic test account on the server. For that account, you need to map a UTORid to it. In Active Directory Users and Computers, create the account and set a password for the account that DOES NOT match the password for your UTORid account that you will map to this user account. Once the account is created, right click on the account and select Name Mappings and add a mapping for the UTORid. For example in my test server I created a user called dirtball and in the name mapping I added sample@UTORONTO.CA
    Note: It is worth pointing out that you can map multiple UTORid users to a single Windows account name or you can map one to one.
  8. That completes the server side of the setup.

Workstation Setup

Once you have set up your server, you will need to set up each individual workstation to authenticate to your server

  1. On the Windows XP workstation you also need to install the Support Tools found in \support\tools on the XP setup CD. This again adds the command line ksetup functionality required.
  2. On the XP workstation you must tell it where to find the UTORONTO.CA kerberos domain controllers
    	ksetup /addkdc UTORONTO.CA
    	ksetup /addkdc UTORONTO.CA
  3. Join the workstation to your Windows Domain.

Now at this stage when you reboot the workstation you should have multiple options for logging into the workstation. You should be able to:

  • log into the local workstation if you have a local workstation account
  • log directly into your Windows domain if you have a valid domain account
  • log into the UTORONTO.CA domain using your UTORid and password.

You can log into the UTORONTO.CA domain in two different ways:

  1. select UTORONTO.CA from the domain drop-down and then type your UTORid as the username and your UTORid password for the password
  2. type your username directly in the username field as sample@UTORONTO.CA
Note: You may want to experiment with how settings are saved and whether credentials are cached on the workstation to enable or prevent logins when the UTORONTO.CA domain is unreachable. One way may allow a login using a cached credential but may allow a login after a mapping has been removed for a UTORid in the Windows domain. The other way may prevent logins when a mapping has been removed but will also prevent logins if the UTORONTO.CA kerberos domain controllers are unreachable. I did not fully explore this relationship. I simply bumped into this cached credentials issue and moved on. Your mileage may vary.

Populating the Active Directory Users

Once you have a working environment then you will want to populate the Active Directory with the users list and add all the required name mappings. You will need a list of UTORid’s. This can be arranged by contacting the I+TS group responsible for UTORauth. They will set up a scheduled extraction of the appropriate UTORid’s and make it available for download. Once downloaded you can script the rest.

The following code is VBS (ie put it in a file called makeuser.vbs for example) code that can be run to create 1000 users called UTORid1 UTORid2 UTORid3… and map the UTORid sample@UTORONTO.CA to each of the 1000 accounts. You can modify this to read from a list of UTORid’s that you want to grant access to the server as you see fit. You will note that it sets a password for the account (the password in this case is the same for all accounts and is:

	Set objRootDSE = GetObject("LDAP://rootDSE")

	Set objContainer = GetObject("LDAP://cn=Users," & _


	For i = 1 To 1000
		Set objUser = objContainer.Create("User", "cn=UTORid" & i)
		objUser.Put "sAMAccountName", "UTORid" & i
		objUser.Put "altSecurityIdentities", "Kerberos:sample@UTORONTO.CA"
		objUser.SetPassword ""
		objUser.Put "userAccountControl", &H200

	WScript.Echo "1000 Users created."

If you would like to download this sample script in a text file, please click here.

Note: You must set a password for each account but there is no need to use unique passwords and in fact there is no need to even know what the passwords are if you will never log into the Windows domain directly. You can set them to random passwords. Failure to set a password of some form leaves the account inactive. There are lots of resources for account management on the Microsoft site that will let you create and modify new accounts.

Windows 7 Authentication

Note: for the sake of brevity, the following registry entries are specified with HKLM\S\MW\CV\P substituted for:


Be sure to make the translation when you are editing these entries.

Windows 7 must be set to use 3DES encryption instead of the default AES encryption. On the workstation you need the following registry key:






The following website was used as a reference for this information:

Note: This is known to work when the server is Windows Server 208 SP2 64 bit, but has not been tested on R2 yet.

I+TS Contacts

Here are some contacts you may need. For questions about:

the Windows side of things: Terry Jones (416) 978-4924
the UTORONTO.CA Kerberos principal: (416) 946-8689
UTORauth and UTORid lists:

Notes and Tips

Here are a few observations/tips that may help you in the setup process.

  • After a user has logged into a workstation, if their credentials are cached on the workstation then they can still log in after the name mapping has been removed from the Active Directory. I suggest not caching credentials but you may have reasons to want this.
  • When debugging UTORid authentication the following may help. Examine the server event log files and then clear them if all looks well. Join the workstation to the domain and log into the domain using a regular domain account to make sure basic authentication is working, re-examine the event logs and clear them again. Log in using a UTORid and again examine the server event logs.
  • We have put up a page with some questions that have been asked about this process.

Things That Work

These are the things that are known to work.

  • Pubcookie obviously works, but also you can get IIS to prompt you with Windows authentication via the web browser. This works when IIS is set to Basic authentication.
  • Roaming profiles work after enabling the Computer policy setting “Allow Cross-Forest User Policy and Roaming Profiles” at Administrative Templates > Group Policy

Things That Don’t Work

There are a few things known not to work and we welcome any insight/solutions/suggestions.

  • You are supposed to be able to add name mappings from the command line using a ksetup command. Have not been able to get that to work
  • You are supposed to be able to map multiple users to one Windows logon using that same ksetup command using a wild card e.g. *@UTORONTO.CA
last updated 2008/10/22 20:35:12: v. 1.6