The LDAP Directory Structure

Like X.500, LDAP directory entries are arranged in a tree structure. Under the root, there are branches that represent countries, organizations, organizational units, and people.

In complicated LDAP deployments, in which you have to exchange information with the LDAP databases of other companies, you may want to get a formal organization number from the Internet Assigned Numbers Authority (IANA) to reduce any data conflicts. In the chapter’s example this won’t be necessary. Because there will be no data sharing, I’ll just make up one.

The LDAP Directory Structure

Like X.500, LDAP directory entries are arranged in a tree structure. Under the root, there are branches that represent countries, organizations, organizational units, and people.

In complicated LDAP deployments, in which you have to exchange information with the LDAP databases of other companies, you may want to get a formal organization number from the Internet Assigned Numbers Authority (IANA) to reduce any data conflicts. In the chapter’s example this won’t be necessary. Because there will be no data sharing, I’ll just make up one.

Downloading and Installing the LDAP Packages

Most Red Hat and Fedora Linux software products are available in the RPM format. When searching for the file, remember that the FreeRADIUS RPM’s filename usually starts with openldap followed by a version number, as in openldap-servers-2.1.22-8.i386.rpm.

Required LDAP Server RPMs

Make sure these required LDAP Server RPMs are installed on your LDAP server:

  • openldap

  • openldap-clients

  • openldap-devel

  • nss_ldap

  • openldap-servers

Required LDAP Client RPMs

On your LDAP client, make sure you have these required RPMs:

  • openldap

  • openldap-clients

  • openldap-devel

  • nss_ldap

 

Configuring the LDAP Server

The first stage of the project is to correctly configure the LDAP server. To do so, you must create an LDAP database into which you import the /etc/passwd file. Take a closer look at the steps.

Create a Database Directory

Fedora LDAP defaults to putting all databases in the /var/lib/ldap directory. For the example, create a dedicated example.com directory owned by the user ldap. (The ldap user is always created during the RPM installation process.)

     [[email protected] tmp]# mkdir /var/lib/ldap/example.com
     [[email protected] tmp]# chown ldap:ldap /var/lib/ldap/example.com

Create an LDAP Root Password

Only the LDAP root user can create, import data, and export data into an LDAP database. This user needs an encrypted password. You can create it with the slappasswd command and use the result in the LDAP configuration file.

     [[email protected] tmp]# slappasswd
     New password:
     Re-enter new password:
     {SSHA}v4qLq/qy01w9my60LLX9BvfNUrRhOjQZ
     [[email protected] tmp]#

Edit the slapd.conf File

The main LDAP server configuration file is the /etc/openldap/slapd.conf file. Update it with:

  • A database of the default type ldbm using the domain suffix example.com made up of domain components (DCs) example and com.

  • The root user with a common name (CN), or nickname, of Manager who, as expected, is part of the example and com DCs.

  • The encrypted version of the LDAP root password as well as the location of the LDAP database.

    The configuration file syntax to do this is:

database       ldbm
suffix         "dc=example,dc=com"
rootdn         "cn=Manager,dc=example,dc=com"
rootpw         {SSHA}v4qLq/qy01w9my60LLX9BvfNUrRhOjQZ
directory      /var/lib/ldap/example.com

Start the ldap Daemon

The service command uses the options start, stop, and restart to control the LDAP server’s operation. Use the start option to load the contents of the slapd.conf file:

     [[email protected] tmp]# service ldap start
       Starting slapd:  [ OK  ]
     [[email protected] tmp]#

Convert the /etc/passwd File to LDIF Format

The data on the server’s /etc/passwd file now needs to be converted to LDAP Data Interchange Files (LDIF) format before it can be imported into the LDAP database. You don’t need to import all of the usernames, just the ones you need.

Create the ldapuser Test Account

To create the ldapuser account you’ll use for testing, type the commands:

     [[email protected] tmp]# useradd -g users ldapuser
     [[email protected] tmp]# passwd ldapuser
     Changing password for user ldapuser.
     New password:
     Retype new password:
     passwd: all authentication tokens updated successfully.
     [[email protected] tmp]#

Extract the Desired Records from /etc/passwd

