OpenLDAP How To (Fedora)

http://blog.christophersmart.com/articles/openldap-how-to-fedora/

This tutorial explains how you can set up centralised LDAP authentication for a network, covering both the setting up of the LDAP server and client. Whilst based on Fedora 13, it may also apply to other versions.

LDAP stands for Lightweight Directory Access Protocol, which is a computer protocol for querying and modifying a database backed directory service. While Fedora ships its own LDAP based server (389 Directory Server), we will be using the OpenLDAP implementation, with Berkley Database (bdb) as the database backend. Data is entered into the LDAP server via plain text LDIF (LDAP Data Interchange Format) files. We will use a set of perl scripts from the migrationtools package to create most of these for us, but we will also create a few manually for adding a new user and group.

Finally, there are probably better (and more Fedora-specific) ways to do some of these tasks. If so, please let me know!

Note: For the purposes of this how to, our domain is test.lan and our LDAP server is server.test.lan – replace this with your server details instead!

Outline

  1. Install required packages.
  2. Configure the LDAP server configuration file for our domain, test.lan (dc=test,dc=lan).
  3. Configure the LDAP server to use TLS encryption, using a self-signed certificate.
  4. Start the LDAP server and test.
  5. Create LDIF files of our base domain, users and groups using migration tools.
  6. Populate the LDAP server using LDIF files.
  7. Configure clients to authenticate to LDAP server over secure channel.

Prerequisites

This how to assumes you have performed a standard Fedora install, or a base install with relevant configuration tools installed.

  1. Networking is configured (see below).
  2. DNS is working, or at least you can resolve the LDAP server’s FQDN (fully qualified domain name), i.e. server.test.lan.
  3. You have the (awesome) text editor vim installed (if not, substitute and edit as required).

First, you may wish to use standard network configuration rather than NetworkManager on the server.

If so, let’s become root, disable NetworkManager and tell it to not start automatically on boot. 

 [user@server ~]$ su -
 [root@server ~]$ service NetworkManager stop
 [root@server ~]$ chkconfig NetworkManager off

Next we enable the standard networking daemon and tell it to start automatically on boot. 

 [root@server ~]$ service network start
 [root@server ~]$ chkconfig network on

Now you’ll need to configure networking, which you can do via the graphical tool. 

 [root@server ~]$ service network start
 [root@server ~]$ system-configure-network-gui

Set eth0 (or your network device) to be static/use DHCP, whatever is required by your network setup, by selecting it and clicking edit.

Finally, activate the device and close the tool.

Now that your network is configured, let’s get started with LDAP!

Let’s begin!

As we need to run lots of commands on the LDAP server, it’s easier to to this as root.

If you’re not yet root, become so. 

[user@server ~]$ su -

We must install the required packages. The first is the LDAP server itself, the second is a set of perl scripts which help us create LDIF files for populating the LDAP server. 

[root@server ~]$ yum install openldap-servers migrationtools

There is an all-powerful root LDAP user which will populate our directory. Rather than publishing this password in cleartext with in the configuration file, we want to encrypt it.

To do so, we run the slappasswd command, which will encrypt our password and return the value. 

[root@server ~]$ slappasswd
New password:
Re-enter new password:
{SSHA}MP0BeMJzmCoCi5olBhwcRDYJaGBFgN5K

Copy the final encrypted output (i.e. {SSHA}MP0BeMJzmCoCi5olBhwcRDYJaGBFgN5K) for use in the next section.

Configuration

Previously, OpenLDAP was previously managed via a single configuration file (/etc/openldap/slapd.conf), however these days the configuration for LDAP is stored inside the LDAP server itself! As such, the configuration is done by editing LDIF files under the /etc/openldap/slapd.d/ directory.

Fedora supports both methods. We can either delete the slapd.d directory and use a slapd.conf file, or go along with the new method and edit the LDIF files before starting up our LDAP server.

Config file

If you wish to use the config file (which some will find easier), then follow these instructions.

Remove the existing slapd.d directory (else Fedora will not read our configuration). 

[root@server ~]$ rm -Rf /etc/openldap/slapd.d/

Create a new config file from the existing template. 

[root@server ~]$ cp -a /etc/openldap/slapd.conf.bak /etc/openldap/slapd.conf

Now that we have the base files in place, we need to begin configuring the file. We need to set several options, most importantly the domain (dc=test,dc=lan), and the admin password.

First, open it. 

[root@server ~]$ vim /etc/openldap/slapd.conf

If you’re using Vim, just run the following command. 

:%s/dc=my-domain,dc=com/dc=test,dc=lan/g

If not, find and set the following domain values 

suffix  "dc=test,dc=lan"
 rootdn "cn=Manager,dc=test,dc=lan"
...
 # allow only rootdn to read the monitor
 access to *
      by dn.exact="cn=Manager,dc=test,dc=lan" red
      by * none

Next, we need to set the admin user’s password (which we generated earlier) and tell LDAP where to find the certificate and key for encryption (which we will create in a later step). 

