1. Description of Service
The Kerberos service provides support for strong mutual authentication of clients and servers. It is offered primarily to ITSS to enable secure network authentication of service users with the benefit of single sign-on. Kerberos also underpins the Webauth service and is used for system-to-system authentication of many IT Services services such as Oak LDAP.
The Kerberos protocol defines the concept of a security "realm" comprising a set of principals and policies that are shared amongst members of the realm. Principals are digital identities corresponding to human or system users, and policies control various attributes or characteristics of these identities, such as the maximum password lifetime. Principals are created for all entitled users (see IT Services and The University Card for details) via the activation process, and for eligible systems via the provisioning element described below.
Common use cases:
- SSO sign-in to a local Active Directory domain via a cross-realm trust
- SSO authentication of users to a web server supporting HTTP-Negotiate
- SSO authentication of users to CIFS / NFS servers
Our Kerberos service comprises the following main elements:
- Authentication: strong mutual authentication of clients (whether human or system) and servers over any network
- Administration: administration of Kerberos principals, including devolved management of service principals
- Registration: service principals can be created to meet a variety of needs
- Support: information and advice to help diagnose and remedy problems
All service features described here relate to the OX.AC.UK Kerberos realm.
Authentication provides a client with the means to prove their identity to a system or service. For most people at Oxford this equates to demonstrating their right to use a particular Oxford SSO username.
Kerberos works by first establishing the client's identity with the Kerberos service itself, and then issuing signed tokens that the user can present in order to confirm their identity to each service they wish to access. At no point are the client's credentials (e.g. a password) or equivalent information transmitted over the network, so there is no possibility of interception either "on the wire" or by a service that has been compromised.
In order to make use of Kerberos user authentication, servers must be registered with the Kerberos service.
When servers are registered to participate in Kerberos authentication we will assign management rights over the newly created service principal to one or more ITSS. This enables ITSS to obtain keytabs, set encryption types, and delete service principals as required. For security reasons ITSS will be assigned a separate user principal for this purpose (usually of the form unitNNNN/itss). Administration of service principals can be done using a Kerberos admin client (kadmin on many systems).
If the ITSS for a unit change, we will be happy to update the list of ITSS with management rights over a unit's service principals (but please note that we will not do this automatically).
In order to make use of Kerberos user authentication (or indeed system-to-system authentication), servers need to be registered with Kerberos. This involves the creation of one or more Kerberos "service principals" for the server, and the generation of one or more "keytabs" to be stored on the server itself. A keytab is a file containing the information that the server needs to prove its identity to the Kerberos system - it consists of a list of service principals and associated keys.
We can create service principals on request, and often provide additional advice on the best way to set them up for use in particular scenarios. Generation of a keytab is done by ITSS for the service principals for which they have management privileges (see Administration above).
We can assist with diagnosis of problems experienced when configuring a server to use Kerberos in the Oxford realm. Specifically: we can extract relevant portions of the log files from our servers to assist with diagnosis of the problem, and in some cases offer advice on what the cause of the problem might be. We also create and maintain advice in various (mainly web) locations associated with this service.
The Kerberos service was introduced alongside Webauth in 2002.