You need to extract the ldapuser information from the /etc/passwd file using the grep command and save it by appending the information to the /etc/openldap/passwd.ldapusers file with the > character:

     [[email protected] tmp]# grep ldapuser /etc/passwd > \
         /etc/openldap/passwd.ldapusers
     [[email protected] tmp]#

If this is your first time creating the LDAP database, you will also want to extract the information for the Linux root account from the /etc/passwd file to a brand new file called /etc/openldap/passwd.root:

     [[email protected] tmp]# grep root /etc/passwd > \
         /etc/openldap/passwd.root
     [[email protected] tmp]#

Find the Conversion Script

The /etc/passwd conversion program is called migrate_passw.pl; you can find it using the locate command. The locate utility updates its database every night and may not be able to find newly installed files. You can use the locate command to do the update ahead of schedule.

     [[email protected] tmp]# locate -u
     [[email protected] tmp]# locate migrate
     ...
     /usr/share/openldap/migration/migrate_passwd.pl
     ...
     [[email protected] tmp]#

Convert the .ldapuser File

You now need to convert the extracted /etc/passwd data into an LDIF that will then be imported into the database. Give the file used by regular users the name /etc/openldap/ldapuser.ldif and the one for the root user the name /etc/openldap/root.ldif:

     [[email protected] tmp]# /usr/share/openldap/migration/migrate_passwd.pl \
     /etc/openldap/passwd.ldapusers /etc/openldap/ldapusers.ldif
     [[email protected] tmp]#

     [[email protected] tmp]# /usr/share/openldap/migration/migrate_passwd.pl \
     /etc/openldap/passwd.root /etc/openldap/root.ldif
     [[email protected] tmp]#

Modify the LDIF Files

With your two new LDIF files, the next step is to import this data into the LDAP database. To prepare for this, you must do some editing and create a new LDIF file that defines the organizational unit.

Edit the User LDIF File

The Fedora migrate_passwd.pl script creates users that are all part of the organizational unit called People, but everyone belongs to the padl.com domain. You now have to edit both LDIF files and convert the string “padl” to “example” in each record. A text editor is fine for the job. For example, at the vi editor’s : prompt, use the command

     %s/padl/example/g

to perform a global substitution of example for padl.

In the slapd.conf file, you gave the root user a common name (CN) of Manager. You now have to add this information to the root LDIF file by inserting this line under the UID line in the file:

     cn: Manager

Create an LDIF File for the example.com Domain

The LDIF files you created from /etc/passwd referred to users only. The attributes of the example.com domain haven’t yet been defined, and you also haven’t defined the organizational unit called People. This can be done using a third LDIF file called /etc/openldap/example.com.ldif, which should look like this:

     dn: dc=example,dc=com
     dc: example
     description: Root LDAP entry for example.com
     objectClass: dcObject
     objectClass: organizationalUnit
     ou: rootobject

     dn: ou=People, dc=example,dc=com
     ou: People
     description: All people in organisation
     objectClass: organizationalUnit

Import the LDIF Files into the Database

Use the LDAP add command to import all three LDIF files into the database starting with the example.com.ldif file, followed by root.ldif, and lastly by ldapusers.ldif.

Enter the LDAP root password you created when you are prompted:

     [[email protected] tmp]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
           -W -f /etc/openldap/example.com.ldif
     [[email protected] tmp]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
           -W -f /etc/openldap/root.ldif
     [[email protected] tmp]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
           -W -f /etc/openldap/ldapusers.ldif
     [[email protected] tmp]#

Test the LDAP Database

You can view all the LDAP database entries all at once with the ldapsearch command; this is a good test to make sure you have all the correct functionality:

     [[email protected] tmp]# ldapsearch -x -b 'dc=example,dc=com' \
         '(objectclass=*)'
     [[email protected] tmp]#

 

Configuring the LDAP Client

Now that the LDAP server is configured properly, you can turn your attention to configuring and testing the clients.

Edit the ldap.conf Configuration File

LDAP clients are configured using the /etc/openldap/ldap.conf file. You need to make sure that the file refers to the LDAP server’s IP address for the domain example.com. The file should look like this:

     HOST 192.168.1.100
     BASE dc=example,dc=com

Edit the /etc/nsswitch File

The /etc/nsswitch.conf file defines the order in which the Linux operating system searches login databases for login information.