rootpw {SSHA}MP0BeMJzmCoCi5olBhwcRDYJaGBFgN5K
TLSCertificateFile: /etc/openldap/ssl/slapdcert.pem
TLSCertificateKeyFile: /etc/openldap/ssl/slapdkey.pem

Finally, save and quit the file.

:wq

Non-config file

Here’s now to edit the LDIF files under slapd.d to store the LDAP server configuration within LDAP (cn=config) itself.

The first of two LDIF files is the base database file. 

[root@server ~]$ vim /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{1\}bdb.ldif

If you’re using Vim, then just run the following. 

:%s/dc=my-domain,dc=com/dc=test,dc=lan/g

Else, find and replace the following entry. 

olcRootDN: dc=test,dc=lan

Now we must set the admin password and specify the location of our encryption certificate and key. 

olcRootPW: {SSHA}ccFKiy8ska8IhNwwlaNYxiBNbilWe5M1
olcTLSCertificateFile /etc/openldap/ssl/slapdcert.pem
olcTLSCertificateKeyFile /etc/openldap/ssl/slapdkey.pem

Open the second file, which specifies monitoring privileges. 

[root@server ~]$ vim /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{2\}monitor.ldif

Once again, use Vim to replace the required entry. 

:%s/cn=manager,dc=my-domain,dc=com/cn=Manager,dc=test,dc=lan/g

Or replace it yourself.

That’s it! Now you can continue with the how to.

Database cache

You should now have configured LDAP using either the single config file, or by specifying LDIF files. If not, see above.

Back at the terminal, copy a default DB_CONFIG file which sets cache and tuning options for the Berkley database backend (this also needs to be writeable by the ldap user). 

[root@server ~]$ cp /usr/share/doc/openldap-servers-*/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
[root@server ~]$ chown -Rf ldap:ldap /var/lib/ldap/

Test configuration

Lastly, test your configuration by running the command, and check return: 

[root@server ~]$ slaptest -u 
config file testing succeeded

That’s all the initial base configuration we should need to do! Next we will configure encryption.

Encryption (LDAPS) using TLS

Because we are using LDAP for authentication across a network, we want to encrypt the traffic. This means we can either run LDAP (on default port of 389) with TLS, or the LDAPS (on port 636) with TLS. We will do the latter.

We need to tell Fedora how to start the secure LDAP daemon, which is done by editing the sysconfig entry for ldap. 

[root@server ~]$ vim /etc/sysconfig/ldap

Set the following: 

SLAPD_LDAPS=yes

When the service is started, it will also run LDAP Secure (LDAPS).

Now that we have told LDAP to run on secure port 636 we need to generate SSL keys and configure the LDAP service to use them!

