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.
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