LDAP System Administration [Electronic resources] نسخه متنی

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

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 ldapadmin@PLAINJOE.ORG
Password for ldapadmin@PLAINJOE.ORG: password
$ klist
Ticket cache: FILE:/tmp/krb5cc_780
Default principal: ldapadmin@PLAINJOE.ORG
Valid starting     Expires            Service principal
11/28/02 19:20:15  11/29/02 05:20:15  krbtgt/PLAINJOE.ORG@PLAINJOE.ORG
$ ldapmodify -a -H ldap://master.plainjoe.org/ > -f testuser.ldif
SASL/GSSAPI authentication started
SASL username: ldapadmin@PLAINJOE.ORG
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: ldapadmin@PLAINJOE.ORG
Valid starting     Expires            Service principal
11/28/02 19:20:15  11/29/02 05:20:15  krbtgt/PLAINJOE.ORG@PLAINJOE.ORG
11/28/02 19:23:34  11/29/02 05:20:15  ldap/garion.plainjoe.org@PLAINJOE.ORG

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