Search | Directories | Reference Tools
UW Windows Infrastructure Service banner image
Skip Navigation LinksUW Home > IT Connect > Services > UW Windows Infrastructure > Getting Started: Windows Domains > UW NetID Integration > Cross Realm Kerberos

Kerberos Cross-Realm Trust

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 UW NetID 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.

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 others. A workaround is to manually keep the Windows account password & the UW NetID 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 help@uw.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 help@uw.edu 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-primary.u.washington.edu

    KSETUP /addkdc u.washington.edu k5-backup.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 Regedit (REGEDT32 if on an older Windows OS) to add the following key and value:

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

    Value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
      Control\Lsa\Kerberos\Domains\u.washington.edu\KdcNames (REG_MULTI_SZ)

    Values to set:

    k5-primary.u.washington.edu
    k5-backup.u.washington.edu

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

  • Method 3--Group Policy:

    You can create your own 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. UW-IT no longer provides a current MSI package for this method.

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 UW NetID 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 UW NetID@u.washington.edu authenticates against the UW NetID 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. Conversely, in the MIT Kerberos realm, the Windows Kerberos realm *MUST* use UPPERCASE.

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. The UW 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 UW NetID 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.