Isode Support for Kerberos, Active Directory and Single Sign On

Kerberos

Kerberos is an open standard based authentication system generally used with password based authentication that is widely deployed, in particular as the default Windows authentication mechanism. A key feature of Kerberos is its use of “Tickets” to retain authentication information so that users do not have to enter username and password for each network application used; this is known as Single Sign On (SSO).

The current version of Kerberos (version 5) is an Internet Standard specified in RFC 4120. It is used by Windows (since Windows 2000) as the default authentication mechanism, which has been a major driver of Kerberos deployment. Kerberos is supported on Mac OS X and on many Unix platforms (in particular Solaris and Red Hat Linux). The rest of this section gives a very high level overview of how Kerberos works.

Kerberos is an authentication service commonly used to authenticate the user using an application client (such as an email client) to an application server (such as an email server) by using “tickets” obtained from a trusted third party “Kerberos” server.

This “Kerberos” server is called the Kerberos Distribution Center (KDC). The following examples show how Kerberos used by a client (application client) to authenticate to a server (application server).

A client wishing to authenticate using Kerberos will start by presenting credentials (an encrypted token derived from UserName and Password provided by the user) to the KDC. The KDC validates these credentials, and provides a Ticket Granting Ticket back to the client using a secure mechanism. Kerberos Tickets are central to how Kerberos works and to how it supports SSO. The client will cache the ticket granting ticket for future use.

Having obtained a Ticket Granting Ticket, the client can now authenticate to an application server without needing further credentials from the user, as illustrated above. The client will present a “Session Ticket” (a second type of Kerberos ticket) to the server, in order to authenticate the client. To obtain a session ticket, the client sends to the KDC the Ticket Granting Ticket and information about the application server being used, which enables the KDC to provide the client with the necessary session ticket. The client will cache the session ticket, so it will not need to get another one from the KDC until the first session ticket expires.

Kerberos Single Sign On (SSO)

Single Sign On is where a user authenticates once (typically by providing user name and password) and the use of applications and services after this do not require username and password to be provided again. A key feature and benefit of Kerberos is its ability to provide SSO. Particularly as a consequence of Microsoft’s use of Kerberos, Kerberos is very widely used for SSO.

Kerberos SSO works by having the first application to authenticate (typically a client login process) share the Ticket Granting Ticket it obtains with other applications. This means that the other applications can start with the Ticket Granting Ticket, and do not have to get credentials from the user.

This sharing is provided by the operating system and Kerberos interfaces specific to the operating system. Typically Unix Kerberos implementations share and cache the tickets by putting the Kerberos tickets in files, whereas Windows uses shared memory. A common interface to the cached tickets is essential for SSO to work.

This sharing is also a potential security threat, as tickets may enable spoofing. This is a consideration when choosing where to use Kerberos.

SASL

SASL (Simple Authentication and Security Layer) is a framework used by Internet protocols to allow multiple authentication methods. By supporting SASL, an application protocol will automatically support a standardized set of authentication mechanisms, and will automatically support new mechanisms when they are standardized. SASL mechanisms are referred to by capitalized keywords (e.g., PLAIN). Standardized SASL mechanisms include username and password in the clear (PLAIN), various hashed password mechanisms (CRAM-MD5, NTLM, DIGEST-MD5), one time password (OTP) and X.509 PKI (SASL EXTERNAL).

SASL is used by Isode products to support Kerberos Authentication. This enables Kerberos support for the following protocols: SMTP; POP; IMAP; ManageSIEVE; XMPP (Client to Server); LDAP; and SOM (Isode’s Switch Operation and Management protocol used by MConsole to manage M-Switch).

Kerberos Support in SASL

Kerberos authentication is supported in SASL by the GSSAPI mechanism (note: no hyphen), specified in “The Kerberos V5 (“GSSAPI”) Simple Authentication and Security Layer (SASL) Mechanism” (RFC 4752).

Basic SASL operation with GSSAPI (Kerberos) follows the core Kerberos model and is shown above. Note that the authentication flow is identical to the second basic Kerberos diagram, with SASL providing the framework to support the Kerberos authentication. The core SASL function is to transfer the Kerberos Session Ticket from client to application server, where the Session Ticket provides the authentication. The client SASL will also negotiate with the KDC to obtain the Session Ticket, using information obtained from the server via SASL.

