The LDAP server itself (slapd) is controlled through a file called slapd.conf, which is usually stored in /etc/openldap. Two other LDAP configuration files, both called ldap.conf, control LDAP client operations. The /etc/ldap.conf file is used by LDAP’s Name Service Switch (NSS)interfaces, while /etc/openldap/ldap.conf specifies defaults for various LDAP client programs. For now, concentrate on slapd.conf.
The slapd.conf file is rather lengthy, but chances are your default configuration will work reasonably well once you’ve entered a few site-specific items. The first of these is to load an LDAP schema (a set of rules) for handling Linux account information. At the beginning of your default file, you’ll probably see a series of include directives. Be sure that your file has the following directives in the specified order:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
The nis.schema file is the one that’s critical, but it relies on the preceding two. If your configuration loads other schema files, chances are they’ll do no harm, but they probably aren’t required for LDAP to function solely as a network authentication server.
Moving down a few lines, you may see a section that sets encryption options. If the following lines aren’t present, add them after the pidfile and args file options:
TLSCipherSuite
HIGHTLSCertificateFile /etc/openldap/ssl/slapd-cert.pem
TLSCertificateKeyFile /etc/openldap/ssl/slapd-key.pem
By default, LDAP doesn’t support encryption; these lines, in conjunction with procorgres described momentarily, enable encryption. This is an important feature for a network authentication server; you don’t want a user’s password to be sniffed as it’s exchanged! You can also set the security level and specify a default encoding for password storage:
security ssf=128 password-hash {SSHA}
Both of the values shown here are reasonable in most cases. Setting a lower ssf value (say, 112 or 56) disables the most robust encryption algorithms. The password-hash option accepts other values, but {SSHA} works well in most cases.The database option sets the type of backend database that LDAP uses:
database bdbdirectory /var/lib/ldap
The bdb value specifes Berkeley DB, but you can use other databases if you prefer; consult the OpenLDAP documentation for details. The directory option specifies the filesystem directory where the LDAP database files are stored. Be sure this directory exists and has mode 0700 (-rwx------) prior to running slapd. Several other database options may exist around or between these two lines. Chances are you won’t need to change them.
Several options set site-specific information on your network and its administration:
suffix "dc=pvalentino,dc=org"
rootdn "cn=oscar,dc=pvalentino,dc=org"
rootpw {SSHA}1gdwUg+YmJz7IlhpynZO/q6aiTB06Wqh
The suffix line sets the distinguished name (DN) for the LDAP directory. This is conventionally your DNS domain name split into parts (pvalentino.org in this example), but you can use other values if you prefer; the key is to be consistent in all your DN uses. The rootdn line specifies a DN that corresponds to a user who will administer the system. This should be the DN specified in the preceding suffix line with an additional CN code, which is conventionally Manager or admin. Finally, the rootpw line sets a password that’s used for administration (by the DN specified in the rootdn line). This password is stored in a hashed form. You can use the slappasswd command to generate the root password; type slappasswd and enter the
password twice. The program responds by displaying the hashed password, including an encoding value ({SSHA} in this example. Cut and paste this value, taking care to capture both ends of the string.
##################################################################
database bdb
suffix "dc=pvalentino,dc=org"
rootdn "cn=oscar,dc=pvalentino,dc=org"
rootpw {SSHA}#EH(IOHEGOIOIEkjnda+elyr4mWeadfiahfadfe
master
##################################################################
The final set of options in slapd.conf provide access control lists (ACLs) that relate to how users may access the directory:
access to attrs=userPassword by self write
by dn="uid=root,ou=People,dc=pvalentino,dc=org" write
by * auth
access to *
by * read
The first block of lines specifies rules for access to the userPassword attribute, which holds user passwords, as you might have
guessed. Specifically, users may write their own passwords (by self write), root may overwrite any password, and all users may
authenticate against passwords (by*auth). The second block of lines gives all users read access to the rest of the information in the directory (much as all users may read /etc/passwd). When specifying LDAP ACLs, order is important; earlier entries take precedence over later ones. Thus, the earlier ACL for userPassword, which doesn’t specify any read access, takes precedence over the later global read access ACL. This configuration prevents each user from reading his or her — or anyone’s — password. Once you’ve tweaked your default slapd.conf file, save it. You’re not quite ready to start the OpenLDAP server, though. Because you’ve configured LDAP to use encryption (via the three TLS* lines), you must first create keys and certificates. Creating Keys and Certificates TLS encryption, as used by OpenLDAP, is provided by the OpenSSL package, so you should install this software before proceeding. OpenSSL is designed to enable not just encryption, but also authentication of the server to its clients. You may optionally use a Certificate Authority (CA) to create an SSL key and certificate for your use; however, this option is most commonly employed by Web merchants and others who need to verify their identities to the public at large. For internal use, it’s faster and cheaper to generate your own keys and certificates. To do so, you’ll use the openssl command:
$ openssl req –x509 –days 365 –newkey rsa: –nodes –keyout slapd-key.pem –out slapd-cert.crt
For the most part, you needn’t be very concerned with the details of what these options mean, but you should type this command as root, exactly as specified, and in a directory to which you can write data. And although the certificate thus created officially expires in one year (-days 365), it will still be useful after that point for purposes of LDAP authentication. Once you type this command, the openssl program asks you for various pieces of identifying information, such as your location and your organization’s name. Answer in the way that seems reasonable, except for the Common Name(eg, YOUR name) prompt: Answer this question with the hostname or IP address of the LDAP server. The reason is that some clients (but not the Linux clients) are fussy about this field. If it doesn’t match the true hostname or IP address of the LDAP server, such clients might refuse the connection. When openssl is done, it writes two files: slapd-key.pem and slapd-cert.crt. These files hold a private key and a public
certificate, respectively. The slapd-key.pem file’s permissions are sensitive; you should be sure they’re set to 0600 (-rw-------) to ensure that the file isn’t stolen, enabling another computer to masquerade as your LDAP server. Once you’ve verified and, if necessary, changed the permissions on these files, you should move them to the directories (and names) specified by the TLSCertificateKeyFile and TLSCertificateFile parameters in slapd.conf.
Running the LDAP Server
Once you’ve modified your slapd.conf file and created your certificates and keys, you can launch the LDAP server itself. In most cases, you can do this via a SysV startup script:/etc/init.d/ldap start
The location and name of the startup script varies from one distribution to another, so you may need to hunt to find yours. To ensure that the server runs automatically whenever you start your system, you may need to check or modify your SysV startup script configuration. Typing chkconfig ldap on does the trick on many distributions. Unfortunately, some distributions’ LDAP server SysV startup scripts don’t include appropriate options to bind LDAP to all the ports needed for TLS-mediated operation. Typically, LDAP binds to port 389, which is usually adequate for use with Linux clients. Some other clients, though, may require LDAP to be bound to port 636 for secure LDAP (LDAPS) operation. To bind LDAP to other ports, you must pass the ports via the –h option when starting the server, as in –h ldap:// ldaps://. To accomplish this goal, you may need to edit a distribution-specific configuration file or the LDAP SysV startup script itself. Peruse your startup script to locate the call to the server. You may be able to find a variable, such as SLAPD_URLS, which you can modify to include the necessary information...
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, Paul Valentino, whose Linux
username is pvalentino. Listing One: A sample LDAP Data Interchange Format entry holding Linux account information
dn: uid=pvalentino,ou=People,dc=pvalentino,dc=org
uid: pvalentino
cn: Paul Valentino
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/pvalentino
gecos: Paul Valentino
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 previously; 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 = "pvalentino.org";
$DEFAULT_BASE = "dc=pvalentino,dc=org";
This example sets defaults that are appropriate for a fictitious pvalentino.org 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=pvalentino,dc=org
objectClass: domain
dc: pvalentino
dn: ou=People,dc=pvalentino,dc=org
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=pvalentino,dc=org
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. vLikewise, you might want to set different rootvpasswords 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 ahead 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 ahead, 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 previously 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 previously. 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=pvalentino,dc=org
URI ldaps://ldap.pvalentino.org
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 previously. 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=pvalentino,dc=org –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=pvalentino,dc=org –S -W uid=pvalentino,ou=People,dc=pvalentino,dc=org
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 ahead. To delete an existing account entry, you can use the ldapdelete command:
$ sudo ldapdelete –D cn=manager,dc=pvalentino,dc=org –W uid=pvalentino,ou=People,dc=pvalentino,dc=org
Again, you're be prompted for your password. If all goes well, LDAP will delete the specified account (for pvalentino 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 procorgres 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.
The Roles of NSS and PAM
Most people give little thought to the details of how Linux accounts are structured. In fact, there are several characteristics of accounts, such as usernames, passwords, home directories, default shells, and so on. These features are managed by two Linux tools: PAM is a security tool; it tells login tools, such as the text-mode login process or the GUI GNOME Display Manager (GDM) or KDE Display Manager (KDM), that the password a user types is (or is not) correct for the specified username. PAM also handles some additional tasks, such as changing passwords when a user runs the passwd utility. NSS handles less sensitive account data, such as the path to a user's home directory, his or her default shell, and so on. If you configure PAM but not NSS to use LDAP, only users who have local account data stored in /etc/passwd and /etc/shadow will be able to log in. These files could lack passwords, but they'd have to host the normal NSS data. If you configure NSS but not PAM to use LDAP, then Linux will believe it has accounts for the users defined on the LDAP server, but those users won't be able to log in. Thus, to use an LDAP server for authentication, you must normally reconfigure both PAM and NSS to use LDAP. Either alone could be useful in some limited circumstances, but in most cases you must configure both to use LDAP.
Setting Basic LDAP Client Options
Before proceeding with NSS and PAM configuration, you must set a few client-wide LDAP options. To do so, you should first ensure that the PAM and NSS LDAP libraries are installed on your client computer. These tools are usually stored in packages called pam_ldap and nss_ldap, although some distributions use other names, such as libpam-ldap and libnss-ldap. Some distributions combine both packages into one — nss_ldap in the case of Fedora Core 6, for instance. In most cases, the LDAP client tools for NSS and PAM both rely on the /etc/ldap.conf file. Debian and its derivative distributions use two files, /etc/nss_ldap.conf and /etc/pam_ldap.conf. If your distribution uses two files, you must make similar changes to both. Be sure not to confuse this file with the /etc/openldap/ldap.conf, which is the configuration file for the LDAP tools described previously. To proceed, load your /etc/ldap.conf file into an editor and change the host and base lines:
host 192.168.1.3
base dc=pvalentino,dc=org
The host line specifies the LDAP server's IP address or hostname, so modify it to suit your network's neeeds. The base line points to the base directory used by your LDAP account directory. As described two months ago, this is often related to your domain name, but it need not be. You may want to peruse additional options in the /etc/ldap.conf file. Many default files include commented-out options related to port numbers, encryption, and other features. In a high-security environment, you may want to enable some of these options. Doing so can improve security, but these features can be difficult to debug.
Setting NSS Options
Telling NSS to use LDAP is fairly straightforward. The main NSS configuration file is /etc/nsswitch.conf, and you must edit three
lines to have NSS use LDAP. These lines begin with the words passwd, shadow, and group, and you should add the string ldap to each of these lines:
passwd: files ldap
shadow: files ldap
group: files ldap
In practice, NSS uses each of the named subsystems in the order in which they're listed for the duties specified by the leading keyword. You may have noticed that each of these lines begins with the name of a file that's used in Linux account management: /etc/passwd, /etc/shadow, and /etc/group. This is because NSS ordinarily accesses these files (hence the files keyword). By adding ldap to the end of the line, you direct NSS to use the local files first and then to call on LDAP. Thus, when reconfigured in this way, your system will include all the locally-defined accounts and groups, plus whatever accounts or groups are defined in the LDAP directory. It's possible that your configuration will include other keywords, in addition to or instead of the files keyword that's common to the lines in this example. For instance, many systems use compat rather than files. If so, the safest approach is usually to add ldap to the end of each line.
Setting PAM Options
PAM is a more complex subsystem than NSS to configure as an LDAP authentication client. As noted earlier, PAM stands for Pluggable Authentication Modules. The modules referred to in the name are pieces of code, similar to libraries or kernel modules, that extend PAM to handle new authentication methods. The PAM LDAP package you installed earlier provides an LDAP module for PAM; this module" talks" to the LDAP server, providing an interface between the LDAP server and the local computer's authentication system. The main PAM configuration file is /etc/pam.conf; however, all common Linux distributions place the bulk of the PAM configuration in files within the /etc/pam.d directory. Each file in this directory controls one authentication tool. For instance, /etc/pam.d/login controls the login process, /etc/pam.d/gdm controls the GDM GUI login tool, and /etc/pam.d/su controls the su command's authentication. In theory, to configure PAM to use LDAP, you must modify the files for each subsystem that should use LDAP. Precisely which files and subsystems this should be can vary greatly from one computer to another; for instance, you might need to modify files for a Post Office Protocol (POP) email server on one computer, but for GDM on another computer. Fortunately, many Linux distributions provide a shortcut:
/etc/pam.d/system-auth
Not all distributions use this file, but if yours does, you can modify just this one file rather than modifying all the relevant authentication programs' files. Whether you need to modify the system-auth file or multiple files, though, the procedure is similar. PAM authentication files consist of stacks, which are sets of external modules that provide authentication services. These stacks are broken into four management groups: auth, account, password, and session. Each management group's stack defines the rules that PAM uses to perform a specific action, such as authenticate a user (auth) or manage a login session (session). A typical authentication stack resembles Listing One, which is based on a Gentoo PAM stack. (Some lines have been broken for publication.)
Listing One: A typical PAM authentication stack
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_unix.so likeauth
nullok
auth required pam_deny.so
account required pam_unix.so
password required pam_cracklib.so retry=3
password sufficient pam_unix.so nullok md5
shadow use_authtok
password required pam_deny.so
session required pam_limits.so
session required pam_unix.so
To add LDAP authentication to the mix, you must add a reference to the LDAP authentication module (pam_ldap.so) to each of the management groups. To do so, though, you must first understand a bit about how PAM processes its stacks. When it's called upon to perform an action, such as authenticate a user or change a password, PAM calls each of the modules (in the third column of Listing One) for the associated management group in turn. Ultimately, the action will succeed or fail, and which happens depends on the successful completion of each module in conjunction with the control flag in the second column of Listing One. Of most importance are the requisite, required, and sufficient flags: A requisite flag means that the module must succeed if the stack is to succeed. If the module fails, stack execution terminates immediately. A required flag is much like a requisite flag, but if the module fails, execution continues until the end. A sufficient flag causes stack execution to immediately terminate with a successful outcome if the associated module succeeds, provided no previous required module failed. If a sufficient module fails, the stack as a whole could still succeed, if other modules cause it to succeed — that is, a module failure causes the stack to work as if the sufficient module has not been present in the stack. The default stacks provided with most Linux distributions rely heavily on requisite or required flags, with an occasional sufficient flag thrown in; Listing One is a typical example. To add LDAP authentication while keeping local authentication working, you must add references to the pam_ldap.so module as sufficient. You must also usually change some of the requisite or required modules to be sufficient. The result might resemble Listing Two.
Listing Two: A PAM authentication stack that uses LDAP
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_unix.so likeauth
nullok
auth sufficient pam_ldap.so
try_first_pass
auth required pam_deny.so
account sufficient pam_unix.so
account sufficient pam_ldap.so
password required pam_cracklib.so retry=3
password sufficient pam_unix.so nullok md5
shadow use_authtok
password sufficient pam_ldap.so use_authtok
debug
password required pam_deny.so
session required pam_limits.so
session sufficient pam_unix.so
session sufficient pam_ldap.so use_first_pass
session required pam_mkhomedir.so
skel=/etc/skel umask=0027
In this example, Listing One uses the pam_unix.so module to perform the key tasks for each of the four management groups; however, some distributions use other modules instead of pam_unix.so, so you may need to do some research on your distribution's PAM defaults. To add LDAP to the mix, you add its line after the pam_unix.so line and, if pam_unix.so is set to be requisite or required, change it to sufficient. Alternatively, you could add pam_ldap.so to the stack before the requisite or required module; pam_ldap.so, if successful, will then bypass the requisite or required module. You may also need to add a reference to pam_deny.so to the auth and password stacks; if you don't, the stack may incorrectly indicate success even when an incorrect password is entered. (You may need to test both ways, as described shortly.)The pam_ldap.so lines in Listing Two include parameters that vary from one management group to another. These parameters tweak the module's behavior. For instance, the try_first_pass and use_first_pass options tell the module to try the password collected on behalf of the first authentication tool. Without these options, users may be prompted for their passwords twice when they have only LDAP accounts. Listing Two's final line is a new one that's unrelated to LDAP, but that's very useful for network logins: The pam_mkhomedir.so module automatically creates a new home directory for a user if one doesn't already exist. You can call this module as part of the session management group, using options as shown in Listing Two to specify template files and permissions. Of course, this tool is most useful on workstations or computers that should have home directories. You might not need it for all systems. Remember to make changes either to the /etc/pam.d/system-auth file or to the configuration files for all of the authentication tools you want to use LDAP. Note that if you modify individual configuration files, not all files use all of the management groups shown in Listing One and Listing Two, so you might not need to make all of the changes shown in Listing Two.
Testing Proper Functioning
Once you've made your changes, you should test them. Try using each authentication tool to log in using several different types of
accounts and procedures:
Use a real local account with a correct password
Use a real local account with an incorrect password
Use a real LDAP account with a correct password
Use a real LDAP account with an incorrect password
Use an account that exists in neither the local account database nor LDAP You should see the correct login behavior in each of these cases. If you see authentication failures when you type the correct password or, worse in some ways, authentication successes when you use an incorrect password or a non-existent account, you should review your configuration. Unfortunately, there's little standardization between Linux distributions concerning their default PAM configurations, so the changes that work for one distribution might not work for another. You may need to experiment or look for distribution-specific documentation to help fill in the gaps. Be sure to test every authentication tool, or at least every one you've altered to use LDAP. The passwd utility deserves special mention: If you change the /etc/pam.d/passwd configuration file, or if it uses the system-auth stack, users who use the passwd command to change their passwords should change their passwords in the local database, in the LDAP directory, or in both, depending on precisely how you've configured PAM. Check both the local database and LDAP to be sure that the changes have been made as you expect
Posts