You want to configure it to first search its /etc/passwd file. If it doesn’t find the user password information there, it goes to the LDAP server. The easiest way set this up is to use the /usr/bin/authconfig command:

1.
Run /usr/bin/authconfig.
2.
Select LDAP.
3.
Give the LDAP server’s IP address, which is 192.168.1.100 in this case.
4.
Give the base DN as dc[eq]example,dc[eq]com.
5.
Do not select TLS.
6.
Use MD5 and shadow passwords.

The screen should look like this:

     [*] Use Shadow Passwords
     [*] Use MD5 Passwords
     [*] Use LDAP                    [ ] Use TLS
                             Server: 192.168.1.100
                            Base DN: dc=example,dc=com

When finished, look at the /etc/nsswitch.conf file and make sure it has references to LDAP.

Create Home Directories on the LDAP Client

You previously created a user named ldapuser in the group users on server Bigboy. You now need to make sure that this user has a home directory on the LDAP client Smallfry. The example in this section creates the directory and makes ldapuser the owner. As you can see, server Smallfry correctly gets its user information about ldapuser from Bigboy; the chown command doesn’t complain about ldapuser not existing in Smallfry’s /etc/passwd file.

Check If ldapuser Is Missing from the /etc/passwd File

You can look for ldapuser by searching the /etc/passwd file with the grep command. There should be no response.

     [[email protected] tmp]# grep ldapuser /etc/passwd
     [[email protected] tmp]#

Create the Home Directory for ldapuser on the LDAP Client

In this phase, you create the home directory, copy a BASH login profile file into it, and modify the ownership of the directory and all the files to user ldapuser.

Tip

If the chown command fails, it is probably because of an incorrect LDAP configuration in which the LDAP client cannot read the user information from the LDAP server.