SASL Authentication using Kerberos requires the client to have the Kerberos Ticket Granting Ticket, so that it can get a Session Ticket from the KDC. There are two ways that this initialization can happen, which are now explained.

The simple scenario is that the client gets the Ticket Granting Ticket directly from the KDC, typically when the client logs in to the computer. This is the standard SSO scenario.

The second scenario is where the client has not obtained the Kerberos Ticket Granting Ticket from a previous authentication. There are a number of situations where this might happen, for example when the client is running on a system that does not use Kerberos for logon. Here the client needs to get a Ticket Granting Ticket from the KDC specifically to connect to the application server. The client will need to get username and password, which it can do in one of two ways:

• Prompt the user (as shown in the diagram).
• Obtain username and password from an application configuration (e.g., they could be stored in a Sodium bind profile).

Microsoft Authentication with SASL

Microsoft supports three Kerberos related SASL authentication mechanisms (in addition to various other SASL mechanisms) in its client and server products:

• GSSAPI, the SASL Kerberos (v5) mechanism.
• NTLM, an older Windows authentication mechanism (not Kerberos based).
• GSS-SPNEGO, a mechanism for negotiating the best available mechanism between GSSAPI and NTLM. This will negotiate use of GSSAPI if the machine is a part of a Windows domain, with fallback to NTLM otherwise.

Windows clients will support this combination, so that Kerberos authentication will be used where possible with fallback to NTLM. For example, when “Secure Password Authentication (SPA)” is selected in Microsoft Outlook, this will cause Outlook to use SASL use GSS-SPNEGO to negotiate either the GSSAPI or NTLM SASL mechanism.

APIs for Supporting Kerberos

In order to share Kerberos tickets to support SSO, applications using Kerberos on a computer need to use the same Kerberos interface. The best way for products such as Isode’s to do this is to use the Kerberos library provided by the operating system vendor. Because of this, the APIs used with Kerberos are important.

The SASL Kerberos (v5) mechanism (called GSSAPI) is specified by reference to the Internet Standard GSS-API (with a hyphen) API: The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 (RFC 4121). Note that the GSSAPI mechanism is specific to Kerberos, and can be implemented without GSS-API. GSS-API provides access to all of the functions needed by SASL to support authentication, given a Ticket Granting Ticket. Setup of a Ticket Granting Ticket must be done with vendor specific APIs. GSS-API enables application developers to easily work with different Kerberos implementations. GSS-API is provided on Mac OS X and on a number of Unix platforms.

Microsoft does not support GSS-API. Application access to Kerberos services is generally provided through higher level API such as ADSI (Active Directory Service Interface) or by a Microsoft SSPI (Security Support Provider Interface).

Windows and Unix implementations have good protocol interoperability. However these different APIs mean that many applications that support Kerberos work on either Unix/Mac or Windows but not both. Isode supports both APIs.

Isode Kerberos Support

Isode supports Kerberos (v5) through use of the SASL Kerberos (v5) mechanism (called “GSSAPI”). Isode’s implementation is dependent on the host operating system’s security services SDKs. On Windows, Isode utilizes the Microsoft Security Support Provider Interface (SSPI). On other platforms, Isode uses the operating systems GSS-API implementation and underlying Kerberos API implementation.

Isode also supports the NTLM SASL mechanism on all platforms and the GSS-SPNEGO SASL mechanism on Windows.

LDAP & Kerberos

LDAP Directory and Kerberos have a complex and important inter-relationship which is examined below.

LDAP Based (Password) Authentication

LDAP directories are often used for user authentication based on passwords. Directory is a natural central repository that can be used by a wide range of application for authentication. Discussion of the benefits of using a directory for password based authentication and how directory can provide appropriate management and control is described in the Isode white paper Password Policy.

Entries in an LDAP directory use hierarchical names with typed components, defined in X.500. There is a need to map from the User Name to a Directory Name. A clean way to do this is as a part of the Directory SASL implementation, which will allow authentication with a single SASL Bind operation. The SASL in the LDAP server will authenticate against information in the directory, so a password based SASL mechanism that can do this must be used (e.g., PLAIN or DIGEST-MD5). A description of Isode’s name mapping approach is given here.

