UW NetIDs

Kerberos cross-realm trust

Windows 2000 or later supports kerberos authentication. It even supports interoperability between non-Microsoft key distribution centers (KDCs). Your standalone Windows workstation can authenticate to an existing non-Microsoft kerberos realm, or you can map a Windows account in a Windows domain to a kerberos principal in an existing non-Microsoft kerberos realm (this is commonly called cross-realm authentication). This latter option allows the Windows account to be manipulated for management purposes (like group policy, home directory, etc.), while the user logs in with their UWNetID account name and password. Both of these options are described in this MS case-scenario whitepaper and this MS how-to whitepaper.

Any UW-affiliated Windows domain/forest can request a kerberos trust and configure cross-realm authentication; the UW forest has no special status with regard to interacting with the u.washington.edu kerberos realm.

To configure cross-realm authentication, you need:

• A kerberos trust
• To configure workstations so they know about the external kerberos realm (and its KDCs)(a simple registry mod)
• To set the altSecurityIdentities attribute to the foreign principal for each Windows user account

Limitations

Setting up cross-realm authentication is *not* a single-sign-on solution for Windows users. There are a number of limitations:

• Using a cross-realm authentication you won't have access to any Windows services that don't support kerberos. Many services only understand NTLM authentication. These services are not definitively enumerated anywhere, but they include SAMBA, the Mac UAM client, and Outlook to Exchange. A workaround is to manually keep the Windows account password & the UWNetID password in sync, but that could be pretty messy from a support standpoint.
• The Microsoft kerberos ticket cache is not the same as the ticket cache for any other vendor (like the MIT ticket cache). There are utilities that will manually sync these, but that could get messy too. The bottom line is that your authentication won't mean anything outside of Windows services.

How-to

Step 1-Setup Kerberos trust:

Contact win2kinfo@u.washington.edu to request a Kerberos realm trust. The domain administrator will be sent a password to complete the trust setup. Once you have the password, the following steps will complete the setup of the trust:

1. Connect to the domain with admin rights.
2. Open Administrative Tools->Domains & Trusts.
3. Right click on your domain and choose Properties.
4. Select the Trusts Tab.
5. Click the 'New Trust...' button.
6. Enter u.washington.edu in the domain box (MUST BE LOWERCASE).
7. Select 'Realm trust' and Next.
8. If there are other resource domains in your forest, choose transitive. Otherwise, choose nontransitive. And Next.
9. Choose 'One-way: outgoing' and Next.
10. Enter the password given to you by the NOC after you've contacted win2kinfo@u.washington.edu and Next.
11. Click Next to create the trust. You should be told that the trust was successfully created. If not, retry steps 5-11. If this still fails, contact win2kinfo@u.washington for a different realm trust password.

Step 2-Configure u.washington.edu realm info:

Every computer in your domain needs to be told who the KDCs are for the u.washington.edu realm. There are three methods you can use to configure a computer with this info.

• Method 1-KSETUP:

  KSETUP is a utility included with Windows 2000 Support Tools. Windows 2000 support tools can be installed from the Windows 2000 distribution media, in the \SUPPORT\TOOLS folder. Running the following commands will configure your computer to recognize the u.washington.edu realm. You must restart the computer for the changes to take effect.

  KSETUP /addkdc u.washington.edu k5-kdc1.u.washington.edu

  KSETUP /addkdc u.washington.edu k5-kdc2.u.washington.edu

  Here is a description of ksetup.

• Method 2--Modify Registry:

  Use this .reg file either manually by double-clicking it, or in a login script to modify the registry.

  Alternately, you can make the same modifications that KSETUP does manually by editing the computer's registry. Use REGEDT32 (multi strings cannot be added with REGEDIT) to add the following key and value:

  Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
    Control\Lsa\Kerberos\Domains\u.washington.edu

  Values: (under above key)

  k5-kdc1.u.washington.edu (REG_MULTI_SZ)
  k5-kdc2.u.washington.edu

  After modifying the registry, you must reboot the computer for the changes to take effect.

• Method 3--Group Policy:

  You can use this MSI package to install the required registry key values. This package can be assigned to workstations using group policy. This would most likely be the best and easiest way to distribute the change to all your domain's workstations and member servers. For more information on using group policy please see Microsoft's Windows 2000 technical resources.

Step 3 - Set the altSecurityIdentities attribute on each user:

