SyntaxTechnology

For part 2 of this tutorial, which covers the installation and configuration of the server, click here.

Client Configuration

Now that we’ve gotten our server up and running, it’s time to configure a client to use it. Many Linux distributions require you to manually edit the proper files to configure LDAP authentication, but Red Hat and its derivatives use an automatic system instead. In fact, the files that are required for client configuration should not be configured manually at all. You risk losing your changes since any time you run the configuration wizard it resets the PAM files that allow LDAP authentication.

System-config-authentication

The first method for configuring the client is the graphical system-config-authentication command. If you have an X server installed or have X11 forwarding set up via an SSH connection, you can run this command to drastically simplify the configuration. The command is very simply:

system-config-authentication

This will bring up a window that looks like this:

system-config-authentication

With this window, we can configure everything our client needs to know to support LDAP logins. First, we want the system to use LDAP for user information. This includes UID numbers, GID numbers, home directories, login shells, and other various information we can store about our users. So check the box next to “Enable LDAP Support.” This will also enable the “Configure LDAP” button opposite the checkbox. Click on that button to enter your LDAP server’s information.

LDAP server settings

Here you can enter your base DN and the address of your LDAP server. In this example, the LDAP server is on the same machine as the client. In that case you can use 127.0.0.1 or localhost. If your server is on another machine, you’ll want to use the IP address or hostname of the server. Be aware that if you use a hostname it will need to be resolvable without using LDAP itself. Since you can store hosts in LDAP, it is not uncommon to use LDAP to map hostnames to IP addresses. Don’t make the mistake of putting an LDAP-mapped hostname as the location of the LDAP server.

This is also where you would indicate that the LDAP server is using TLS encryption for connections. Since we aren’t using this feature, we can skip that part.

Next, click on the Authentication tab.

Authentication options

This is where you specify that your client should use LDAP for authentication and not just user information. Just like the User Information tab, you can click on the checkbox next to “Enable LDAP Support” to tell the client to use LDAP. Once again, the “Configure LDAP” button is enabled by clicking on that checkbox. However, you don’t need to configure the LDAP server information a second time. To see that everything is still there, click on the button. Your server information should be identical to what you specified on the User Information tab.

Lastly, click on the Options tab.

Additional authentication options

First, the “Cache User Information” option turns on the nscd daemon that caches user information. This is useful in medium to large scale environments when you have a lot of hits to your LDAP directory, but in smaller environments it’s not necessary. I leave it unchecked as it makes it easier to make changes. You don’t need to remember to restart the nscd daemon when LDAP changes.

The next option is “Use Shadow Passwords.” This tells the system to still use the /etc/shadow file to store passwords. You want to keep this one for system and local accounts. LDAP passwords will be stored in LDAP no matter what. It is considered a security problem to not use the shadow file for local passwords.

The password hashing algorithm is never going to be used by your LDAP users. Since we set up the password-hash option in /etc/openldap/slapd.conf, that will override this setting in system-config-authentication.

You want to keep “Local authorization is sufficient for local users” checked so that all local users such as root can be authenticated without the LDAP server being contacted. This isn’t necessary for local accounts to work correctly, but it’ll potentially save on some traffic to your directory.

The next option is where you have to be careful. If you want to authenticate system accounts to LDAP, you’ll want to check this. This option is useful if you have many servers and want to centralize those logins. However, if you select this and have a user by the same name in LDAP, it could cause conflicts.

Access.conf is a file that indicates which users have access to log into a particular machine. LDAP can also handle access restrictions.  Check this box if you want to do machine authorization at login time.

The last option is to create home directories at first login. This is very useful if you don’t want to have to manually create every user’s home directory. If you have more than a couple users, this will save you lots of time.

Setting Password Hashing Properly

Now that you’ve configured everything, click OK to close that dialog box. System-config-authentication will configure your authentication on your client to use LDAP for you. However, there is one last setting we have to fix manually. System-config-authentication does not set up proper handling of password hashing in /etc/ldap.conf. Open this file in a text editor and search for an uncommented line with this directive:

pam_password crypt

It is possible that it will have md5 in place of crypt, depending on what you had in the “Password hashing algorithm” option of system-config-authentication. We need to change this so that PAM will not hash passwords at all in favor of letting LDAP handle the hashing like we want. Comment that line out by putting a # at the beginning and add this on a new line below it:

pam_password exop

This will tell the client to use an external operation in LDAP.  Then LDAP will use the SSHA algorithm we specified in /etc/slapd.conf. Remember that if you ever change your configuration with system-config-authentication, you’ll need to redo this change to /etc/ldap.conf.

Authconfig

The other method for configuring your client on CentOS is the authconfig command. If you don’t have a GUI available, this is the only option you have without manually editing the files. Authconfig is the utility that is running behind the scenes when you use system-config-authentication. It has all the same options available on the command line. To see all of your options, you can use the -h or –help flags. Those will display the options available along with a description of each to assist you. To accomplish all of the same settings with authconfig that we set with system-config-authentication, here’s the command you’ll need:

authconfig --enableldap --enableldapauth --ldapserver='ldap://127.0.0.1/' --ldapbasedn='dc=example,dc=com' --enablemkhomedir --enableshadow --enablelocauthorize --test

These options are fairly straight forward, and you can use the help information to get more information. Note that not all of these options are required since some of the settings are defaults. I included them to draw attention to the specific options that will affect specifically what we’re working on.

The option that I do want to talk about is –test. This option allows you to do a “dry run” of your configuration settings. It will show you what all of the authentication and authorization settings will be. You’ll notice when you use the –help option that each enable option also has a disable counterpart. That’s because there are two ways to use authconfig. The first is just like we’ve done, but substituting –test for –update. This will update all the settings that you’ve specified without touching the rest. The other way is with –updateall, which will update everything exactly as you specify it on that command line. If you don’t mention a specific option, it will proceed as if you’ve specified the disable option. So you only want to use that option if you specify every single setting you want, including defaults. It’s usually a better idea to use –update by itself to only update the configuration files affected by the options you’re changing. So once you use –test and verify that everything looks the way you want it, remove –test in favor of –update to make the settings effective.

Once again, as with the graphical system-config-authentication, you’ll need to manually change the pam_password option in /etc/ldap.conf to ensure the directory server handles the password hashing. Once you’ve done this, the client configuration is complete.

Testing the Connection

Now you can test your client configuration and your server configuration all at once. There is an easy way to verify that everything is working together without needing a single record in your directory yet. It involves our first opportunity to use one of the client binaries that comes with openldap-clients. The command you’ll run is:

ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base

The ldapsearch tool allows you to search, as a client, through an LDAP server. These same options are available for all of the client binaries, so you’ll end up using them frequently. Here’s each option explained in more detail:

• -x : This tells the server to use simple authentication instead of SASL. SASL is an authentication format that uses additional authorization checks and encryption, so it’s more secure. It’s also much more complicated, so we aren’t using it here.
• -W : This tells the ldapsearch command to prompt you securely for your password. Without this, the password would be required as part of the command. Obviously, this is a security problem since that will include the password in any command history files. This is useful, however, for automated tasks such as backup applications.
• -D : This is the DN that you wish to connect as. In our case, we’re using the Manager account since we have no other records in the directory. Down the road, we will use individual user accounts with these tools as well. This option requires you to pass the string, so you can’t leave the DN string out.
• -b : This tells the server where you want to begin your search. It’s referencing a “base DN,” but this isn’t necessarily the same base DN that you specify in your slapd.conf file. In this particular case, it’s just the base where you want to begin your search, which can be farther down the directory tree than the actual base DN. In this particular case, we want to search an empty DN. This will return information about the server and not records contained within it.
• -s : This tells the server how far you want your search to traverse. The options here are base, sub, and one. Base will search only the level that you specify. Sub will search the entire subtree underneath the DN you specified. One will search one level below the DN you specified. Since you have no records in your directory, all of the options will return the same results as base.

When you enter that command, you’ll be prompted for the Manager’s LDAP password, which you specified in your slapd.conf file. After you enter that password, assuming your connection is successful, you’ll see output similar to this:

# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
objectClass: top
objectClass: OpenLDAProotDSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

This will confirm that your configuration of your server and client are both functioning correctly. If you do not see this output, the error message should help guide you in the right direction. Also, remember that loglevel directive in slapd.conf. If you’re having trouble with the connection between client and server, turn on more logging levels to see if the LDAP log will tell you what’s failing.

To see Part 4 of this tutorial, where I explain how to add data into your new directory, click here.