Linux.com

If client machines are to authenticate through LDAP, administrators must make sure user changes are reflected within the LDAP server. Most user management utilities on a client system expect to find information in files like /etc/passwd and /etc/group. If such information is only available through LDAP, utilities may complain about unknown users. To make changes in these cases, an administrator must modify the corresponding LDAP entries. While utilities such as phpLDAPadmin can help with this task, you must know what you're doing if you're to use them effectively.

Changing user information in LDAP

Just as creating users and groups with LDAP is often a process of populating and adding Lightweight Directory Interchange Format (LDIF) files, so is the process of making LDAP changes. Suppose you had used the following LDIF file to add a user called "myuser" to LDAP:

	dn: cn=Myuser,ou=People,dc=example,dc=org
	cn: Myuser
	objectClass: posixAccount
	objectClass: shadowAccount
	objectClass: inetOrgPerson
	sn: User
	uid: myuser
	uidNumber: 1025
	gidNumber: 9000
	homeDirectory: /tmp

Later you decide you would like a directory other than /tmp as myuser's home. Make a file with a name like myuser_change.ldif and add the following:

	dn: cn=Myuser,ou=People,dc=example,dc=org
	homeDirectory: /home/myuser

Notice all that is needed here is the DN (Distinguished Name) and the information we wish to change. Though we only changed the home directory, we could also have changed attributes like the uidNumber or uid. Add your changes with the ldapmodify command:

ldapmodify -x -D "cn=admin,dc=example,dc=org" -W -f myuser_change.ldif

Because the DN is a unique identifier, deleting a DN with the ldapdelete command will remove everything about a user or group:

ldapdelete -x -D "cn=admin,dc=example,dc=org" -W "cn=Myuser,ou=People,dc=example,dc=org"

Encrypting communication between the clients and server

Our LDAP authentication system works well but has a major drawback: nothing is encrypted. Anyone with a packet analyzer and access to the network can read all communication between the client and server, so it's vital to enable LDAP encryption.

OpenLDAP offers two major methods of encrypting communication: LDAP with Transport Layer Security (TLS), and LDAP over Secure Sockets Layer (SSL). LDAP with TLS describes a normal LDAP session where a client requests SSL communication. This type of encryption would occur over the normal LDAP port (389). LDAP over SSL is LDAP being transmitted through an SSL tunnel over port 636. This communication is also called "ldaps://". Both approaches offer the same amount of security. Our example will use the latter approach, LDAP over SSL.

On your machine running OpenLDAP, ensure you have OpenSSL installed. If not, issuing a simple apt-get install openssl will do the trick for Debian systems. If you're using a different Linux distribution, you should be able to find packages for OpenSSL.

Our example will create our own CA (certificate authority), but you can have a third party act as a certificate authority as well. The following commands create our CA:

mkdir /etc/myca
cd /etc/myca
sh /usr/lib/ssl/misc/CA.sh -newca

After running the CA.sh script, you will be prompted to enter a certificate filename or press Enter for a new certificate. In this case, you'll want to press Enter. Then you'll be prompted for a pass phrase; use "cacert," and enter it twice. Then you'll be prompted for the following information:

	Country Name (2 letter code) [AU]: US
	State or Province Name (full name) [Some-State]: Yourstate
	Locality Name (eg, city) []: Your City
	Organization Name (eg, company) [Internet Widgits Pty Ltd]: Exampleorg
	Organizational Unit Name (eg, section) []: Exampleunit
	Common Name (eg, YOUR name) []:	example.org
	Email Address []: ldapadmin@example.org

Enter the correct information for your company or organization.

The Common Name, or "CN" for short, must be a fully qualified domain name pointing to your server. Incorrect CN values will completely break encryption, and there exist countless examples of this error on mailing lists and forums throughout the Internet.

Next we will create a certificate request and private key. Perform the following:

openssl req -new -nodes -keyout newreq.pem -out newreq.pem

You will then be prompted for the following information:

	Country Name (2 letter code) [AU]: US
	State or Province Name (full name) [Some-State]: Yourstate
	Locality Name (eg, city) []: Your City
	Organization Name (eg, company) [Internet Widgits Pty Ltd]: Exampleorg
	Organizational Unit Name (eg, section) []: Exampleunit
	Common Name (eg, YOUR name) []: example.org
	Email Address []: ldapadmin@example.org

