- 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 iam@it.ox.ac.uk. 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.
When Sysdev create your Kerberos cross-realm service principal, they will also assign administration rights over it to the requested /itssprincipal(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 linux.ox.ac.uk 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 = kdc0.ox.ac.uk
kdc = kdc1.ox.ac.uk
kdc = kdc2.ox.ac.uk
kdc = kdc3.ox.ac.uk
admin_server = kdc-admin.ox.ac.uk
}
- Use the kadmin tool with the /itss principal to set the cross-realm trust principal's password and change the principal's keys. For example, 'kadmin -p unit9999/itss@OX.AC.UK -r OX.AC.UK' will start kadmin with the default realm as 'OX.AC.UK' and prompt for the 'unit9999/itss' principal's password. Once you have logged in and receive the "kadmin:" prompt you can specify the cross-realm trust principal, the encryption types it uses, and set its password, e.g. if you were the ITSS for the fictitious Jordan College the command would be 'cpw -e "aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal" krbtgt/JORDAN.OX.AC.UK@OX.AC.UK', and you would be prompted to enter a strong password for the cross-realm principal (NOTE: the policy for cross-realm trust principal passwords specifies a minimum length of 32 characters). Once the "kadmin:" prompt is returned you can then confirm the principal keys and parameters using 'getprinc krbtgt/JORDAN.OX.AC.UK'.
-
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"
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 Configure Domain Controllers on the webpage 'Oxford SSO integration of AD via a cross-realm trust', 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. 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).
- 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)
- 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.
- Add a valid Kerberos principal in the form 'oxfordusername@OX.AC.UK' (note case).
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.
-
Repeat for other usernames. If you have a lot of users, you're going to want to look at scripting this.
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.
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': 'kdc0.ox.ac.uk', 'kdc1.ox.ac.uk', 'kdc2.ox.ac.uk', 'kdc3.ox.ac.uk'
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.