Search Google Appliance

Home >> Iam >> Kerberos >> Oxford SSO Integration of AD via a Cross-Realm Trust

Oxford SSO Integration of AD via a Cross-Realm Trust

1. Overview

This document describes a procedure for integration of a local Active Directory domain (deployed within a University department or college network) with the OX.AC.UK Kerberos realm by way of a Cross-Realm Trust. This will allow users to access resources within the local AD domain using their Oxford SSO username and password.

The following instructions have been tested using Windows 2016 servers with Windows 7 (Enterprise) SP1 and Windows 10 (Enterprise) clients for the following use cases within the local domain:

  • Workstation logons
  • File and Print services
  • The application of Group Policies
  • IIS integrated authentication
  • Sharepoint 2010 authentication
  • SQL Server authentication

Other use cases may (and probably will) work as the fundamental capability to authenticate users via Kerberos is becoming widespread amongst Windows-based applications (and is indeed Microsoft's preferred mechanism for authentication in an AD environment).

The instructions have been developed from older instructions for Windows Server 2008 R2 AD installations, and should also work for that operating systems.

This procedure configures the Windows AD domain to trust the OX.AC.UK Kerberos realm (which contains all Oxford SSO users). The procedure include 5 main activities:

  • Obtain a Kerberos cross-realm principal for your Active Directory domain
  • Set a password for the principal
  • Configure domain controllers (DCs)
  • Map user principals to names
  • Configure domain members and workstations

2. Prerequisites

You will need:

  1. one or more Windows Server 2016 (also fully patched Windows Server 2012 or later) domain controllers, set up in line with Oxford University's Active Directory pages;
  2. to make sure that time is synchronised with an NTP source. For Kerberos to function properly, all participating hosts must be within five minutes of each other (by default). Point the PDC Emulator in your AD forest to the IT Services NTP servers to achieve this, using the w32time service, configured using this Microsoft authoritative time server configuration procedure.

3. The Procedure

3.1. Obtain a Kerberos cross-realm Principal

  • The Kerberos cross-realm principal (of the form krbtgt/ ADFQDN where ADFQDN is the fully qualified domain name of your Active Directory domain in upper case, for example 'krbtgt/IT.OX.AC.UK') can be requested via email to Be sure to specify the Kerberos principal you are requesting, and specify the /itss principals that should be granted administration rights over the requested principal.

3.2. Set a password for the Principal

When Sysdev create your Kerberos cross-realm service principal, they will also assign administration rights over it to the requested /itss principal(s) (of the form oxfordusername /itss) to enable you to set a password on the principal.

  • On a Linux/UNIX workstation that is suitably secure (since is a shared service it is not recommended for this), add the following to the [realms] section of your /etc/krb5.conf:
        OX.AC.UK = {
            kdc =
            kdc =
            kdc =
            kdc =
            admin_server =
  • Use the kadmin tool with the /itss principal as in the following example. The example uses a fictitious principal unit9999/itss, with a cross-realm principal for the fictitious 'Jordan College'. We tell kadmin the name of the kerberos admin server in the OX.AC.UK realm to connect to with the -s option. Keyboard input is underlined in red.
Setting the password and encryption type(s) for the principal

The above screenshot shows the /itss user authenticating, setting the password (and the encryption types) for the cross-realm principal using the cpw command, and then checking the current settings on the cross-realm principal using the getprinc command.

(Note: Do not worry if you see "Policy: crossrealm [does not exist]". Nothing has gone awry, it's just your /itss principal does not have permission to list the policies in our kerberos database).

The -e switch on cpw defines the encryption type. Since AES support was added in Windows Server 2008 it has become the preferred encryption type for the latest versions of Windows Server.

The list of currently-considered secure encryption types, for the convenience of copy/paste, is:

"aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal"

The image above also includes the rc4-hmac:normal encryption type.  This is only required by Windows XP clients, and is now considered to be insecure.

If you have an existing AD-MIT cross-realm trust and you are migrating your domain controllers to a later version of Windows Server, it is important you reset the password and the encryption types as above, and then remove and add the realm trusts again as in section 3.3. Configure Domain Controllers prior to introducing the new DCs. This is to ensure that the key encryption types remain secure and compatible.

NOTE: Make sure that you choose a very strong password, and keep it secure! You'll only need it to create the other side of the trust, so you're not going to need to use it very often. MIT recommend that the password should be at least 26 characters long and comprised of random ASCII. You should also ensure that it conforms to the strength requirements of your Windows system — this may mean three out of four categories of character (lower and upper case, numbers, and special characters).

3.3. Configure Domain Controllers

  • Configure the domain controller so that it knows about the Kerberos KDC servers. From a command prompt, use ksetup /addkdc ... to add the OX.AC.UK KDCs (invoking ksetup without arguments shows the current settings), as in the following example:


    Add OX.AC.UK KDCs to each domain controller

    The KDCs can be added in any order. Make sure you run the /addkdc commands on all your domain controllers.

  • Next we need to set up the realm trust:


    On your domain controller, run Active Directory Domains and Trusts. Right-click on your domain name, select Properties, and then select the tab labelled Trusts.


    Click on New Trust to open the New Trust wizard. Advance beyond the initial screen by clicking Next.


    When prompted for the Trust Name enter 'OX.AC.UK'.

     Trust Name

    Click on Next, and ensure that the trust type is set to Realm trust.

     Trust Type

    Click on Next. The next screen asks whether the trust should be transitive or non-transitive. If in any doubt choose Transitive as this is generally only likely to be important if you have more than one domain in your Active Directory forest - in which case transitive trust would also probably be the best option.

     Trust Transitivity

    Click on Next. Now you need to choose the direction for the trust. You should set this to be One-way: outgoing.

     Trust Direction

    Click on Next. When prompted for the trust password, enter the password you set on the principal for your domain (i.e. the password from section 3.2. Set a password for the Principal).

     Trust Password

    Click on Next. You will then be shown the Trust Selections Screen, where you can review your choices. NB this screen is the last point at which the Back button is enabled.

     Trust Selections Complete

    Click Next to advance to the New Trust Wizard completion screen. Click Finish to complete the process, and you should see the new realm trust show up in the top panel under Domains trusted by this domain (outgoing trusts).

     Trusts Tab

    Click OK to close the Properties window.

3.4. Map user principals to names

  • Next we map OX.AC.UK principals to AD users

    Start Active Directory Users and Computers as an Administrative user and turn on the Advanced Features view (in the View menu).

    Pick a username, right-click and select Name Mappings...

    Select the Kerberos Names tab.


     Kerberos Names Tab

    Add a valid Kerberos principal in the form 'oxfordusername@OX.AC.UK' (note case).


     Add Kerberos Name

    It's helpful, but not essential, for the Active Directory username and the oxfordusername to match. For example, if they don't match and the user authenticates as (example SSO user) abcd0123 but is authorised to use the Active Directory resources that (example AD user) wxyz9876 has access to, scripts using %username% will use wxyz9876 and this could cause problems if a user has a home directory called abcd0123 with an automatic mapping.


     Populated Kerberos Names Tab

    Repeat for other usernames. If you have a lot of users, you're going to want to look at scripting this.

3.5. Domain Member Workstation (XP/Vista/7) and Domain Member Server Configuration

NOTE: Windows OS 'Home' editions do not have the capability to join a domain, so cannot be configured for AD cross-realm SSO login. The Windows OS editions listed below exclude all 'Home' editions.

  • ksetup

    First you will need to install ksetup.exe on the Domain Client if it's not already installed.

    • Windows XP: ksetup.exe should be installed from the Windows Support Tools package for Windows XP.
    • Windows Vista: ksetup.exe is not provided for Windows Vista, so either use the Windows XP executable or change the registry directly (see below).
    • Windows 7 and later: ksetup.exe is included in the default Windows 7 installation.

    If ksetup.exe is available on the client (or you have installed it), run the same ksetup commands that were run on the server:


    Add OX.AC.UK KDCs to each domain client

    If ksetup.exe is unavailable on the client, use the direct registry method:

    • Open the registry editor to the path 'HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains'
    • Create a new key and name it 'OX.AC.UK'
    • Create a new REG_MULTI_SZ entry, named 'KdcNames' inside the new 'OX.AC.UK' key
    • Add the four KDC values to 'KdcNames': '', '', '', ''

    For larger numbers of users we would generally recommend that the above workstation configuration is set up using Group Policy.

    Domain member servers do not need the addition of the OX.AC.UK KDCs using ksetup.exe unless users in the OX.AC.UK realm are permitted to log into it directly.

    Ideally the above settings would be established using Group Policy for workstations.

  • Domain Group Policies

    When a user logs in using their OX.AC.UK credentials, the system will not apply roaming profiles or group policy objects (GPOs) associated with that user in the local domain, unless the Allow Cross-Forest User Policy and Roaming User Profiles policy is applied to the workstation they are logging into. The path to this policy in the Group Policy Management Editor is Computer Configuration\Policies\Administrative Templates\System\Group Policy.

  • Password changes
  • SSO Password changes using Ctrl+Alt+Del will not work, so SSO users should be configured to disallow the password changing option using the Remove Change Password Group Policy. The path to this policy in the Group Policy Management Editor is User Configuration\Policies\Administrative Templates\System\Ctrl+Alt+Del Options. If SSO passwords need changing they should be changed using the Webauth Change Password web page instead.

4. Troubleshooting

In case of problems:

  • Kerberos event logging can be enabled on domain controllers for more information, as described in
  • The klist.exe tool can also be used to display the current tickets for a user on a client workstation.
  • An effective method for debugging your client domain authentication process is to monitor client network traffic using a network traffic analysis tool such as Wireshark

5. Current Problems

Problems that have been reported or discovered, with work-arounds / solutions where available, will be recorded on this page.

Windows 7 Workstation Hangs at Welcome Screen
Credential Manager issues have been seen in Windows 7, where the PC would hang at the Welcome screen. This was confirmed as an issue by Microsoft in and a hotfix was released. This fix was subsequently rolled into Windows 7 Service Pack 1.


Written by IT Services. Latest revision 31 October 2019