In some cases, you may want to use NFS mounts to provide home directories for your users, which will significantly reduce the need to do this step. The benefits and disadvantages of NFSĀ  “Remote Disk Access with NFS,” , “Centralized Logins Using NIS,” covers using NFS for home directories.

     [[email protected] tmp]# mkdir /home/ldapuser
     [[email protected] tmp]# chmod 700 /home/ldapuser/
     [[email protected] tmp]# chown ldapuser:users /home/ldapuser/
     [[email protected] tmp]# ll /home
     total 2
     drwx------    2 ldapuser users        1024 Aug 4 08:05 ldapuser
     [[email protected] tmp]#
     [[email protected] tmp]# cp /etc/skel/.* /home/ldapuser/
     cp: omitting directory `/etc/skel/.'
     cp: omitting directory `/etc/skel/..'
     cp: omitting directory `/etc/skel/.kde'
     [[email protected] tmp]# chown ldapuser:users /home/ldapuser/.*
     [[email protected] tmp]#

Configuring Encrypted LDAP Communication

The secure tunnel (stunnel) utility can be used to intercept regular LDAP communications and encrypt them over an SSL tunnel using the TCP port of your choice. Fortunately, stunnel is installed by default on Fedora Linux, making it even easier to use.

Tip

Add the SSL encryption, only after basic LDAP has been proven to work without encryption. This makes troubleshooting much easier.

Here’s how to encrypt LDAP with Fedora Linux.

Configuring the stunnel LDAP Client

First, you configure the LDAP client to use stunnel:

1.
Edit the ldap.conf file. You have to trick the LDAP client into thinking that the LDAP server is actually running locally as a daemon, so you need to set the HOST enTRy to localhost. You then configure the stunnel utility to intercept this traffic and relay it to the real LDAP server:

HOST localhost
BASE dc=example,dc=com
2.
Create an stunnel user with the useradd command:

[[email protected] tmp]# useradd stunnel
3.
Edit the stunnel.conf configuration file in the /etc/stunnel directory, configuring it as shown:

#
# File: /etc/stunnel (LDAP Client)
#

# Configure stunnel to run as user "stunnel" placing temporary
# files in the /usr/var/run/stunnel/ directory
chroot = /home/stunnel
pid = /stunnel.pid
setuid = stunnel
setgid = stunnel

# Configure logging
debug = 7
output = /var/log/messages

# Use it for client mode
client = yes

# Service-level configuration
[ldap]
accept  = 389
connect = 192.168.1.100:636

At the very end of the file, notice that traffic on the LDAP TCP port 389 is specifically redirected to the LDAP server on TCP port 636 over the secure tunnel.

4.
Start stunnel with the stunnel command:

[[email protected] tmp]# stunnel
5.
Check the log files, especially the last 100 lines of the error log file /var/log/messages, to make sure there are no errors. If there are errors, double check your stunnel configuration file for mistakes.

[[email protected] tmp]# tail -100 /var/log/messages
6.
Make sure stunnel runs on the next reboot. The script /etc/rc.local is run at the end of every boot sequence. Use the locate command to find out where the stunnel program is and then place your stunnel command in /etc/rc.local as shown:

# Run stunnel for LDAP (Fedora file location)
/usr/sbin/stunnel

Configuring the stunnel LDAP Server

After you configure the client, you’re ready to set up stunnel on the LDAP server:

1.
Create an stunnel user using the useradd command:

[[email protected] tmp]# useradd stunnel
2.
Edit the stunnel.conf configuration file located in the /etc/stunnel directory. Configure it as shown:

#
# File: /etc/stunnel (LDAP Server)
#

# Configure stunnel to run as user "stunnel" placing temporary
# files in the /usr/var/run/stunnel/ directory
chroot = /home/stunnel/
pid = /stunnel.pid
setuid = stunnel
setgid = stunnel

# Some debugging stuff
debug = 7
output = /var/log/messages

# Use it for client mode
client = no
cert = /usr/share/ssl/certs/stunnel.pem
key =  /usr/share/ssl/certs/stunnel.pem

# Service-level configuration
[ldap]
accept  = 636
connect = 389

There are a few differences between the client and server stunnel.conf files. The very bottom of the file shows that all traffic received on the secure LDAP port of 636 is redirected to the application listening on LDAP port 389. The file is configured for server mode and a special SSH certificate has been defined for the encryption process. You’ll create the certificates next.

3.
Go to the /usr/share/ssl/certs directory and create the certificate using the make command. Use all the defaults when prompted, but make sure you use the server’s IP address when prompted for your server’s Common Name or hostname.

[[email protected] tmp]# cd /usr/share/ssl/certs
[[email protected] certs]# make stunnel.pem
...
Common Name (eg, your name or your server's hostname) []:
192.168.1.100
...
[[email protected] certs]#

Note

The certificate created only has a 365 day lifetime. Remember to repeat this process next year.

4.
Modify certificate file permissions. The certificate needs to be read by root and the stunnel user. Use the chmod and chgrp commands to do this:

[[email protected] certs]# chmod 640 stunnel.pem
[[email protected] certs]# chgrp stunnel stunnel.pem

[[email protected] certs]# ll /usr/share/ssl/certs
-rw-r----- 1 root stunnel    1991 Jul 31 21:50 stunnel.pem
[[email protected] certs]#
5.
Start stunnel with the stunnel command:

[[email protected] tmp]# stunnel
6.
Check the last 100 lines of the error log file /var/log/messages to make sure there are no errors. If you find errors, double check your stunnel configuration file for mistakes.

[[email protected] tmp]# tail -100 /var/log/messages

The key things to look for are the loading of the certificate, the binding of LDAP to the 636 secure LDAP port, and the creation of the temporary stunnel.pid file:

2004.08.02 08:50:18 LOG7[12102:3210052320]: Certificate:
/usr/share/ssl/certs/stunnel.pem
2004.08.02 08:50:18 LOG7[12102:3210052320]: Key file:
/usr/share/ssl/certs/stunnel.pem
2004.08.02 08:50:18 LOG7[12102:3210052320]: ldap bound to
0.0.0.0:636
2004.08.02 08:50:18 LOG7[12103:3210052320]: Created pid file
/stunnel.pid
7.
Make sure stunnel runs on the next reboot. The script /etc/rc.local is run at the end of every boot sequence. Use the locate command to find out where the stunnel program is and then place your stunnel command in /etc/rc.local:

#
# File : /etc/rc.local
#
# Run stunnel for LDAP (Fedora file location)
/usr/sbin/stunnel

The final step of the preparation is to create home directories for each user to use just like in the unencrypted LDAP example before this. After this is complete, you’ll need to do some basic testing,


Troubleshooting LDAP Logins

You can never be certain about the functioning of any application unless you test it. LDAP is fairly complicated to install and should be as thoroughly tested as possible before you deploy it. Here are some steps you can take to help you sleep better at night.

Test Using ldapsearch

Always run the ldapsearch command on both the LDAP client and server to test your LDAP configuration:

[[email protected] tmp]# ldapsearch -x -b ‘dc=example,dc=com’ \ ‘(objectclass=*)’

When LDAP is configured correctly, the command sends a full database listing to your screen.

Use SSH or the Linux Console

Try to log in as user ldapuser to the LDAP client Linux system as an alternative test. If it fails, try restarting SSH on the LDAP client so that the /etc/nsswitch.conf file can be reread with the new LDAP information. This step is not required in all versions of Linux.

Use the tcpdump Command

If the LDAP configuration files appear correct and LDAP still doesn’t work, then you should try using the tcpdump command, “Simple Network Troubleshooting,” to see whether your systems can correctly communicate with one another. A failure to communicate could be due to poor routing, misconfigured firewalls along the way, or possibly LDAP being turned off on the server.

Test Secure LDAP

On the LDAP server, use the tcpdump command to listen for traffic on the secure LDAP port 636 or ldaps. Run the ldapsearch command on the LDAP client and if everything is configured correctly, you should see packet flows such as this one:

[[email protected] tmp]# tcpdump -n tcp port ldaps tcpdump: listening on eth0 09:20:02.281257 192.168.1.102.1345 > 192.168.1.100.ldaps: S 1665037104:1665037104(0) win 5840 <mss 1460,sackOK,timestamp 74401362 0,nop,wscale 0> (DF) 09:20:02.281356 192.168.1.100.ldaps > 192.168.1.102.1345: S 1911175072:1911175072(0) ack 1665037105 win 5792 <mss 1460,sackOK,timestamp 20737195 74401362,nop,wscale 0> (DF) … … [[email protected] tmp]#

Test Regular LDAP

On the LDAP server, use the tcpdump command to listen for traffic on the regular LDAP port 389 or ldap. Run the ldapsearch command on the LDAP client:

[[email protected] tmp]# tcpdump -n tcp port ldap

If everything is configured correctly, you should see LDAP packet flows similar to those in the last section.

Test Basic Connectivity

The very first step is to use TELNET to determine whether your LDAP server is accessible on TCP port 389 (LDAP) or 636 (LDAPS).

Lack of connectivity could be caused by a firewall in the path between the LDAP server and client or there could be firewall software running on the servers themselves.

Other sources of failure include LDAP not being started at all, the server could be down, or there could be a network related failure.

 

LDAP Works But Is Not Using LDAPS

An LDAPS configuration will default to using regular LDAP if there is an error with the SSL keys. This is usually caused by incorrect permissions and ownerships on the key file.

stunnel Doesn’t Appear to Work

Changes to the stunnel.conf file take effect only after stunnel has been restarted. Unfortunately, there is no stunnel script in the /etc/init.d directory to do this. You have to use the pkill command to stop it and the stunnel command to start it again:

[[email protected] tmp]# pkill stunnel ; stunnel [[email protected] tmp]#

LDAP bind Errors

The LDAP bind utility is used for each login and can give failure errors that are usually not very descriptive. Two of the main ones that usually occur when running the ldapadd command are:

  • Can’t contact LDAP server (81): This is usually caused by not configuring the correct IP address in the LDAP client’s ldap.conf file.

  • Invalid credentials (49): This is usually caused by incorrect dc[eq] statements in the configuration files or in commands used.

Possible stunnel Errors in Fedora Core 2

You may get a cryptonet error when starting stunnel:

Unable to open “/dev/cryptonet”

This is caused by an incompatibility with the hwcrypto RPM used for hardware-, not software-based encryption. You need to uninstall hwcrypto to get stunnel to work correctly:

[[email protected] tmp]# rpm -e hwcrypto

Common LDAP Administrative Tasks

Here are some explanations of how to do many common LDAP tasks. They are all based on our sample organization with DNs of example and com.

Note

You need to always make sure that there are no entries for regular users in the /etc/passwd files of the LDAP clients. These should only reside on the LDAP server.

Starting and Stopping LDAP

You can use the chkconfig command to get ldap configured to start at boot:

     [[email protected] tmp]# chkconfig ldap on

To start, stop, or restart ldap after booting, use:

     [[email protected] tmp]# service ldap start
     [[email protected] tmp]# service ldap stop
     [[email protected] tmp]# service ldap restart

Remember to restart the ldap process every time you make a change to the LDAP database file for the changes to take effect on the running process.

LDAP Users Changing Their Own Passwords

LDAP users can modify their LDAP passwords using the regular passwd command:

     [[email protected] ldapuser]$ passwd
     Changing password for user ldapuser.
     Enter login(LDAP) password:
     New password:
     Retype new password:
     LDAP password information changed for ldapuser
     passwd: all authentication tokens updated successfully.
     [[email protected] ldapuser]$

Modifying LDAP Users by User root

One easy way for the system administrator to manage LDAP users is to modify the regular Linux users’ characteristics on the LDAP server in the regular way and then run a script to automatically modify the LDAP database.

The Modify LDAP User Script

You can use the very simple sample script /usr/local/bin/modifyldapuser to extract a particular user’s information from /etc/passwd and import it into your LDAP database.

The script works by using the grep command to extract the /etc/passwd user record to a temporary file. It then runs the migrate_passwd script on this data and outputs the result to a temporary LDIF file. Next, the script replaces the default padl DC with the example DC and exports this to the final LDIF file. Finally, the ldapmodify command does the update, and then the temporary files are deleted.

     #!/bin/bash

     grep $1 /etc/passwd > /tmp/modifyldapuser.tmp

     /usr/share/openldap/migration/migrate_passwd.pl \
         /tmp/modifyldapuser.tmp /tmp/modifyldapuser.ldif.tmp

     cat /tmp/modifyldapuser.ldif.tmp | sed s/padl/example/ \
         > /tmp/modifyldapuser.ldif

     ldapmodify -x -D "cn=Manager,dc=example,dc=com" -W -f \
         /tmp/modifyldapuser.ldif

     rm -f /tmp/modifyldapuser.*

Remember to make the script executable and usable only by user root with the chmod command:

     [[email protected] tmp]# chmod 700 /usr/local/bin/modifyldapuser
     [[email protected] tmp]#

To use the script, modify the Linux user. In this case, modify the password for user ldapuser by running the modifyldapuser script using ldapuser as the argument. You will be prompted for the LDAP root password:

     [[email protected] tmp]# passwd ldapuser
     Changing password for user ldapuser.
     New password:
     Retype new password:
     passwd: all authentication tokens updated successfully.
     [[email protected] tmp]# modifyldapuser ldapuser
     Enter LDAP Password:
     modifying entry "uid=ldapuser,ou=People,dc=example,dc=com"

     [[email protected] tmp]#

Adding New LDAP Users

You can use the short script in this section to add LDAP users to your database. I’ll also provide an example of how to use it.

Create an LDAP Add User Script

You can create a /usr/local/bin/addldapuser script based on the modifyldapuser script you created earlier. For example:

     #!/bin/bash

     grep $1 /etc/passwd > /tmp/changeldappasswd.tmp

     /usr/share/openldap/migration/migrate_passwd.pl \
         /tmp/changeldappasswd.tmp /tmp/changeldappasswd.ldif.tmp

     cat /tmp/changeldappasswd.ldif.tmp | sed s/padl/example/ \
         > /tmp/changeldappasswd.ldif

     ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f \
         /tmp/changeldappasswd.ldif

     rm -f /tmp/changeldappasswd.*

Add the User to the Database

Adding the user to the database takes three steps:

1.
Create the Linux user on the LDAP server.
2.
Run the addldapuser script with the username as the only argument. This example imports a previously created Linux user named ldapuser. The script prompts you for your LDAP root password:

[[email protected] tmp]# addldapuser ldapuser
Enter LDAP Password:
adding new entry "uid=ldapuser,ou=People,dc=example,dc=com"

[[email protected] tmp]#
3.
Create home directories for the user on all the LDAP client Linux boxes.

Remember that this script adds existing Linux users to the LDAP database. The creation of Linux users still requires the use of the adduser command.

Deleting LDAP Users

Sometimes you want to get rid of users instead of add them. You can create a /usr/local/bin/deleteldapuser script to delete LDAP users from your database. For example:

     #!/bin/bash

     ldapdelete -x -W -D "cn=Manager,dc=example,dc=com" \
          "uid=$1,ou=People,dc=example,dc=com"

To delete the user from the database, run the deleteldapuser script with the username as the only argument. This example below deletes a previously created Linux user named ldapuser. The script prompts you for your LDAP root password:

     [[email protected] tmp]# deleteldapuser ldapuser
     Enter LDAP Password:
     [[email protected] tmp]#

LDAP Web Management Tools

Once you understand the principles behind LDAP management, you may want to use a graphical tool to help with further administration. If the tool misbehaves, at least you’ll now know how to try to fix it behind the scenes from the command line.

The LDAP Account Manager (LAM), which is available at http://lam.sourceforge.net/, is a well known, easy-to-use product. After you feel comfortable enough with the background tasks and concepts outlined in this chapter, you should give it a try

Configuring RADIUS for LDAP

Many network equipment manufacturers use an authorization scheme called RADIUS to filter the types of activities a user can do. The Linux FreeRADIUS server can be configured to talk to a Linux LDAP server to handle login authentication services. In other words, the user logs into the equipment, which then sends a username/password combination to the RADIUS server, the RADIUS server queries the LDAP server to see if the user is a valid one, and then replies to the network equipment with the desired login privileges if the LDAP query is successful.

You’ll have to refer to your manufacturer’s manuals on how to configure RADIUS, but fortunately researching how the FreeRADIUS server interacts with the Linux LDAP server is much simpler. Here are the steps.

Download and Install the FreeRADIUS Packages

Most Red Hat and Fedora Linux software products are available in the RPM format. When searching for the file, remember that the FreeRADIUS RPM’s filename usually starts with freeradius followed by a version number, as in freeradius-0.9.1-1.i386.rpm.

Starting and Stopping FreeRADIUS

You can use the chkconfig command to get the FreeRADIUS daemon, radiusd, configured to start at boot:

     [[email protected] tmp]# chkconfig radiusd on

To start, stop, and restart radiusd after booting, use:

     [[email protected] tmp]# service radiusd start
     [[email protected] tmp]# service radiusd stop
     [[email protected] tmp]# service radiusd restart

Remember to restart the radiusd process every time you make a change to the configuration files for the changes to take effect on the running process.

Configuring the /etc/raddb/radiusd.conf File

The /etc/raddb/radiusd.conf file stores the main RADIUS configuration parameters. You’ll have to update some of the settings to allow LDAP queries from RADIUS:

1.
Activate the use of the LDAP module in the authorize section of the file by uncommenting the word ldap.

authorize {
    ...
    ...
    #
    #  The ldap module will set Auth-Type to LDAP if it has not
    #  already been set
    Ldap
    ...
    ...
}
2.
Activate the use of the LDAP module in the authenticate section by uncommenting the Auth-Type block for LDAP:

Auth-Type LDAP {
    ldap
}
3.
Define the LDAP domain, LDAP server, and password methods to be used in the ldap block. In the example, the LDAP and RADIUS server is the same machine, so you set the LDAP server IP address to localhost:
ldap {
    # Define the LDAP server and the base domain name

    server = "localhost"
    basedn = "dc=example,dc=com"

    # Define which attribute from an LDAP "ldapsearch" query
    # is the password. Create a filter to extract the password
    # from the "ldapsearch" output

    password_attribute = "userPassword"
    filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"

    # The following are RADIUS defaults
    start_tls = no
    dictionary_mapping = ${raddbdir}/ldap.attrmap
    ldap_connections_number = 5
    timeout = 4
    timelimit = 3
    net_timeout = 1
}

These configuration steps only cover how to configure RADIUS to interact with LDAP. You’ll have to define the login attributes and privileges each user will receive and the IP addresses of the various RADIUS clients. We’ll cover these topics next.

Configuring the /etc/raddb/users File

The /etc/raddb/users file defines the types of attributes a user receives upon login. In the case of a router, this may include allowing some user groups to login to a device in a privileged mode, while allowing other only basic access.

One of the first entries in this file is to check the local server’s /etc/passwd file. The very next entry should be one referring to your LDAP server with a fall through statement that will allow additional authorizations to be granted to the LDAP user further down the file based on other sets of criteria.

     #
     # First setup all accounts to be checked against the UNIX /etc/passwd.
     #
     DEFAULT Auth-Type = System
        Fall-Through = 1

     #
     # Defaults for LDAP
     #
     DEFAULT Auth-Type := LDAP
        Fall-Through = 1

Configuring the /etc/raddb/clients.conf File

You can define a shared secret password key to be used by the RADIUS server and its clients in the /etc/raddb/clients.conf file.

Passwords can be allocated for ranges of IP addresses in each network block using the secret keyword. The next example defines the password testing123 for all queries from localhost, but s3astar for the 192.168.1.0/24 network and shrtp3nc1l for the 172.16.1.0/24 network. All RADIUS clients have to peer with the RADIUS server from these networks using the correct password before logins are correctly accepted.

     client 127.0.0.1 {
        secret = testing123
        shortname = localhost
     }

     client 192.168.1.0/24 {
        secret = s3astar
        shortname = home-network
     }

     client 172.16.1.0/24 {
        secret = shrtp3nc1l
        shortname = office-network
}

Troubleshooting and Testing RADIUS

You can now test the various elements of the RADIUS setup.

Server Setup

To test the server, run radiusd in debug mode to see verbose messages about the status of the RADIUS queries. These messages are much more informative than those provided in the /var/log/messages and /var/log/radius/radius.log files.

     [[email protected] tmp]# /usr/sbin/radiusd -X -A

After testing is complete, you must start the radiusd daemon in the normal manner using the command service radiusd start.

Linux Client Setup

For Linux clients, you can perform RADIUS queries with the radtest command. The arguments are the LDAP username, the LDAP user’s password, the LDAP server IP address, an NAS port value (any value between 1 and 100 will work here), and the RADIUS client-server shared secret password key. Successful queries will show an Access-Accept message.

A successful test from the RADIUS server looks like this:

     [[email protected] tmp]# radtest ldapuser "ldapuser-password" \
       localhost 2 testing123
     ...
     rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=99,
     length=20
     ...
     [[email protected] tmp]#

A successful test from a Linux RADIUS client looks like this:

     [[email protected] bin]# radtest ldapuser "ldapuser-password"
     192.168.1.100 2 s3astar
     ...
     rad_recv: Access-Accept packet from host 192.168.1.100:1812, id=51,
     length=20
     ...
     [[email protected] bin]#

In this case, freeradius was installed solely for the purposes of testing the shared secret password key from another network. This is a good troubleshooting tip to verify remote client access before deploying network equipment.

Cisco Client Setup

Here is a sample snippet of how to set up a Cisco device to use a RADIUS server. You can find full coverage of Cisco authentication, authorization, and accounting (AAA) setup using RADIUS on Cisco’s corporate Web site at www.cisco.com.

     aaa new-model
     aaa authentication login default radius enable
     aaa authentication ppp default radius
     aaa authorization network radius

     radius-server host 192.168.1.100
     radius-server timeout 10
     radius-server key shrtp3nc1l

The important thing to note in relation to the example setup is that the radius-server statements define the RADIUS server’s IP address and the shared secret password key.

Errors with Fedora Core 2

The interaction between LDAP and RADIUS on Fedora Core 2 seems to be plagued with a segmentation fault error that you can see on the RADIUS server when running in debug mode. The error looks like this:

     ldap_get_conn: Got Id: 0
     rlm_ldap: attempting LDAP reconnection
     rlm_ldap: (re)connect to localhost:389, authentication 0
     rlm_ldap: bind as / to localhost:389
     Segmentation fault

The only solution I have found is to install the Fedora Core 1 versions of the RADIUS and LDAP RPMs and to edit the /etc/yum.conf file to prevent them from being automatically updated to newer versions.

Conclusion

LDAP is rapidly becoming a de facto standard for remote authentication and authorization of users, not only in the realm of Linux, but also in that of Windows where it is a key component of Active Directory. Usage of LDAP is also becoming increasingly widespread in wireless networking systems. For example in hot spots, ISPs will sacrifice data security for the sake of convenience by not using encryption, but will use LDAP to restrict access to the Internet to people who have purchased pre-paid access codes with a predefined lifetime.

Leave a Reply