Fedora has a script to automate this process, but it’s easy enough to generate the keys manually (when prompted, fill in the information as below, but replace the hostname with the FQDN of the LDAP server!). 

 [root@server ~]$ mkdir /etc/openldap/ssl/
 [root@server ~]$ openssl req -new -x509 -nodes -out /etc/openldap/ssl/slapdcert.pem -keyout /etc/openldap/ssl/slapdkey.pem -days 365
 Generating a 2048 bit RSA private key
 ....................................................+++
 writing new private key to '/etc/openldap/ssl/slapdkey.pem'

 -----
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 -----
 Country Name (2 letter code) [XX]: AU
 State or Province Name (full name) []: ACT
 Locality Name (eg, city) [Default City]: Canberra
 Organization Name (eg, company) [Default Company Ltd]: Company
 Organizational Unit Name (eg, section) []: Section
 Common Name (eg, your name or your server's hostname) []: server.test.lan
 Email Address []: user@test.lan

This will create the two required keys in the /etc/openldap/ssl/ directory, but we need to make sure that the ldap user can read them. 

[root@server ~]$ chown -Rf root:ldap /etc/openldap/ssl
[root@server ~]$ chmod -Rf 750 /etc/openldap/ssl

We have already told the LDAP server to use them, so once we start the server it should be good to go!

Start LDAP service

It’s time to start the LDAP service, and tell it to start on bootup. 

 [root@server ~]$ service slapd start
 Starting slapd:                                            [  <font color=green>OK</font>  ]

Test that the server came up properly and is listening on the LDAPS port 

 [root@server ~]$ netstat -lt |grep ldap
 tcp  0  0 *:ldap   *:*  LISTEN
 tcp  0  0 *:ldaps  *:*  LISTEN

If so, tell Fedora to start the LDAP server on bootup. 

[root@server ~]$ chkconfig slapd on

 [root@server ~]$ ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
 # extended LDIF
 #
 # LDAPv3
 # base <> with scope baseObject
 # filter: (objectclass=*)
 # requesting: namingContexts 
 #

 #
 dn:
 namingContexts: dc=test,dc=lan

 # search result
 search: 2
 result: 0 Success

 # numResponses: 2
 # numEntries: 1

This should returns a success, as above.

If all that went as planned, congratulations, you have a basic LDAP server configured! Next we need to populate this with our users and groups.

Configure base domain

We should now have a base LDAP server running, configured for our domain. However we do not have any users (People) or groups (Group) configured! We do that in the next step Now we need to set up our base, authentication and group files.

This is done via a migration of your existing local unix accounts already configured on the system, which are converted into an LDIF file for loading into LDAP. First however, we need to create a template base.ldif file which creates the base structure of our directory (test.lan), which we will import into LDAP database first. 

[root@server ~]$ vim base.ldif

Add the following to the base.ldif file: 

dn: dc=test,dc=lan
dc: test
objectClass: top
objectClass: domain

dn: ou=People,dc=test,dc=lan
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group,dc=test,dc=lan
ou: Group
objectClass: top
objectClass: organizationalUnit

Now that we have the base information for our LDAP structure, we can (hopefully!) import that information into our LDAP database (use the password you created above): 

[root@server ~]$ vim base.ldif
[root@server ~]$ ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f ./base.ldif
 Enter LDAP Password:
 adding new entry "dc=test,dc=lan"
 adding new entry "ou=People,dc=test,dc=lan"
 adding new entry "ou=Group,dc=test,dc=lan"

If you saw the above, then it worked! If you get an error about authentication issues connecting to my-domain.com then it’s not reading your configuration properly, and is using the default. Stop the service and start again.

Migrate users and groups

We are now going to use the migration tools to create ldif files for our existing users and groups, which we will import into LDAP like in the previous step.

First, tell the migration scripts which domain to use by default (we want to use test.lan instead of the default padl.com). 

[root@server ~]$ vim /usr/share/migrationtools/migrate_common.ph

Set the following: 

 # Default DNS domain
 $DEFAULT_MAIL_DOMAIN = "test.lan";
 
 # Default base 
 $DEFAULT_BASE = "dc=test,dc=lan";

Now, we will use the migration script to create an ldif which we will use to populate LDAP with all our existing users (note, this will pull in the user account). 

[root@server ~]$ /usr/share/migrationtools/migrate_passwd.pl /etc/passwd people.ldif

Once you have the file, we can import the entries into LDAP: 

[root@server ~]$ ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f people.ldif

Now, we will use the migration script to create an ldif which we will use to populate LDAP with all our existing groups (note, this will pull in the user group). 

[root@server ~]$ /usr/share/migrationtools/migrate_group.pl /etc/group group.ldif

Once you have the file, we can import the entries into LDAP: 

[root@server ~]$  ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f group.ldif

Now, we have our database populated with info. It’s time to test our work. First, you can use the ldapsearch command to look for your username. You should get a successful response back, as below. 

[root@server ~]$ ldapsearch -xWD “cn=Manager,dc=test,dc=lan” -b “dc=test,dc=lan” “cn=user”
 # extended LDIF
 #
 ...
 # user, Group, test.lan
 dn: cn=user,ou=Group,dc=test,dc=lan
 objectClass: posixGroup
 objectClass: top
 cn: user
 userPassword:: E2NyeXB0fXG=
 gidNumber: 500

 # search result
 search: 2
 result: 0 Success
 ...

Adding a new user and group

To add a new user, we create an ldif for the user account, and the group. Then we import these into the LDAP server, like we did with the base, people and groups previously.

To add a user, simply create an ldif file (like chris.ldif) with contents like so: 

dn: uid=chris,ou=People,dc=test,dc=lan
uid: chris
cn: Chris Smart
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$6$XemGNmMU9f3FRFo/vt7Uld/gUcP/2N7/R.uw5SK.
shadowLastChange: 14846
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 501
gidNumber: 501
homeDirectory: /home/chris
gecos: Chris Smart

Then, add the group information for this user (like chris-group.ldif): 

dn: cn=chris,ou=Group,dc=test,dc=lan
objectClass: posixGroup
objectClass: top
cn: chris
userPassword: {crypt}x
gidNumber: 501

Then add these into LDAP! 

[root@server ~]$ ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f chris.ldif
#Enter LDAP Password:
#adding new entry "uid=chris,ou=People,dc=test,dc=lan"
 
[root@server ~]$ ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f chris-group.ldif
#Enter LDAP Password:
#adding new entry "cn=chris,ou=Group,dc=test,dc=lan"

Now you have a new user called chris!

Client Configuration

Now that we have a server which is responding correctly, we can configure our clients to authenticate to the LDAP server.

For Fedora machines, authconfig-gtk or authconfig-tui: 

[root@server ~]$ authconfig-gtk
# or
[root@server ~]$ authconfig

In the tool, select and fill in the details below.

Now, we need to tell Fedora the location of the encryption certificate. Click on Download CA Certificate and pass the location of the file. Note: If this is a local machine, you can use file://, however if it’s a remote machine, you’ll need to put the certificate on an NFS, FTP or HTTP share.

On the Advanced Options tab, tick Create home directories on the first login – else although users can authenticate, they won’t have a home directory when they log in!

Hit Apply and we should now be able to log in as our users!

Of course, to test this you can just log out and back in, but a quicker way (in case something’s not right) is to open a non-root terminal and switch to the new user you created (i.e. chris as above). 

[user@server ~]$ su - chris

This should ask for chris’ password and if everything’s working correctly, you should be able to switch to this user.

If it fails, check your /var/log/messages to see if there are some helpful errors.

Licensed under Creative Commons 3.0 non-ported license.