This architecture is an alternate authentication approach to Kerberos.

LDAP use of Kerberos (SASL/GSSAPI)

LDAP can use Kerberos authentication with SASL/GSSAPI as shown above. From the client perspective, this will work as for any GSSAPI application, with client credentials in the Session Ticket being authenticated by the LDAP Server. The LDAP server will be set up as a Kerberos Principal (i.e., a Kerberos named identity), which enables it to verify the Session Ticket.

This basic approach has Kerberos user authentication independent of data stored in the LDAP server. The architecture will gain a number of benefits from co-ordination between data in the LDAP Server and the KDC authentication information (of a Kerberos Principal):

1. Directory Access Control. If access control needs to be applied (e.g., to control data modification) the Kerberos Principal needs to be mapped to a Directory Name. Isode M-Vault offers a number of ways to do this, including a search mechanism (so that the Kerberos Principal name can be stored in the associated directory entry).
2. Application Authorization. If an application using Kerberos authentication needs additional information for authorization or other purposes, and LDAP directory is a convenient place to hold this. The name mapping supported by Isode in 1, enables this.
3. Common credentials. So that an organization can use both Kerberos and LDAP authentication.

Three ways of achieving this coordination are noted:

1. Active Directory is both a KDC and an LDAP server. This integrated approach ensures coordination for all services.
2. External co-ordination by provisioning.
3. The KDC can use the LDAP directory as a back end database. This is an option on both of the popular Unix KDCs. This architecture could support a system with a mix of LDAP/Password and Kerberos authentication, although current implementations only allow the KDC to be the exclusive authentication approach.

These options are illustrated in the examples later in this paper.

Kerberos and X.509

This paper has focused on using Kerberos with passwords. Kerberos can be used with X.509 based authentication (instead of passwords) to establish the Ticket Granting Ticket and this supported by Microsoft and other implementations. This has particular value in support of applications that do not support direct X.509 Authentication.

Isode’s applications with Kerberos support can be used with Ticket Granting Tickets established using X.509 in an SSO environment. Where Isode’s products establish Ticket Granting Tickets, this will be done using passwords. All of the Isode protocols that support Kerberos can also use direct X.509 authentication with SASL EXTERNAL. Where X.509 authentication is available, Isode recommends that it is used directly by its applications in preference to Kerberos.

Data Integrity & Confidentiality with Kerberos

The primary role for Kerberos is to provide network authentication. However, Kerberos also provides a session key for use within the application protocol for providing data integrity and confidentiality services. The SASL Kerberos (v5) mechanism (called GSSAPI) utilizes this session key to establish a security layer offering data integrity and/or data confidentiality protection.

Alternative Approaches to Authentication and SSO

Kerberos is one approach to providing password based network authentication, and use of LDAP (described above) is the most important standards based alternative. The basic architecture of a server holding usernames and passwords is the same for Kerberos and LDAP, and for direct authentication there is no particular benefit of either approach. Use of LDAP directory is simpler, if Kerberos SSO is not required.

A benefit of LDAP, which is often important to service providers, is that the database only needs to hold hashes of the password. Kerberos need to hold either the plain password or a plain text equivalent (which may be hashed, but this does not mitigate the security risk). Use of LDAP can reduce risk for an operator, as passwords cannot be directly retrieved from the database. The simpler LDAP approach can also be beneficial.

For any password based SSO mechanisms, there will be a need to pass credentials between applications (e.g., Kerberos Tickets) and this is the critical security risk of any SSO approach. Kerberos has been carefully designed to minimize these risks. However, Kerberos still gives higher risks when used on computers which support multiple users at the same time.

When LDAP authentication is used for system logon, applications will often hide subsequent logon from the user by storing credentials in a local configuration file. Most email clients work in this way. Similarly, Web browsers will often cache username and password for Web applications. This gives user convenience, although the information storage is not always very secure. This approach is only viable if users always (or generally) use the same computer. Kerberos on the other hand will work well for mobile users.

Isode’s client credentials approach (which is oriented for high security environments) is to not trust operating system mechanisms for storing or hiding user passwords. For example, Sodium has the option to:

1. Not store passwords, and always prompt the user.
2. Store passwords in an encrypted file, and prompt the user for the encryption key on startup.

