Centralized Logins Using LDAP and RADIUS

Centralized Logins Using LDAP and RADIUS

Introduction

Many centralized database programs have been developed to allow users to log in on multiple computers using a single password. NIS was one of the first, but it doesn't encrypt the password transaction. It also uses the portmapper daemon, which uses an unpredictable range of TCP ports that are difficult for firewalls to track. LDAP (Lightweight Directory Access Protocol) provides an alternative based on the X.500 standard.

The X.500 standard defines how globally referenced directories of people should be structured. X.500 directories are organized under a common root directory in a tree hierarchy with different levels for each category of information, such as country, state, city, organization, organizational unit, and person. Designed to provide a simpler yet robust implementation of X.500, LDAP was originally used as the backbone of Microsoft's Active Directory Service and Novell's Novell Directory Services (NDS) products. LDAP can also interact with other login programs, such as Remote Authentication Dial-in User Service (RADIUS), which the network equipment of many ISPs uses to manage dialup Internet access.

It was later recognized that LDAP had features that could make it a desirable replacement for NIS in some scenarios. For example, it uses a single TCP port (389) for regular communication and another port (636) for encrypted transactions. LDAP also can interact with many login authentication, authorization, and accounting programs external to Linux and UNIX.

This chapter will first show you how to install and use LDAP on Fedora Linux systems, then go on to explain how LDAP interacts with RADIUS.

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.

Scenario

These concepts are easier to explain when working from an example, so imagine the IT department in a small organization called example.com has many Linux servers it needs to administer.

The company wants a simple, secure, centralized login scheme for all of the servers.

It has decided to use the LDAP domain example.com for its LDAP database, in which one domain component (DC) will be example, and the other will be com.

The database will have only one organizational unit simply called People, which is the LDAP default.

Each person will have such attributes as a username (User ID or UID), password, Linux home directory, and login shell.

The Fedora Linux server named bigboy with the IP address 192.168.1.100 will act as the LDAP server containing the database.

The Fedora Linux server named smallfry will be used to test the system as the LDAP client and has the IP address 192.168.1.102.

Server bigboy has a special user account named ldapuser that will be used to test the LDAP logins.

Here is how all that is accomplished.

Downloading And Installing The LDAP Packages

Most RedHat 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. (For more detail on downloading and installing, see Chapter 6, 'Installing Linux Software')

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

Required LDAP Server RPMS

You will have to make sure the following packages are installed on your LDAP server.

openldap

openldap-clients

openldap-devel

nss_ldap

openldap-servers

Required LDAP Client RPMS

You will have to make sure the following packages are installed on your LDAP client.

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 and 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.)

[root@bigboy tmp]# mkdir /var/lib/ldap/example.com

