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.
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.
Configure the files in /etc/krb5.
Create the Kerberos database for storing users and services.
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.
Start the Kerberos daemon processes.
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.
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.
Create the default identity mapping for GSSAPI and any custom mappings as described in GSSAPI Identity Mappings.
Create a keytab to store the service keys.
Your LDAP service key is stored in the keytab.
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.
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:
bjensen bjensen/Sales bjensen@EXAMPLE.COM bjensen/Sales@EXAMPLE.COM |
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.
You cannot use DSCC to perform this task. Use the command line, as described in this procedure.
Create new mapping entries under cn=GSSAPI,cn=identity mapping, cn=config.
See Sun Java System Directory Server Enterprise Edition 6.3 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 |
Restart Directory Server for your new mappings to take effect.