5.6 SASL and OpenLDAP

The final section of this chapter explores how to replace the simple authentication used in your current directory server with SASL mechanisms. You will be using the GSSAPI mechanism for Kerberos 5 authentication (RFCs 1510, 2743, and 2478). The examples assume that a Kerberos realm named PLAINJOE.ORG has already been established and that a service principal named ldapadmin has been created. If you are unclear on the details of Kerberos 5, a good place to start would be Kerberos: A Network Authentication System, by Brian Tung (Addison-Wesley), or The Moron's Guide to Kerberos, located at http://www.isi.edu/gost/brian/security/kerberos.html.

So far, the rootdn and rootpw values used in slapd.conf have appeared similar to:

rootdn          "cn=Manager,dc=plainjoe,dc=org"
rootpw          {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy

In OpenLDAP 2.1, an SASL ID can be converted to a distinguished name and used for authentication or authorization wherever a normal DN would be appropriate. This includes operations such as defining the updatedn used for replication or the binddn used by a client in a search request. There's one important exception to this rule: don't use an SASL ID as the DN of an entry in the directory. To summarize from Chapter 3, an SASL ID converted to a DN appears as:

uid=name[,realm=realm],cn=mechanism,cn=auth

To illustrate how to use SASL as the authentication mechanism, we'll replace the rootdn in our master server's slapd.conf with the Kerberos 5 principal ldapadmin. Following the conversion algorithm just discussed, the new rootdn in slapd.conf will be:

## New SASL-based rootdn
rootdn      "uid=ldapadmin,cn=gssapi,cn=auth"

The rootpw entry can be deleted because authentication for the new rootdn will be done using the SASL GSSAPI mechanism. The OpenLDAP server must possess a valid keytab file containing the key for decrypting tickets transmitted with client requests.^[2] Moreover, our tests will assume that the server is configured to use the default realm of PLAINJOE.ORG.

^[2] More information on generating keytab files can be found on the kadmin(8) manpage.

Once the configuration change has been made, restart slapd. You can then verify that the change has been made correctly by using the ldapadd command to add an entry; the rootdn is currently the only DN allowed to write to the directory.

To run this test, create a file with an LDIF entry; we'll use the following LDIF entry, stored in /tmp/test.ldif:

## Test user to verify that the new rootdn is OK.
dn: cn=test user,ou=people,dc=plainjoe,dc=org
cn: test user
sn: test
objectclass: person

To add this entry to the directory, invoke ldapadd with some additional arguments:

$ kinit [email protected]
Password for [email protected]: password
$ klist
Ticket cache: FILE:/tmp/krb5cc_780
Default principal: [email protected]
      
Valid starting     Expires            Service principal
11/28/02 19:20:15  11/29/02 05:20:15  krbtgt/[email protected]
      
$ ldapmodify -a -H ldap://master.plainjoe.org/ \
> -f testuser.ldif
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL installing layers
adding new entry "cn=test user,ou=people,dc=plainjoe,dc=org"
      
$ klist
Ticket cache: FILE:/tmp/krb5cc_780
Default principal: [email protected]
      
Valid starting     Expires            Service principal
11/28/02 19:20:15  11/29/02 05:20:15  krbtgt/[email protected]
11/28/02 19:23:34  11/29/02 05:20:15  ldap/[email protected]

If the server does not support the particular mechanism needed, GSSAPI in this case, authentication will fail. The -Y option can be used to specify an SASL authentication mechanism rather than letting the client and server attempt to negotiate a valid type that is supported by both. As seen earlier, the client can obtain a list of the mechanisms that the server supports by querying the server's rootDSE and viewing the values of the supportedSASLMechanisms attribute.

After becoming accustomed to SASL user IDs, you can incorporate them into the ACLs defined in slapd.conf. Following the rule that an SASL ID can be used anywhere a DN is used to represent an authenticated user, SASL IDs can follow the by keyword in an ACL definition. For example, the following definition allows the Kerberos principal jerry to edit the mail attribute for all users in the people organizational unit:

access to dn=".*,ou=people,dc=plainjoe,dc=org" attrs=mail
     by "uid=jerry,cn=gssapi,cn=auth" write