9.11. Using Kerberos GSS-API with SASL

Kerberos v5 must be deployed on the host for Directory Server to utilize the GSS-API mechanism for SASL authentication. GSS-API and Kerberos client libraries must be installed on the Directory Server host to take advantage of Kerberos services.

9.11.1. Authentication Mechanisms for SASL in Directory Server

Directory Server support the following SASL encryption mechanisms:
  • PLAIN. PLAIN sends cleartext passwords for simple password-based authentication.
  • EXTERNAL. EXTERNAL, as with TLS, performs certificate-based authentication. This method uses public keys for strong authentication.
  • CRAM-MD5. CRAM-MD5 is a weak, simple challenge-response authentication method. It does not establish any security layer.

    Warning

    Red Hat recommends not using the insecure CRAM-MD5 mechanism.
  • DIGEST-MD5. DIGEST-MD5 is a weak authentication method for LDAPv3 servers.

    Warning

    Red Hat recommends not using the insecure DIGGEST-MD5 mechanism.
  • Generic Security Services (GSS-API). Generic Security Services (GSS) is a security API that is the native way for UNIX-based operating systems to access and authenticate Kerberos services. GSS-API also supports session encryption, similar to TLS. This allows LDAP clients to authenticate with the server using Kerberos version 5 credentials (tickets) and to use network session encryption.
    For Directory Server to use GSS-API, Kerberos must be configured on the host machine. See Section 9.11, “Using Kerberos GSS-API with SASL”.

    Note

    GSS-API and, thus, Kerberos are only supported on platforms that have GSS-API support. To use GSS-API, it may be necessary to install the Kerberos client libraries; any required Kerberos libraries will be available through the operating system vendor.

9.11.2. About Kerberos in Directory Server

On Red Hat Enterprise Linux, the supported Kerberos libraries are MIT Kerberos version 5.
The concepts of Kerberos, as well as using and configuring Kerberos, are covered at the MIT Kerberos website, http://web.mit.edu/Kerberos/.

9.11.2.1. About Principals and Realms

A principal is a user or service in the Kerberos environment. A realm defines what Kerberos manages in terms of who can access what. The client, the KDC, and the host or service you want to access must use the same realm.

Note

Kerberos realms are only supported for GSS-API authentication and encryption, not for DIGEST-MD5.
Realms are used by the server to associate the DN of the client in the following form, which looks like an LDAP DN: 
uid=user_name/[server_instance],cn=realm,cn=mechanism,cn=auth
For example, Mike Connors in the engineering realm of the European division of example.com uses the following association to access a server in the US realm: 
uid=mconnors/cn=Europe.example.com,cn=engineering,cn=gssapi,cn=auth
Babara Jensen, from the accounting realm of US.example.com, does not have to specify a realm when to access a local server: 
uid=bjensen,cn=accounting,cn=gssapi,cn=auth
If realms are supported by the mechanism and the default realm is not used to authenticate to the server, then the realm must be specified in the Kerberos principal. Otherwise, the realm can be omitted.

Note

Kerberos systems treat the Kerberos realm as the default realm; other systems default to the server.

9.11.2.2. About the KDC Server and Keytabs

The Key Distribution Center (KDC) authenticates users and issues Ticket Granting Tickets (TGT) for them. This enables users to authenticate to Directory Server using GSS-API. To respond to Kerberos operations, Directory Server requires access to its keytab file. The keytab contains the cryptographic key that Directory Server uses to authenticate to other servers.
Directory Server uses the ldap service name in a Kerberos principal. For example: 
ldap/server.example.com@EXAMPLE.COM
For details about creating the keytab, see your Kerberos documentation.

Note

You must create a Simple Authentication and Security Layer (SASL) mapping for the Directory Server Kerberos principal that maps to an existing entry Distinguished Name (DN).

9.11.3. Configuring SASL Authentication at Directory Server Startup

SASL GSS-API authentication has to be activated in Directory Server so that Kerberos tickets can be used for authentication. This is done by supplying a system configuration file for the init scripts to use which identifies the variable to set the keytab file location. When the init script runs at Directory Server startup, SASL authentication is then immediately active.
The default SASL configuration is stored in the /etc/sysconfig/dirsrv file.
If there are multiple Directory Server instances and not all of them will use SASL authentication, then there can be instance-specific configuration files created in the /etc/sysconfig/ directory named dirsrv-instance. For example, dirsrv-example. The default dirsrv file can be used if there is a single instance on a host.
To enable SASL authentication, uncomment the KRB5_KTNAME line in the /etc/sysconfig/dirsrv (or instance-specific) file, and set the keytab location for the KRB5_KTNAME variable. For example: 
# In order to use SASL/GSSAPI the directory
# server needs to know where to find its keytab
# file - uncomment the following line and set
# the path and filename appropriately
KRB5_KTNAME=/etc/dirsrv/krb5.keytab