Kerberos Interoperability

  • Article

The Kerberos Version 5 protocol is implemented for a variety of systems and is used to provide a single authentication service in a distributed network. Kerberos interoperability provides a common protocol that allows a single (possibly replicated) account database for authenticating users on all enterprise computing platforms to access all services in a heterogeneous environment. Kerberos interoperability is based on the following characteristics:

  • A common authentication protocol used to identify the end user or service by the principal name in a network connection.

  • The ability to define trust relationships between Kerberos realms and to generate ticket referral requests between realms.

  • Implementations that support the Interoperability Requirements defined in RFC 1510 regarding encryption and checksum algorithms, mutual authentication, and other ticket options.

  • Support for Kerberos Version 5 security token formats for context establishment and per-message exchange as defined by the IETF Common Authentication Technology working group.*

The principal name in a Kerberos ticket is used to authenticate the user's identity while additional authorization information might be managed on the local system for access control. Identity-based authentication provides a high degree of interoperability for systems that support the Kerberos Version 5 protocol, however, it does not support user authorization. The Kerberos protocol provides for transport of authorization data but the contents of this field is considered specific to the application service.

Microsoft's implementation of the Kerberos protocol supports the interoperability characteristics sufficient for identity-based authentication. In addition, Microsoft integrates authorization data in the form of Windows NT group memberships in Kerberos tickets to convey access control information to Windows NT services. The native representation of the authorization data is the Windows NT Security IDs.

Windows NT services have services accounts defined in the Windows NT Directory Service that defines the shared secret used by the KDC to encrypt session tickets. Clients attempting to connect to Windows NT services obtain session tickets to the target server from the KDC in the domain where the service account is defined. The Kerberos security provider supporting a Windows NT service will expect to find authorization data in the session tickets used to build a security access token. The Windows NT service will impersonate the security context of the client, based on the authorization data provided in the session ticket.

Clients that obtain initial Kerberos TGT tickets from KDCs on non-Windows NT-based systems will use the Kerberos referral mechanism to request a session ticket from the KDC in the Windows NT Service domain. The referral ticket is created by interrealm trust relationships between the KDCs. The ticket requests originating from an MIT Kerberos authentication service are not likely to contain authorization data. In the case where session tickets do not contain authorization data, the Kerberos security provider on Windows NT will try to use the principal name in the ticket and create a security access token for a designated user account, or use a default account defined for this purpose. Microsoft is still investigating some of the interoperability issues with different Kerberos configurations and will continue to work to find solutions for Kerberos interoperability.

The DCE Security Services are also layered on the Kerberos protocol. DCE authentication services use RPC representation of Kerberos protocol messages. In addition, DCE uses the authorization data field in Kerberos tickets to convey Privilege Attribute Certificates (PACs) that define user identity and group membership. The DCE PAC is used in a similar manner as Windows NT Security IDs for user authorization and access control. Windows NT services will not be able to translate DCE PACs into Windows NT user and group identifiers. This is not an issue with Kerberos interoperability, but rather an issue of interoperability between DCE and Windows NT access control information. In the future, Microsoft will investigate ways to map DCE authorization to the Windows NT security model.

* RFC 1964 defines the Kerberos Version 5 GSS-API Mechanism security token formats.