Enter the appropriate information for your certificate. You will also be prompted for a challenge password and optional company name, which you can leave blank. OpenLDAP does not support password-protected private keys.

Notice the questions are roughly the same as the ones we saw before, and be aware that the same domain name warnings apply to the CN value here. The CA we created earlier will now sign our certificate request, and we will move the resulting files into place:

sh /usr/lib/ssl/misc/CA.sh -sign

Enter your CA password and answer "y" to the two questions, then copy the certificates to /etc/ldap:

cp demoCA/cacert.pem /etc/ldap/cacert.pem
cp newcert.pem /etc/ldap/servercrt.pem
cp newreq.pem /etc/ldap/serverkey.pem
chmod 600 /etc/ldap/serverkey.pem

We now have all the files we need to enable LDAP encryption. Edit the LDAP daemon's configuration file, /etc/ldap/slapd.conf, and add the following values:

	TLSCACertificateFile /etc/ldap/cacert.pem
	TLSCertificateFile /etc/ldap/servercrt.pem
	TLSCertificateKeyFile /etc/ldap/serverkey.pem
	loglevel	256

This tells slapd where to find our certificates and key, and we added an option to enable more verbose logging. Next we need to start an LDAP daemon that listens on port 636. To test your setup and get immediate feedback, start a debugging slapd. Ensure no other instances of slapd are running and issue the following command as root:

slapd -h 'ldap:// ldaps://' -d1

This command starts a normal slapd running on port 389 and an SSL-only slapd running on port 636. If you messed up any of the above steps, slapd will refuse to start with a sometimes less-than-helpful error message.

Client encryption configuration

Once the server is running smoothly and listening on port 636, we can configure a client. While on the client machine, open /etc/ldap/ldap.conf and make the following changes:

	BASE    dc=example,dc=org
	URI     ldaps://example.org
	TLS_REQCERT allow

We changed the URI stanza to consult ldaps:// instead of the unencrypted ldap://. The TLS_REQCERT stanza allows the client to request the server's certificate, alleviating the need to place a copy of the certificate on each client machine.

Next we need to configure the client's authentication files to use our newly minted secure connection. First up is /etc/libnss-ldap.conf. Comment out any "host" lines and ensure only the following exists:

	base dc=example,dc=org
	uri ldaps://example.org
	ldap_version 3

Notice the change to "ldaps://" in the above lines. Next we will edit /etc/pam_ldap.conf and change it to use SSL. Open /etc/pam_ldap.conf and ensure the following exists:

	base dc=example,dc=org
	uri ldaps://example.org/
	ldap_version 3
	rootbinddn cn=admin,dc=example,dc=org
	pam_password exop

Note the mention here of ldaps://. Again, any "host" stanzas or any lines referring to an IP address rather than the CN of the server certificate will break your setup. SSL is extremely picky in this regard.

Since we have made some serious changes, we now need to restart the name service cache daemon (nscd). Issue the command:

/etc/init.d/nscd restart

Because we made the server run a slapd that listens to both insecure and secure connections, we can test normal and encrypted LDAP. First, test a normal LDAP connection:

ldapsearch -x -b dc=example,dc=org -H 'ldap://example.org'

And to test LDAP over SSL:

ldapsearch -x -b dc=example,dc=org -H 'ldaps://example.org'

If the second ldapsearch command worked, client logins will be encrypted. You can verify this by looking at the output on the server terminal you started slapd with. Log in as an LDAP user on your client machine. Congratulations, you've securely authenticated over LDAP.

To make LDAP over SSL the only option on your network, open /etc/default/slapd on the OpenLDAP server and change the SLAPD_SERVICES line to the following:

	SLAPD_SERVICES="ldaps:///"

Linux and LDAP play together nicely, and now we know how to make LDAP more flexible and secure. Making LDAP work with SSL is a sometimes tedious process that grinds to a halt if LDAP is not configured correctly. But the alternative of exchanging unencrypted user information is not an option. With what you now know, you should be able to make the connections work.

Share    Print    Comments