4.Â Security Considerations

Now that your machines (and possibly other services) are
authenticating against your LDAP server, this server needs to be
protected at least as well as
/etc/master.passwd would be on a regular
server, and possibly even more so since a broken or cracked LDAP
server would break every client service.

Remember, this section is not exhaustive. You should
continually review your configuration and procedures for
improvements.

4.1.Â Setting Attributes Read-only

Several attributes in LDAP should be read-only. If left
writable by the user, for example, a user could change his
uidNumber attribute to 0
and get root
access!

To begin with, the userPassword
attribute should not be world-readable. By default, anyone
who can connect to the LDAP server can read this attribute.
To disable this, put the following in
slapd.conf:

ExampleÂ 8.Â Hide Passwords

access to dn.subtree="ou=people,dc=example,dc=org"
attrs=userPassword
by self write
by anonymous auth
by * none
access to *
by self write
by * read

This will disallow reading of the
userPassword attribute, while still
allowing users to change their own passwords.

Additionally, you'll want to keep users from changing some
of their own attributes. By default, users can change any
attribute (except for those which the LDAP schemas themselves
deny changes), such as uidNumber. To close
this hole, modify the above to

ExampleÂ 9.Â Read-only Attributes

access to dn.subtree="ou=people,dc=example,dc=org"
attrs=userPassword
by self write
by anonymous auth
by * none
access to attrs=homeDirectory,uidNumber,gidNumber
by * read
access to *
by self write
by * read

This will stop users from being able to masquerade as
other users.

4.2.Â root Account
Definition

Often the root
or manager account for the LDAP service will be defined in the
configuration file. OpenLDAP
supports this, for example, and it works, but it can lead to
trouble if slapd.conf is compromised. It
may be better to use this only to bootstrap yourself into
LDAP, and then define a root account there.

Even better is to define accounts that have limited
permissions, and omit a root account entirely. For
example, users that can add or remove user accounts are added
to one group, but they cannot themselves change the membership
of this group. Such a security policy would help mitigate the
effects of a leaked password.

4.2.1.Â Creating a Management Group

Say you want your IT department to be able to change
home directories for users, but you do not want all of them
to be able to add or remove users. The way to do this is to
add a group for these admins:

In this example we have given a subset of administrative
power to certain users without giving them power in other
domains. The idea is that soon no single user account has
the power of a root account, but every
power root had is had by at least one user. The root account then becomes
unnecessary and can be removed.

4.3.Â Password Storage

By default OpenLDAP will store
the value of the userPassword attribute as
it stores any other data: in the clear. Most of the time it
is base 64 encoded, which provides enough protection to keep
an honest administrator from knowing your password, but little
else.

It is a good idea, then, to store passwords in a more
secure format, such as SSHA (salted SHA). This is done by
whatever program you use to change users' passwords.