• Method 1-Manual entry

  • Start the Directory Management tool. Point to Programs, then Administrative tools, and then Active Directory Users and Computers.
  • Start advanced features by clicking View, and then Advanced Features as shown below.
  • Locate the account to which you want to create mappings, and right-click to view Name Mappings.
  • Click the Kerberos Names mappings tab.
  • Add a principal from the u.washington.edu realm. The example shown below uses ryanc@u.washington.edu .
  
  

• Method 2-Automated script

  If you would prefer, you can automate the process using your own scripts or installation package. Below is an example script to accomplish this:

  Dim oUser As IADsUser
  Dim oRootDSE As IADs
  Dim strTranslate As String
  Dim strDomain As String
  Dim strUserName As String
  Dim nto As New NameTranslate
  On Local Error Resume Next
  ' Replace DOMAIN with the NETBIOS name of your domain
  ' Replace USER with the user name
  strDomain = "DOMAIN"
  strUserName = "USER"
  ' Converting a NETBIOS style name to the LDAP style.
  nto.Init ADS_NAME_INITTYPE_GC, ""
  nto.Set ADS_NAME_TYPE_NT4, (strDomain & "\" & strUserName)
  strTranslate = nto.Get(ADS_NAME_TYPE_1779)
  ' Bind to the user object via LDAP
  Set oUser = GetObject("LDAP://" & strTranslate)
  ' Set the altSecurityIdentities Kerberos property
  oUser.Put "altSecurityIdentities", "Kerberos:" & strUserName & "@u.washington.edu"
  oUser.SetInfo
  Set oUser = Nothing
  Set nto = Nothing
  

Step 4 - Using the cross-realm authentication:

• On a computer that has been configured to know about the u.washington.edu realm, u.washington.edu will appear on the list of domains under "Log on to:" in the Windows logon dialog. Simply choose the u.washington.edu domain, enter a UWNetID and password, and the computer will automatically logon to any Windows account in your domain that has that mapping setup for it. Special account settings like home directories and user-directed group policies will be applied.

Gotchas

Recognize that when you use cross-realm authentication that each user has two passwords that are not automatically in sync. Logging in with uwnetid@u.washington.edu authenticates against the UWNetID password on the UW KDCs, whereas logging in with uwnetid@yourdomain.washington.edu goes against the password local to your domain controllers (the Windows password). If you want to use only Kerberos authentication-i.e. you don't have any NTLM-only services-then don't tell users their Windows password, and set that password to be a random long string.

When you create the trust using lowercase u.washington.edu, Windows 2003 warns you that it needs to be in uppercase or it won't work. If you allow Windows to change the domain to all uppercase, the trust will not work. You must NOT follow the MS wizard dialogue's suggestion.

If you do have problems getting the Kerberos cross-realm trust to work, one of the first things you'll want to do to troubleshoot is to turn on Kerberos logging via q262177.

Note that if you want to use cross-realm authentication across an external domain trust (i.e. not a forest trust, but a NTLM "NT4 style" trust), the @u.washington.edu password and the @yourdomain.washington.edu password must match or you won't be granted access to resources in the external domain. Microsoft sends the @u.washington.edu MIT password hash in response to the challenge/response from the services in the external domain. UW Technology has investigated this behavior with Microsoft PSS, and Microsoft has called this behavior "by design". The same scenario with a forest trust instead of an external domain trust works fine without sync'd passwords.

If you use cross-realm authentication, don't sync passwords, and have a domain password expire, cross-realm authentication will break.

Accessing a resource using a path of "\\<IP address>\<sharename>" relies on NTLM authentication instead of Kerberos. Using the format "\\<Server NetBIOS name>\<sharename>" or "\\<Server FQDN>\<sharename>" will use Kerberos for authentication. If you aren't syncing passwords, this can cause problems.

When logged in as user@u.washington.edu, if the user chooses to change their password, the password change is sent to the u.washington.edu KDCs. It must meet the password complexity requirements set there. A successful password change means the uwnetid password has been changed. The user@yourdomain.washington.edu password (i.e. the Windows password) is *NOT* changed. The user would need to login as user@yourdomain.washington.edu to change that password.

If your computers have hostnames that don't match the DNS suffix of your domain, then you'll need to consult http://support.microsoft.com/?id=258503 to adjust your domain to allow computers to update their own dnsHostName and servicePrincipalName attributes (SPN). These two attributes affect whether kerberos works properly or not. Failing to have correct values in these attributes can mean that kerberos doesn't work to/from those computers.

If a user possesses an account (of the same name) in multiple domains in the same forest along the Kerberos trust path, and each account has altSecurityIdentities mapped, then the account closest to the MIT realm will be used for pass-thru logons.