[root@bigboy 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.

[root@bigboy tmp]# slappasswd

New password:

Re-enter new password:

v4qLq/qy01w9my60LLX9BvfNUrRhOjQZ

[root@bigboy tmp]#

Edit the slapd.conf file

The LDAP server's daemon is named slapd and its configuration file is named /etc/openldap/slapd.conf. Update it with:

A database of the default type bdb 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 bdb

suffix 'dc=example,dc=com'

rootdn  'cn=Manager,dc=example,dc=com'

rootpw  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 slapd daemon's operation. Use the start option to load the contents of the slapd.conf file.

Some LDAP versions require a DB_CONFIG file to be installed in the LDAP database directory. Before starting LDAP, you may need to copy a sample template file from /etc/openldap to /var/lib/ldap/example.com.

[root@bigboy tmp]# cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/example.com/DB_CONFIG

[root@bigboy tmp]# service ldap start

Starting slapd: [ OK ]

[root@bigboy 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.

[root@bigboy tmp]# useradd -g users ldapuser

[root@bigboy tmp]# passwd ldapuser

Changing password for user ldapuser.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

[root@bigboy 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 a file called /etc/openldap/passwd.ldapusers file with the > character.

[root@bigboy tmp]# grep ldapuser /etc/passwd >

/etc/openldap/passwd.ldapusers

[root@bigboy 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.

[root@bigboy tmp]# grep root /etc/passwd >

/etc/openldap/passwd.root

[root@bigboy 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.

[root@bigboy tmp]# updatedb

[root@bigboy tmp]# locate migrate

/usr/share/openldap/migration/migrate_passwd.pl

[root@bigboy 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.

[root@bigboy tmp]# /usr/share/openldap/migration/migrate_passwd.pl

/etc/openldap/passwd.ldapusers /etc/openldap/ldapusers.ldif

[root@bigboy tmp]#

[root@bigboy tmp]# /usr/share/openldap/migration/migrate_passwd.pl

/etc/openldap/passwd.root /etc/openldap/root.ldif

[root@bigboy 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.

[root@bigboy tmp]# ldapadd -x -D 'cn=Manager,dc=example,dc=com'

-W -f /etc/openldap/example.com.ldif

[root@bigboy tmp]# ldapadd -x -D 'cn=Manager,dc=example,dc=com'

-W -f /etc/openldap/root.ldif

[root@bigboy tmp]# ldapadd -x -D 'cn=Manager,dc=example,dc=com'

-W -f /etc/openldap/ldapusers.ldif

[root@bigboy 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.

[root@bigboy tmp]# ldapsearch -x -b 'dc=example,dc=com'

'(objectclass=*)'

[root@bigboy 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-tui command:

Run /usr/bin/authconfig-tui. The output of this command may be jumbled because your command line shell's language setting may not be compatible. You can usually avoid this problem by placing the string LANG=C in front of the command as shown here.

[root@smallfry tmp]# env LANG=C authconfig-tui

Select LDAP.

Give the LDAP server's IP address, which is 192.168.1.100 in this case.

Give the base DN as dc=example,dc=com

Do not select TLS.

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.

Note: In some Linux versions, the authconfig-tui command is replaced with the authconfig command.

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.

[root@smallfry tmp]# grep ldapuser /etc/passwd

[root@smallfry 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.

Note: 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 are covered in Chapter 29, 'Remote Disk Access with NFS', and Chapter 30, 'Configuring NIS', covers using NFS for home directories.

[root@smallfry tmp]# mkdir /home/ldapuser

[root@smallfry tmp]# chmod 700 /home/ldapuser/

[root@smallfry tmp]# ll /home

total 2

drwx------ 2 ldapuser users 1024 Aug 4 08:05 ldapuser

[root@smallfry tmp]# cp /etc/skel/.* /home/ldapuser/

cp: omitting directory `/etc/skel/.'

cp: omitting directory `/etc/skel/..'

cp: omitting directory `/etc/skel/.kde'

[root@smallfry tmp]# chown -R ldapuser:users /home/ldapuser

[root@smallfry tmp]#

Testing

You next need to do basic testing. For details, see which is covered in the 'Troubleshooting LDAP Logins' section.

Configuring Encrypted LDAP Communication

There are two commonly mentioned methods of encrypting Linux LDAP communications between clients and servers. One method is through the use of the external stunnel utility that protects the data using SSL. The other method also uses SSL, but it is natively supported in LDAP by using its Transport Layer Security (TLS) option and is therefore easier to implement. This section describes both methods.

Using Transport Layer Security (TLS)Encryption

TLS is an updated version of the Secure Socket Layer (SSL) protocol used by many web browsers to do shopping cart checkouts. Like most certificate based encryption schemes it allows a client and server to talk in a trusted manner without the use of a password.

TLS will require you to create a certificate authority (CA) for your organization. A CA is a server that will manage the issuance and authentication of new server certificates used by the LDAP server for TLS. In the example that follows, the CA and LDAP servers are the same device, but guidelines are also provided on how the functions can be assigned to separate servers.

Note: Unlike the stunnel encryption method described later, TLS runs encrypted on LDAP's TCP port 389.

Before we begin configuration it is important to understand how TLS works. This will be discussed next.

How TLS Communication Works

There is a sequence of events that occur prior to the creation of an LDAP communication session using TLS. These include the following steps:

Both the LDAP server and client need to be configured with a shared copy of a CA certificate beforehand.

When the TLS LDAP connection is made, the client and server negotiate their SSL encryption scheme.

The LDAP server then sends its public encryption key and its server certificate.

The LDAP client inspects the server certificate to make sure that it hasn't expired and takes note of the name and key ID of the CA server that issued it. It then checks this CA information with all the CA certificates in its database to determine whether the server certificate should be trusted.

If everything is valid, the LDAP client then creates a random 'premaster' secret encryption key that it encrypts with the LDAP server's public key. It then sends the encrypted encryption key to the LDAP server.

When public keys are created, a special 'private' key is also simultaneously created. Anything encrypted with the public key can only be decrypted with the private key and vice versa. The server then uses its private key to extract the premaster key.

The client and server then use the premaster key to generate a master secret that will be the same for both, but will never be transmitted so that a third-party cannot intercept it.

The master secret key is then used to create session keys that will be used to encrypt all future communication between client and server for the duration of the TLS session.

Now that you understand the TLS process its time to start configuring secure LDAP.

Configuring the TLS Server

We are about to create our own CA server to create and sign server certificates. This process is known as creating a self-signed SSL certificate as opposed to having a trusted third party organization, such as Verisign, doing it on your behalf. The latter method is most commonly used by public websites in which the CA certificates of many well known and trusted CA companies already come installed on your PC as part of your Web browser installation.

Configuration of the server isn't hard, but there are many steps. Let's go!

1. Install the openssl-perl package which will provide the CA.pl script that helps to automate a lot of the certificate generation steps.

[root@bigboy tmp]# yum -y install openssl-perl

2. The location of the CA.pl script will vary with each Linux distribution. Use the updatedb command to update your file locations database to reflect the new files installed with the package and then use the locate command to file the script, which in this case is located at /etc/pki/tls/misc/CA.pl.

[root@bigboy tmp]# updatedb

[root@bigboy tmp]# locate CA.pl

/etc/pki/tls/misc/CA.pl

/usr/share/man/man1/CA.pl.1ssl.gz

[root@bigboy tmp]#

3. Take a look at the contents of the CA.pl script. There is a CATOP variable that determines where CA.pl will place some of the certificate files. With Fedora Core, this defaults to the ../../CA directory. You could edit this to be a specific directory, but the script will get overwritten the original values the next time you update the packages on your system. In this example we'll do most of our work in a newly created /etc/openldap/TLS/data/files directory which will place the CA files in the /etc/openldap/TLS/CA directory.

[root@bigboy tmp]# mkdir -p /etc/openldap/TLS/data/files

[root@bigboy tmp]# cd /etc/openldap/TLS/data/files

[root@bigboy files]#

4. This next step is very important. You need to know the hostname of your system, and it should also be reflected in DNS or the host files of all your TLS LDAP clients. Things will not work other wise. Here it is bigboy.my-web-site.org.

[root@bigboy files]# hostname

bigboy.my-web-site.org

[root@bigboy files]#

5. Now you will run CA.pl for the first of many times. Create your CA certificate using CA.pl with the -newca option. You will be prompted for a PEM encryption pass phrase, use the same phrase for all the following TLS steps. The script will also prompt you for company information, if you don't use the defaults, make sure the information matches each time you run the script. Don't provide any of the 'extra' attributes.

Note: Make sure you place the correct hostname, not its IP address when you are prompted for it. The LDAP clients will only work if the hostname of the certificate matches the hostname, not IP address, of the server defined in their ldap.conf files.

Note: Take note of your PEM encryption pass phrase. Your server default to a 365 day expiry at which point you will have to regenerate them from the CA certificate. If you don't remember the phrase, you'll have to start all over again.

[root@bigboy files]# /etc/pki/tls/misc/CA.pl -newca

CA certificate filename (or enter to create)

Making CA certificate

Generating a 1024 bit RSA private key

writing new private key to '../../CA/private/cakey.pem'

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

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) [GB]:

State or Province Name (full name) [Berkshire]:

Locality Name (eg, city) [Newbury]:

Organization Name (eg, company) [My Company Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server's hostname) []:bigboy.my-web-site.org

Email Address []:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Using configuration from /etc/pki/tls/openssl.cnf

Enter pass phrase for ../../CA/private/cakey.pem:

Check that the request matches the signature

Signature ok

Certificate Details:

Serial Number:

8f:e7:82:39:04:61:79:2b

Validity

Not Before: Jul 3 19:02:39 2006 GMT

Not After : Jul 2 19:02:39 2009 GMT

Subject:

countryName = GB

stateOrProvinceName = Berkshire

organizationName = My Company Ltd

commonName = bigboy.my-web-site.org

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Comment:

OpenSSL Generated Certificate

X509v3 Subject Key Identifier:

FA:B4:14:1E:63:37:43:05:96:3E:E1:D7:24:9A:38:84:17:E4:A2:80

X509v3 Authority Key Identifier:

keyid:FA:B4:14:1E:63:37:43:05:96:3E:E1:D7:24:9A:38:84:17:E4:A2:80

Certificate is to be certified until Jul 2 19:02:39 2009 GMT (1095 days)

Write out database with 1 new entries

Data Base Updated

[root@bigboy files]#

Note: Your CA certificate will be named /etc/openldap/TLS/CA/cacert.pem. The private CA key used to generate all future server certificates will be named /etc/openldap/TLS/CA/private/cakey.pem. Guard this file carefully by making it only readable by the root user.

6. Run CA.pl again, but with the -newreq option to create a new server certificate signing request (CSR) and its associated server private key. Follow the same guidelines as before.

Your CSR will be named newreq.pem and its private key will be newkey.pem; both will be located in your current directory.

[root@bigboy files]# /etc/pki/tls/misc/CA.pl -newreq

Note: If the server certificate is going to be used on a different server running LDAP, then you'll have to use the hostname of that server when you are generating the request.

7. Run CA.pl one more time with the -sign option. The script will use the CSR information to create a server certificate signed by your CA certificate. You will be prompted for the CA private key's PEM pass phrase as a form of validation. Answer 'y' whenever you are prompted to sign the certificate and commit it to the certificate database. Follow the same guidelines for the other prompts as before.

Your new signed certificate will be named newcert.pem.

[root@bigboy files]# /etc/pki/tls/misc/CA.pl -sign

8. The newkey.pem key file in its present form will always require the PEM password for it to be used with TLS. This can cause problems when it is used by programs like the LDAP slapd daemon that don't take advantage of a keyboard. You will have to use the openssl command to remove this requirement.

[root@bigboy files]# openssl rsa -in newkey.pem -out newkey.pem

Enter pass phrase for newkey.pem:

writing RSA key

[root@bigboy files]#

9. Copy the files to their final resting place in the /etc/openssl/cacerts directory.

[root@bigboy files]# cp newkey.pem /etc/openldap/cacerts/slapd-key.pem

[root@bigboy files]# cp ../../CA/cacert.pem /etc/openldap/cacerts/

[root@bigboy files]# cp newcert.pem /etc/openldap/cacerts/slapd-cert.pem

Note: If the server certificate is going to be used on a different server running LDAP, then you'll have to copy these files to the same locations on that server.

10. Alter your LDAP server's slapd.conf file to make the TLS entries map to the newly created PEM files.

# File: slapd.conf

TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3:RSA

TLSCertificateFile  /etc/openldap/cacerts/slapd-cert.pem

TLSCertificateKeyFile /etc/openldap/cacerts/slapd-key.pem

TLSCACertificateFile /etc/openldap/cacerts/cacert.pem

TLSVerifyClient allow

11. Change the permissions and ownership of the /etc/openldap/cacerts files so they are only readable by the slapd daemon that runs as the ldap user. Also secure the contents of the /etc/openldap/TLS directory from prying eyes.

[root@bigboy files]# chown ldap:ldap /etc/openldap/cacerts/*

[root@bigboy files]# chmod 600 /etc/openldap/cacerts/*

[root@bigboy files]# chown root:root /etc/openldap/TLS

[root@bigboy files]# chmod 750 /etc/openldap/TLS

12. Restart the LDAP daemon.

[root@zippy files]# service ldap restart

Configuring the TLS Client

Configuration of the client is much quicker as you will soon see. Here are the steps:

1. Run authconfig-tui and make sure your options match these screens.

----- ----- ---------Authentication Configuration ----- ----- ---------

|

| User Information Authentication |

| [ ] Cache Information [*] Use MD5 Passwords |

| [ ] Use Hesiod [*] Use Shadow Passwords |

| [*] Use LDAP [*] Use LDAP Authentication |

| [ ] Use NIS [ ] Use Kerberos |

| [ ] Use Winbind [ ] Use SMB Authentication |

[ ] Use Winbind Authentication |

[ ] Local authorization is sufficient |

|

| ---------- -------- |

| | Cancel | | Next | |

| ---------- -------- |

|

| |

----- ----- --------- LDAP Settings ----- ----- ---------

|

| [*] Use TLS |

| Server: bigboy.my-web-site.org__________________ |

| Base DN: dc=example,dc=com_____ _______ ______ ________ |

|

| -------- ------ |

| | Back | | Ok | |

| -------- ------ |

|

|

2. Review the contents of /etc/ldap.conf and make sure they have the following entries. The host must match the hostname of the certificate.

# File: /etc/ldap.conf

host  bigboy.my-web-site.org

base  dc=example,dc=com

tls_cacertdir /etc/openldap/cacerts

ssl start_tls

3. Review the contents of /etc/openldap/ldap.conf and make sure they have the following entries. The host must match the hostname of the certificate.

# File: /etc/openldap/ldap.conf

BASE  dc=example,dc=com

HOST bigboy.my-web-site.org

TLS_CACERT /etc/openldap/cacerts/cacert.pem

TLS_REQCERT allow

4. Copy the server's /etc/openldap/cacerts/cacert.pem file to /etc/openldap/cacerts/cacert.pem on the LDAP client.

[root@smallfry tmp]# scp root@bigboy.my-web-site.org:/etc/openldap/cacerts/cacert.pem

/etc/openldap/cacerts/cacert.pem

5. Test your configuration by logging into your LDAP client server via SSL with the ldapuser user's credentials.

TLS Maintenance

The server certificate (slapd-cert.pem) will expire annually and will have to be regenerated every year. The CA certificate (cacert.pem) is valid for three years before having to be regenerated and recopied to all your LDAP clients. You can change these defaults in the CA.pl file by editing the $DAYS variable for the server certificate and the $CADAYS variable for the CA certificate. Make sure that $CADAYS is greater than $DAYS. Here is an example of alternative values.

$DAYS='-days 365'; # 1 year

$CADAYS='-days 1825'; # 5 years

Using stunnel Encryption

The secure tunnel (stunnel) utility can be used to intercept regular LDAP communications and encrypt it 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.

Note: 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.

[root@smallfry 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.

[root@smallfry 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.

[root@smallfry 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.

[root@bigboy 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.

[root@bigboy tmp]# cd /usr/share/ssl/certs

[root@bigboy certs]# make stunnel.pem

Common Name (eg, your name or your server's hostname) []: 192.168.1.100

[root@bigboy 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.

[root@bigboy certs]# chmod 640 stunnel.pem

[root@bigboy certs]# chgrp stunnel stunnel.pem

[root@bigboy certs]# ll /usr/share/ssl/certs

-rw-r----- 1 root stunnel 1991 Jul 31 21:50 stunnel.pem

[root@bigboy certs]#

5. Start stunnel with the stunnel command.

[root@bigboy 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.

[root@bigboy 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 which is covered in the troubleshooting section.

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.

Check Your /var/log/messages file

The first step is to see what type of error massages you are getting on both the LDAP server and client. Lots of valuable information can be obtained using this method and it is covered in much more detail in Chapter 5, 'Troubleshooting Linux with syslog'.

Testing 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.

Troubleshooting with Telnet is covered in Chapter 4, 'Simple Network Troubleshooting', on network troubleshooting.

Testing Using ldapsearch

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

[root@smallfry 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, outlined in Chapter 4, '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.

Testing 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.

[root@bigboy tmp]# tcpdump -n tcp port ldap

If everything is configured correctly, you should see bidirectional LDAP packet flows between the LDAP client and server.

Note: The insecurity of unencrypted LDAP client communication can also be demonstrated by using network packet capture. In this example, the tethereal command is used with the -x flag to view the ASCII contents of LDAP traffic between client and server. The username, password, UID (100), GID (503), shell (/bin/bash) and home directory (/home/ldapuser) of the ldapuser user can all be clearly seen in clear text. It is always a good practice to add an additional layer of security with LDAP TLS encryption which will eliminate this ASCII visibility.

If you are using the stunnel method you would set the tethereal TCP port to ldaps.

[root@bigboy ~]# tethereal -n -x -i eth0 tcp port ldap

0050 69 64 3d 6c 64 61 70 75 73 65 72 2c 6f 75 3d 50 id=ldapuser,ou=P

0060 65 6f 70 6c 65 2c 64 63 3d 65 78 61 6d 70 6c 65 eople,dc=example

0070 2c 64 63 3d 63 6f 6d 30 82 01 04 30 11 04 03 75 ,dc=com00u

0080 69 64 31 0a 04 08 6c 64 61 70 75 73 65 72 30 10 id1ldapuser0.

0090 04 02 63 6e 31 0a 04 08 6c 64 61 70 75 73 65 72 ..cn1ldapuser

00e0 75 73 65 72 50 61 73 73 77 6f 72 64 31 2b 04 29 userPassword1+.)

00f0 7b 63 72 79 70 74 7d 24 31 24 47 53 77 48 53 54 $1$GSwHST

4a 49 24 71 59 4d 65 66 47 32 4f 35 77 6a 7a 70 JI$qYMefG2O5wjzp

0110 77 42 2e 32 4b 70 58 48 31 30 19 04 0a 6c 6f 67 wB.2KpXH10log

0120 69 6e 53 68 65 6c 6c 31 0b 04 09 2f 62 69 6e 2f inShell1/bin/

0130 62 61 73 68 30 12 04 09 75 69 64 4e 75 6d 62 65 bash0uidNumbe

0140 72 31 05 04 03 35 30 33 30 12 04 09 67 69 64 4e r15030gidN

0150 75 6d 62 65 72 31 05 04 03 31 30 30 30 21 04 0d umber11000!..

0160 68 6f 6d 65 44 69 72 65 63 74 6f 72 79 31 10 04 homeDirectory1..

0170 0e 2f 68 6f 6d 65 2f 6c 64 61 70 75 73 65 72 ./home/ldapuser

[root@bigboy ~]#

Testing Secure LDAP

On the LDAP server, when using stunnel, use the tcpdump command to listen for traffic on the secure LDAP port 636 or ldaps. With TLS you would use the regular LDAP port 389 or ldap with the command. Run the ldapsearch command on the LDAP client and if everything is configured correctly, you should see packet flows such as this one.

[root@bigboy 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)

[root@bigboy tmp]#

Note: You can also verify the lack of ACSII strings being sent with LDAP encryption using the tetheral example used previously. Remember to use ldap for TLS encryption and ldaps when using stunnel.

[root@bigboy ~]# tethereal -n -x -i eth0 tcp port ldaps

0000 00 b0 d0 46 32 71 00 b0 d0 4e f2 18 08 00 45 00 F2qN.E.

0010 01 3e 14 2c 40 00 40 06 a1 11 c0 a8 01 64 c0 a8 .>.,@.@d..

0020 01 c8 90 ec 01 85 95 c1 c9 95 90 a3 67 01 80 18 g

0030 08 88 3c 2c 00 00 01 01 08 0a 02 3e d3 b9 02 3e ..<,.>>

0040 ea 23 17 03 01 00 20 a4 47 5e c4 54 87 66 a2 5a .#. .G^.T.f.Z

0050 5d ef 24 77 7f 9b c5 57 84 a1 b6 f0 10 ef 3e be ].$wW>.

0060 bc 91 ec 31 a2 81 5e 17 03 01 00 e0 ee 34 fc 93 1..^4..

0070 f9 b9 3f ba e7 fb 97 78 3e a0 25 09 77 bf c9 b0 ..?.x>.%.w

0080 95 30 ca 6a e8 e7 7f cc a5 77 db e5 30 e6 34 ac .0.j..w..0.4.

0090 e3 d0 84 98 d5 97 1a b5 9f 2b 9c 11 41 b7 ae ed +..A

00a0 0e fc 54 52 89 fd 59 b0 77 42 d4 07 96 83 33 6f ..TR..Y.wB.3o

00b0 fb 85 dd e7 90 dc 83 44 41 1f 8f 1d d3 29 60 28 .DA.)`(

00c0 58 a7 22 8e 6e 16 01 5f fa f1 4f 69 31 78 1e 6c X.'.n.._..Oi1x.l

00d0 a4 23 9e 89 3a 9c 25 37 da 9d 27 03 d4 17 31 9e .#..:.%7..'1.

00e0 30 d8 25 d8 95 57 a3 7b 7f 77 20 7b f4 ee cd 7a 0.%..W.

2. Activate the use of the LDAP module in the authenticate section by uncommenting the Auth-Type block for LDAP:

Auth-Type 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 })'

# The following are RADIUS defaults

start_tls = no

dictionary_mapping = $/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 varius 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

client 192.168.1.0/24

client 172.16.1.0/24

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.

[root@bigboy 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.

[root@bigboy tmp]# radtest ldapuser 'ldapuser-password'

localhost 2 testing123

rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=99, length=20

[root@bigboy tmp]#

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

[root@smallfry 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

[root@smallfry 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 our 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 defacto 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.

Chapter 32, 'Controlling Web Access with Squid', covers the use of the Linux Squid application to cache Web content, restrict Web access by the time of day and via password prompts. Although it is beyond the scope of this book, you should know that you can use LDAP can to complement the functionality of Squid in larger implementations.