Monday, September 17th, 2007
By Roderick W. Smith Read Part One of this series here
Last month's column introduced the basic principles of the Lightweight Directory Access Protocol (LDAP) and presented an outline of how it can be used as a network authentication tool. Using LDAP, you can configure one system (the LDAP server) to maintain a user directory for an arbitrary number of additional computers, which can greatly simplify user administration if your users must have access to a wide variety of computers — say, mail servers, FTP servers, and so on, or many different workstations.
If you read last month's column and followed its procedures, you should now have a simple LDAP configuration. Two tasks remain before you'll have a working LDAP network authentication tool, though: You must load your LDAP server with account information, and you must configure LDAP clients (some of which may be servers for other protocols) to use the LDAP server for their authentication needs. This column covers the first of these tasks; the second task appears in next month's issue.
Reviewing Your Existing Configuration
Last month's column described LDAP terminology, how to configure LDAP to hold Linux account information, how to enable security features, and how to start the LDAP server. If the details of what you did are a bit foggy, you might want to review last month's column before proceeding.
Most of the procedures described this month don't require that the LDAP server actually be running. However, the account maintenance procedures do require the LDAP server to be running. You should be able to start it via a SysV startup script, as described last month.
Understanding LDIF
As noted last month, LDAP is a network protocol that relies on a separate database package as a backend. Once this backend is configured, though, interactions with LDAP, including methods to add, delete, and otherwise modify directory entries, use LDAP tools rather than those of the backend database. To this end, LDAP relies on the LDAP Data Interchange Format (LDIF) to describe information stored in its directories. LDIF is a text format that LDAP can parse, extracting the relevant data for inclusion in the backend database.
When using LDAP as an authentication server, the relevant LDIF information includes the data that's normally stored in /etc/passwd, /etc/shadow, and /etc/group, plus a few LDAP-specific fields. Listing One shows an example LDIF entry for a user, Fred Jones, whose Linux username is fredjones.
dn: uid=fjones,ou=People,dc=luna,dc=edu
uid: fjones
cn: Fred Jones
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}KpP.s/mnFoEoI
shadowLastChange: 12561
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 780
gidNumber: 100
homeDirectory: /home/fjones
gecos: Fred Jones
For the most part, the names of the fields in Listing One ‘s LDIF entry should be self-explanatory to anybody who's already familiar with Linux accounts; however, a few fields require additional explanation. The first of these is the first line in Listing One: The entry begins with the distinguished name (DN) that applies to the account. This DN normally consists of the uid, ou, and one or more dc components. It should uniquely identify the account in question.
The second field that requires explanation is the second line in Listing One. In LDAP parlance, a uid isn't a Linux user ID (UID); the LDAP uid is equivalent to the Linux username. The Linux UID must, of course, be stored in the directory, and in fact it appears later in Listing One, under the heading uidNumber.
The user's password is specified in the LDIF entry in an encrypted form. You can use tools to enter an encrypted password, as described last month; however, as described shortly, there are easier ways to set passwords in most cases.
You can use a few more fields, in addition to those shown in Listing One. These fields relate to shadow password and group features, such as shadowMin, shadowWarning, and memberUid. The tools described shortly create these fields, when necessary.
Don't begin creating LDIF entries for your accounts just yet; tools to help automate the process exist, assuming you've got a working Linux account database. Understanding LDIF is helpful when you modify accounts or add fresh accounts, though. You may want to create a template LDIF entry, perhaps based on an existing account that you migrate, for use when adding new accounts.
Migrating an Existing Account Database
One useful approach to setting up a new LDAP server as an account maintenance system is to migrate an existing Linux account database. The tools to do this are available as scripts from http://www.padl.com/OSS/MigrationTools.html. The links at the bottom of that page retrieve a file called MigrationTools.tgz.
To use the migration tools, you must first edit the migrate-common.ph file and change two lines that hold site-specific defaults. The variables in question are $DEFAULT_MAIL_DOMAIN and $DEFAULT_BASE. They must be set to hold your site's DNS domain name and your directory's base:
$DEFAULT_MAIL_DOMAIN = "luna.edu";
$DEFAULT_BASE = "dc=luna,dc=edu";
This example sets defaults that are appropriate for a fictitious luna.edu domain. If you're using LDAP for more than just login authentication, you might want to make similar adjustments to additional variables, such as $DEFAULT_MAIL_HOST (which points to your site's mail server); however, such changes are unnecessary if you're only using LDAP for network account authentication.
Once you've modified the migrate-common.ph file, you can use two scripts to create LDIF files holding your user and group information:
$ sudo ./migrate_passwd.pl /etc/passwd passwd.ldif
$ sudo ./migrate_group.pl /etc/group group.ldif
You must run these commands as root, because other users won't be able to read the shadow password file, which is necessary for successful creation of the LDIF files. Note that the migrate_passwd.pl script reads your shadow password file, despite the fact that you don't explicitly refer to it on the command line.
The result of typing these two commands is, as you might expect, two LDIF files: passwd.ldif and group.ldif. Unfortunately, these files aren't quite complete. You must add information for the top-level DN to both files.
You must add six lines to the start of the passwd.ldif file:
dn: dc=luna,dc=edu
objectClass: domain
dc: luna
dn: ou=People,dc=luna,dc=edu
objectClass: organizationalUnit
ou: People
Of course, you should modify the domain information to match your own domain. You need only add three lines to the top of the group.ldif file:
dn: ou=Group,dc=luna,dc=edu
objectClass: organizationalUnit
ou: Group
Once again, change the DN to match your own local network.
In addition to making these changes, you may want to peruse the files and remove entries for accounts and groups that you don't want the LDAP server to manage. For instance, your template Linux account files are likely to include accounts for users such as daemon, lp, shutdown, and other system accounts. Adding such accounts to LDAP increases clutter in your directory and could conceivably cause problems if the same username is associated with different Linux UIDs (LDAP uidNumber fields) in a client's local account database and in LDAP, or if a single UID number maps to different usernames. Likewise, you might want to set different root passwords on each client, in which case you should remove the entry for root.
Before proceeding further, you should temporarily shut down your LDAP server, if it's running. Use your SysV startup scripts or other methods to do so. Once you've made these changes, you can add the LDIF files to LDAP by using the slapadd utility:
$ sudo slapadd –v –l passwd.ldif
$ sudo slapadd –v –l group.ldif
Once you've added these entries to your LDAP directory, you can restart the LDAP server.
In principle, you could use the ldapadd utility instead of slapadd; however, ldapadd requires you to have configured LDAP for account maintenance, as described shortly.
Adding Accounts
Chances are that sooner or later you'll need to modify your LDAP account directory after you've migrated an existing Linux account database to LDAP. Naturally, LDAP provides tools to do so; you can add new accounts, modify existing accounts, or delete existing accounts. You can also change passwords, although the client configuration described next month provides an easier way to perform this task.
To create a new account, you must first create an LDIF file that specifies the account. One way to do this is to extract a single account's information from the file with all your system's account data that you created earlier. You can then modify this information in a text editor. The result should resemble Listing One, although of course the details will differ. Be sure that the dn, uid, and uidNumber entries for your new account are unique.
(Once your system is configured to use LDAP for authentication, as described next month, you'll be able to type getent passwd to obtain a complete list of accounts to help avoid LDAP uid and uidNumber collisions.) If you want to set a password at account-creation time, you can use slappasswd to generate an encrypted value, as described last month in reference to the LDAP administrative password.
Before proceeding further, you should temporarily shut down your LDAP server. You can then add your new account to the LDAP account directory by using slapadd, just as you did when you created the initial account directory:
$ sudo slapadd –v -l acct.ldif
You must run this command as root on the LDAP server computer. Additional account management tools require that the LDAP server be running. These commands can be run from the LDAP server computer or from other systems.
Managing Accounts Remotely
Before you can use LDAP for most account maintenance tasks, you must configure at least one system to connect to the LDAP server to perform these tasks. The LDAP server must also be running, as described last month. To configure the LDAP account-maintenance tools, you should edit the /etc/openldap/ldap.conf file. (Don't confuse this file with /etc/ldap.conf, which is used by other LDAP utilities.) You should set the BASE, URI, and TLS_CACERT options in this file:
BASE dc=luna,dc=edu
URI ldaps://ldap.luna.edu
TLS_CACERT /etc/openldap/ssl/certs/slapd-cert.crt
You should modify these entries as appropriate for your system. The BASE option points to the root of your LDAP directory. The URI option specifies the hostname on which the LDAP server is running, preceded by ldaps://. Note that you can perform account maintenance tasks on a computer other than the LDAP server itself. Finally, the TLS_CACERT option points to the certificate file you generated last month. If you want to perform account maintenance tasks on a computer other than the LDAP server system, you must copy the public certificate file to the computer that's to serve as an account maintenance platform.
Once you've taken care of these basics, you can use the ldapadd, ldapmodify, ldappasswd, and ldapdelete utilities to add new accounts, modify existing accounts, change the passwords of existing accounts, and delete existing accounts, respectively. The ldapadd utility's function overlaps with that of slapadd, except that you may run ldapadd as any user on any computer that's configured as just described; slapadd must be run on the LDAP server system. The ldapadd command is also a bit more complex than is the slapadd command:
ldapadd –D cn=manager,dc=luna,dc=edu –W \
–f acct.ldif
You must specify the DN for the directory's administrator, as you specified it when configuring LDAP. The program prompts you for a password; you should enter the one you specified (in encrypted form) in the LDAP configuration file on the server, as described last month.
The ldapmodify command is another name for ldapadd, but when called as ldapmodify, the program enables you to modify an existing entry rather than add a new one. You can create an LDIF file and its entries will replace conflicting entries in the existing directory. Entries that you omit from the LDIF file won't be changed. You can use this technique to alter a user's home directory, login shell, password, or other account features.
One common administrative task is altering user passwords. Instead of using ldapmodify and an LDIF file to do this job, you can change a password using the ldappasswd command:
$ sudo ldappasswd –D cn=manager,dc=luna,dc=edu \
–S -W uid=fjones,ou=People,dc=luna,dc=edu
Before prompting for your administrative password, the program asks for you to enter the new password twice. Because this tool requires the LDAP administrative password, it can't be used by ordinary users. You can, however, configure Linux to have its normal passwd utility update users' LDAP passwords. This topic is covered next month.
To delete an existing account entry, you can use the ldapdelete command:
$ sudo ldapdelete –D cn=manager,dc=luna,dc=edu \
–W uid=fjones,ou=People,dc=luna,dc=edu
Again, you're be prompted for your password. If all goes well, LDAP will delete the specified account (for fjones in the People OU, in this case).
You can use the ldapadd, ldapmodify, and ldapdelete utilities to add, modify, or delete the groups managed by LDAP. The procedures are identical to those for managing accounts; you just need a different LDIF file (modeled after entries in group.ldif) and a different DN to uniquely identify a group rather than an account.
Next Month
You may want to shut down your LDAP server at this point. Although it should now host a working user directory, that directory won't do you much good until you've configured your computers to use it. That task must wait until next month, which covers configuring the Pluggable Authentication Modules (PAM) and Name Service Switch (NSS) subsystems on Linux systems to use an LDAP server.
From: [Linux Magazine]
