3.12 LDAP
3.12.3 Configure OpenLDAP Server
This section contains guidance on how to configure an OpenLDAP server to securely provide information for use in a centralized authentication service. This is not a comprehensive guide to maintaining an OpenLDAP server, but may be helpful in transitioning to an OpenLDAP infrastructure nonetheless.
3.12.3.1 Install OpenLDAP Server RPM
Is this machine the OpenLDAP server? If so:
# yum install openldap-servers
# chkconfig ldap on
CCE 3501-4
The openldap-servers RPM is not installed by default on RHEL5 machines. It is needed only by the OpenLDAP server, not by the clients which use LDAP for authentication.
3.12.3.2 Configure Domain-Specific Parameters
Edit the file /etc/openldap/slapd.conf. Add or correct the following lines:
suffix "dc=example,dc=com "
rootdn "cn=Manager,dc=example,dc=com "
where dc=example,dc=com is the same root you will use on the LDAP clients.
These are basic LDAP configuration directives. The suffix parameter gives the root name of all information served by this LDAP server, and should be some name related to your domain. The rootdn parameter names LDAP’s privileged user, who is allowed to read or write all data managed by this LDAP server.
3.12.3.3 Configure an LDAP Root Password
Ensure that the configuration file has reasonable permissions before putting the hashed root password in that file:
# chown root:ldap /etc/openldap/slapd.conf
# chmod 640 /etc/openldap/slapd.conf
Generate a hashed password using the slappasswd utility:
# slappasswd New password:
Re-enter new password:
This will output a hashed password string. Edit the file /etc/openldap/slapd.conf, and add or correct the line:
rootpw {SSHA}hashed-password-string
Be sure to select a secure password for the LDAP root user, since this user has permission to read and write all LDAP data, so a compromise of the LDAP root password will probably enable a full compromise of your site.
Protect configuration files containing the hashed password the same way you would protect other files, such as /etc/shadow, which contain hashed authentication data. In addition, be sure to use a reasonably strong hash function, such as SHA-1,1 rather than an insecure scheme such as crypt.
3.12.3.4 Configure the LDAP Server to Require TLS for All Transactions
Because LDAP queries and responses, particularly those containing authentication information or other sensitive data, must be protected from disclosure or modification while in transit over the network, this guide recommends using SSL to protect all transactions. In order to do this, it is necessary to have a site-wide SSL infrastructure in which a CA certificate is used to verify that other certificates, such as that presented by the LDAP server to its clients, are authentic.
Therefore, this procedure involves using the CA system to create a certificate for the LDAP server, then installing that certificate on the LDAP server and configuring slapd to require its use. See Section2.5.6for details about the process of creating SSL certificates for use by servers at your site.
3.12.3.4.1 Create the Certificate for the LDAP Server
Note: This step must be performed on the CA system, not on the LDAP server itself.
Change into the CA certificate directory:
# cd /etc/pki/tls/certs
Generate a key pair for the LDAP server:
# openssl genrsa -out ldapserverkey.pem 2048
Next, generate a certificate signing request (CSR) for the CA to sign:
# openssl req -new -key ldapserverkey.pem -out ldapserver.csr Sign the ldapserver.csr request:
# openssl ca -in ldapserver.csr -out ldapservercert.pem
1If you are using SHA-1, the hashed password string will begin with “{SHA}” or “{SSHA}”.
This step creates a private key, ldapserverkey.pem, and a public certificate, ldapservercert.pem. The LDAP server will use these to prove its identity by demonstrating that it has a certificate which has been signed by the site CA. LDAP clients at your site should only be willing to accept authentication data from a verified LDAP server.
3.12.3.4.2 Install the Certificate on the LDAP Server
Create the PKI directory for LDAP certificates if it does not already exist:
# mkdir /etc/pki/tls/ldap
# chown root:root /etc/pki/tls/ldap
# chmod 755 /etc/pki/tls/ldap
Using removable media or some other secure transmission format, install the files generated in the previous step onto the LDAP server:
/etc/pki/tls/ldap/serverkey.pem: the private key ldapserverkey.pem
/etc/pki/tls/ldap/servercert.pem: the certificate file ldapservercert.pem Verify the ownership and permissions of these files:
# chown root:ldap /etc/pki/tls/ldap/serverkey.pem
# chown root:ldap /etc/pki/tls/ldap/servercert.pem
# chmod 640 /etc/pki/tls/ldap/serverkey.pem
# chmod 640 /etc/pki/tls/ldap/servercert.pem
Verify that the CA’s public certificate file has been installed as /etc/pki/tls/CA/cacert.pem, and has the correct permissions:
# mkdir /etc/pki/tls/CA
# chown root:root /etc/pki/tls/CA/cacert.pem
# chmod 644 /etc/pki/tls/CA/cacert.pem
CCE 4360-4, 4378-6, 4492-5, 4263-0, 3502-2, 4449-5, 4361-2, 4427-1, 4321-6, 4339-8, 4105-3, 3718-4
As a result of these steps, the LDAP server will have access to its own private certificate and the key with which that certificate is encrypted, and to the public certificate file belonging to the CA. Note that it would be possible for the key to be protected further, so that processes running as ldap could not read it. If this were done, the LDAP server process would need to be restarted manually whenever the server rebooted.
3.12.3.4.3 Configure slapd to Use the Certificates
Edit the file /etc/openldap/slapd.conf. Add or correct the following lines:
TLSCACertificateFile /etc/pki/tls/CA/cacert.pem TLSCertificateFile /etc/pki/tls/ldap/servercert.pem TLSCertificateKeyFile /etc/pki/tls/ldap/serverkey.pem security simple_bind=128
The first set of lines tell slapd where to find the appropriate SSL certificates to present to clients when they request an encrypted transaction. The last setting tells slapd never to allow clients to present credentials (i.e.
passwords) in an unencrypted session. It is a good security principle never to allow unencrypted passwords to traverse a network, so ensure that LDAP mandates this.
3.12.3.5 Install Account Information into the LDAP Database
There are many ways to maintain an OpenLDAP database. Methods include:
Input entries in ldif(5) format into a file /path/to/new entries , and use slapadd to import those entries while slapd is not running:
# slapadd -l /path/to/new entries
Write a script to create and modify LDAP entries by connecting to the LDAP server normally. The Perl Net::LDAP module is appropriate for this, there is a Python API called python-ldap, and functionality is likely available for other scripting languages as well.
Use an LDAP front-end program which provides an interface for editing the database. If the front-end program is web-based or otherwise accessible over a network, ensure that authentication information is protected via SSL between the administrator’s client and the program, as well as between the program and the LDAP database.
Any of these methods or others may be appropriate for your site. This guide does not provide a recommendation, and there will be no further discussion of the syntax of entering LDAP data into the database.
3.12.3.5.1 Create Top-level LDAP Structure for Domain
Create a structure for the domain itself with at least the following attributes:
dn: dc=example,dc=com objectClass: dcObject objectClass: organization dc: example
o: Organization Description
This is a placeholder for the root of the domain’s LDAP tree. Without this entry, LDAP will not be able to find any other entries for the domain.
3.12.3.5.2 Create LDAP Structures for Users and Groups
Create LDAP structures for people (users) and for groups with at least the following attributes:
dn: ou=people,dc=example,dc=com ou: people
structuralObjectClass: organizationalUnit objectClass: organizationalUnit
dn: ou=groups,dc=example,dc=com ou: groups
structuralObjectClass: organizationalUnit objectClass: organizationalUnit
Posix users and groups are the two top-level items which will be needed in order to use LDAP for authentication.
These organizational units are used to identify the two categories within LDAP.
3.12.3.5.3 Create Unix Accounts
For each Unix user, create an LDAP entry with at least the following attributes (others may be appropriate for your site as well), using variable values appropriate to that user.
dn: uid=username ,ou=people,dc=example,dc=com
If your site implements password expiration in which passwords must be changed every N days (see Section 2.3.1.7), then each entry should also have the attribute:
shadowMax: N
In general, the LDAP schemas for users use uid to refer to the text username, and uidNumber for the numeric UID. This usage may be slightly confusing when compared to the standard Unix usage.
You should not create entries for the root account or for system accounts which are unique to individual systems, but only for user accounts which are to be shared across machines, and which have authentication information (such as a password) associated with them.
3.12.3.5.4 Create Unix Groups
For each Unix group, create an LDAP entry with at least the following attributes:
dn: cn=groupname ,ou=groups,dc=example,dc=com
Note that each user has a primary group, identified by the gidNumber field in the user’s account entry. That group must be created, but it is not necessary to list the user as a memberUid of the group. This behavior should
be familiar to administrators, since it is identical to the handling of the /etc/passwd and /etc/group files.
Do not create entries for the root group or for system groups, but only for groups which contain human users or which are shared across systems.
3.12.3.5.5 Create Groups to Administer LDAP
If a group of LDAP administrators, admins , is desired, that group must be created somewhat differently.
The specification should have these attributes:
LDAP cannot use Posix groups for its own internal authentication — it needs to compare the username specified in an authenticated bind to some internal groupOfUniqueNames. If you do not specify an LDAP administrators’
group, then all LDAP management will need to be done using the LDAP root user (Manager). For reasons of auditing and error detection, it is recommended that LDAP administrators have unique identities. (See Section 2.3.1.3for similar reasoning applied to the use of sudo for privileged system commands.)
3.12.3.6 Configure slapd to Protect Authentication Information
Edit the file /etc/openldap/slapd.conf. Add or correct the following access specifications:
1. Protect the user’s password by allowing the user himself or the LDAP administrators to change it, allowing the anonymous user to authenticate against it, and allowing no other access:
access to attrs=userPassword
2. Allow anyone to read other information, and allow the administrators to change it:
access to *
by group/groupOfUniqueNames/uniqueMember="cn=admins ,ou=groups,dc=example,dc=com " write by * read
Access rules are applied in the order encountered, so more specific rules should appear first. In particular, the rule restricting access to userPassword must appear before the rule allowing access to all data. The shadowLastChange attribute is a timestamp, and is only critical if your site implements password expiration. If
your site does not have an LDAP administrators group, the LDAP root user (called Manager in this guide) will be able to change data without an explicit access statement.
3.12.3.7 Correct Permissions on LDAP Server Files
Correct the permissions on the ldap server’s files:
# chown ldap:root /var/lib/ldap/*
CCE 4484-2, 4502-1
Some manual methods of inserting information into the LDAP database may leave these files with incorrect permissions. This will prevent slapd from starting correctly.
3.12.3.8 Configure iptables to Allow Access to the LDAP Server
Determine an appropriate network block, netwk , and network mask, mask , representing the machines on your network which will synchronize to this server.
Edit /etc/sysconfig/iptables. Add the following lines, ensuring that they appear before the final LOG and DROP lines for the RH-Firewall-1-INPUT chain:
-A RH-Firewall-1-INPUT -s netwk /mask -m state --state NEW -p tcp --dport 389 -j ACCEPT -A RH-Firewall-1-INPUT -s netwk /mask -m state --state NEW -p tcp --dport 636 -j ACCEPT
The default Iptables configuration does not allow inbound access to any services. These modifications allow access to the LDAP primary (389) and encrypted-only (636) ports, while keeping all other ports on the server in their default protected state. See Section2.5.5for more information about Iptables.
Note: Even if the LDAP server restricts connections so that only encrypted queries are allowed, it will probably be necessary to allow traffic to the default port 389. This is true because many LDAP clients implement encryption by connecting to the primary port and issuing the STARTTLS command.
3.12.3.9 Configure Logging for LDAP
1. Edit the file /etc/syslog.conf. Add or correct the following line:
local4.* /var/log/ldap.log
2. Create the log file with safe permissions:
# touch /var/log/ldap.log
# chown root:root /var/log/ldap.log
# chmod 0600 /var/log/ldap.log
3. Edit the file /etc/logrotate.d/syslog and add the pathname /var/log/ldap.log
to the space-separated list in the first line.
4. Edit the LDAP configuration file /etc/openldap/slapd.conf and set a reasonable set of default log parameters, such as:
loglevel stats2
OpenLDAP sends its log data to the syslog facility local4 at priority debug. By default, RHEL5 does not store this facility at all. The syslog configuration suggested here will store any output logged by slapd in the file /var/log/ldap.log, and will include that file in the standard log rotation for syslog files.
By default, LDAP’s logging is quite verbose. The loglevel parameter is a space-separated list of items to be logged. Specifying stats2 will reduce the log output somewhat, but this level will still produce some logging every time an LDAP query is made. (This may be appropriate, depending on your site’s auditing requirements.) In order to capture only slapd startup messages, specify loglevel none.
See slapd.conf(5) for detailed information about the loglevel parameter. See Section2.6.1.1 for more infor-mation about syslog.