The first approach is sensible if only one account is used, and the second is convenient and secure for use of multiple accounts.

Password authentication with SSO has some security risks, and will often not be suitable for high security environments.

SSO can also be provided by Strong Authentication using X.509 PKI often in conjunction with smart cards as the client can use the X.509 private key for authentication. Strong authentication is ideal for server to server communication, and provides good security and easy management.

Private keys will generally be held on a smart card, or in software installed for the user on a given machine. Isode recommends that this is always used for system administration and high sensitivity tasks.

Examples

The following examples show how the capabilities described in this paper may be applied. The examples have been chosen to show a range of useful deployment configurations, the capabilities of the Isode product set, and the services that can be provided.

Sodium with AD

Sodium is Isode’s directory administration tool. Similar configurations are possible with other Isode directory clients, in particular other products in the Sodium family and MConsole. This will work correctly for Sodium on Windows or Unix. Here Sodium will use GSSAPI for authentication with AD using standard Windows Authentication (Kerberos). Two options are possible, which will be configured in the Sodium Bind profile:

• SSO, where the Kerberos Ticket Granting Ticket is available to Sodium and Sodium is configured to use SSO to the server (no bind credentials needed in the bind profile).

• Where the Ticket Granting Ticket is not available, perhaps because the client is not in the same Windows domain, credentials will be configured in the Bind Profile and Sodium will obtain a Ticket Granting Ticket from the KDC. Two configuration options are possible:

• Username only and the user will be promoted for the password.
• Username and password (in an encrypted bind profile).

Sodium with M-Vault and a Unix KDC

A similar setup can be provided with M-Vault as the directory being used by Sodium, giving the same SSO experience to the end user. A separate KDC would be used. The SASL/GSSAPI would communicate with the KDC to support Kerberos authentication.

M-Vault & Unix KDC as an AD Replacement

The server architecture from the previous section can be used for (Windows) LDAP clients, with M-Vault + KDC effectively providing an AD replacement.

>DSI is an Isode Web interface to an LDAP Directory. It can prompt the user for username and password to authenticate to the directory, or use SSO as shown here. The user SSO experience will be that there is no logon and the DSI simply connects and authenticates without prompting for username and password.

M-Link using AD for Authentication

M-Link is Isode’s XMPP Server. Where an organization uses AD for holding users and credentials, it makes sense for M-Link to use AD for authentication of clients. A straightforward way to do this (without using Kerboeros) is shown above. The credentials (Username and Password) presented by the XMPP client to M-Link will be verified against AD (by an LDAP BIND). For both connections, Username and Password must be transmitted, so the connections should be protected by TLS.

This approach may be modified, in a manner where the XMPP client uses password based authentication, but verification uses Kerberos. The Username and Password provided by the XMPP Client will be used by the XMPP server to obtain a Ticket Granting Ticket from the KDC, which will authenticate the XMPP Client to M-Link. This approach is not currently supported by M-Link.

This setup avoids use of Username + Password authentication to AD, which some sites do not allow and others prefer not to use.

A third approach is to use an XMPP client with SASL/GSSAPI support. Here, a Session Ticket provided by the XMPP Client (from the KDC) is used for authentication. This setup provides SSO to the XMPP Client and also completely avoids transmission of username and password over the network.

There is sometimes a requirement to hold additional per user information to support M-Link, such as a Security Clearance attribute in support of Label Checking. Two ways to achieve this are shown below.

The authentication will proceed as before. In order to get the additional user attributes, M-Link will need to bind to AD with LDAP (almost certainly using Kerberos Authentication, with M-Link as the directory client) to obtain this information. Note that this is done within SASL, so that name mappings are transparent to M-Link, which will just see each user as named by the JID (XMPP addresses).

It is often seen as undesirable to extend the schema in AD, and so it is preferable to hold this information in M-Vault. Sodium Sync can be used to provide base entries in M-Vault for each AD user, and the additional attributes can then be managed in M-Vault. These will be accessed by LDAP from the SASL layer. Note that this is done within SASL, so that name mappings are transparent to M-Link, which will just see each user as named by the JID (XMPP addresses).

Conclusions

This white paper has shown how Kerberos can be deployed with Isode clients and servers on Windows and Unix platforms, to provide SSO and also to provide access to Kerberos authenticated services where SSO is not used.