Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide

SASL Authentication Through GSSAPI (Solaris OS Only)

The Generic Security Service API (GSSAPI) over SASL allows you to use a third-party security system such as Kerberos V5 to authenticate clients. The GSSAPI library is available only for the Solaris OS SPARC® platform. Sun recommends that you install the Kerberos V5 implementation on the Sun Enterprise Authentication MechanismTM 1.0.1 server.

The server uses the GSSAPI to validate the identity of the user. Then, the SASL mechanism applies the GSSAPI mapping rules to obtain a DN that is the bind DN for all operations during this connection.

ProcedureTo Configure the Kerberos System

Configure the Kerberos software according to the manufacturer’s instructions. If you are using the Sun Enterprise Authentication Mechanism 1.0.1 server, use this procedure.

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

  1. Configure the files in /etc/krb5.

  2. Create the Kerberos database for storing users and services.

  3. In the database, create the Principal for the LDAP service.

    $ ldap/server-FQDN@realm

    where server-FQDN is the fully qualified domain name of your Directory Server.

  4. Start the Kerberos daemon processes.

    Note –

    The DNS must be configured on the host machine.

    Refer to your software documentation for detailed instructions for each of these steps. Also, see Example Configuration of Kerberos Authentication Using GSSAPI With SASL.

ProcedureTo Configure the GSSAPI Mechanism

The following procedure explains how to configure Directory Server to use GSSAPI on the Solaris OS:

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

  1. Create the default identity mapping for GSSAPI and any custom mappings as described in GSSAPI Identity Mappings.

  2. Create a keytab to store the service keys.

    Your LDAP service key is stored in the keytab.

    1. Ensure that the keytab is only readable by the Directory Server user.

    2. Change the file name to be different from the default /etc/krb5/krb5.keytab.

    3. Set the environment variable KRB5_KTNAME to ensure that the new keytab is used rather than the default keytab.

  3. If you modified the SASL configuration entry or one of the GSSAPI identity mapping entries, restart Directory Server.

    Note that the DNS must be configured on the host machine.

GSSAPI Identity Mappings

Identity mappings for SASL mechanisms try to match credentials of the SASL identity with a user entry in the directory. Authentication fails if the mapping cannot find a DN that corresponds to the SASL identity.

The SASL identity is a string called the Principal that represents a user in a format specific to each mechanism. In Kerberos using GSSAPI, the Principal is an identity with the format uid [/instance][@ realm]. The uid can contain an optional instance identifier followed by an optional realm that is often a domain name. For example, the following strings are all valid user Principals:


Initially, no GSSAPI mappings are defined in the directory. Define a default mapping and any custom mappings that you need according to how your clients define the Principal that your clients use.

ProcedureTo Define Identity Mappings for GSSAPI

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

  1. Create new mapping entries under cn=GSSAPI,cn=identity mapping, cn=config.

    See Sun Java System Directory Server Enterprise Edition 6.2 Reference for the definition of the attributes in an identity mapping entry. Examples of GSSAPI mappings are located in instance-path/ldif/identityMapping_Examples.ldif.

    The default GSSAPI mapping in this file assumes that the Principal contains only a user ID. This mapping determines a user in a fixed branch of the directory:

    dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
    objectclass: dsIdentityMapping
    objectclass: nsContainer
    objectclass: top
    cn: default
    dsMappedDN: uid=\${Principal},ou=people,dc=example,dc=com

    Another example in this file shows how to determine the user ID when the user ID is contained in a Principal that includes a known realm.

    dn: cn=same_realm,cn=GSSAPI,cn=identity mapping,cn=config
    objectclass: dsIdentityMapping
    objectclass: dsPatternMatching
    objectclass: nsContainer
    objectclass: top
    cn: same_realm
    dsMatching-pattern: \${Principal}
    dsMatching-regexp: (.*)@EXAMPLE.COM
    dsMappedDN: uid=\$1,ou=people,dc=EXAMPLE,dc=COM
  2. Restart Directory Server for your new mappings to take effect.