Linux’s multi-user nature is very helpful in many situations. Universities often have public terminals at which students, faculty, and staff may work; Web servers, mail servers, file servers, and other servers usually have multiple users; and even personal computers at home may be shared by multiple users. Linux allows one or more users to share the same hardware simultaneously. In many of these environments, though, a problem arises: How do you manage the accounts for multiple users on multiple computers?
Managing many users on a single computer is easy — you can use Linux’s useradd, usermod, and passwd utilities, among other tools. But as the number of computers grows, administering user accounts becomes increasingly tedious and error-prone. Imagine trying to keep the accounts of hundreds or thousands of users synchronized across hundreds of computers!
Fortunately, Unix systems (and hence Linux) have long supported network authentication tools, such as the Network Information Service (NIS) and Kerberos. These tools enable all the computers on a network to authenticate against a user database maintained by a single computer (possibly with backups). Such an approach greatly simplifies account maintenance on networks with more than a handful of computers.
In recent years, another tool has become increasingly popular for this task: the Lightweight Directory Access Protocol (LDAP). LDAP is much more than an authentication tool, but you can use it as nothing but an authentication protocol, if you like. Getting your feet wet with LDAP is also useful in cross-platform networking, since LDAP is one of several protocols that together make up Microsoft’s Active Directory (AD).
This month’s column introduces LDAP as a network authentication protocol, and also describes basic installation and configuration. Next month’s column describes how to migrate an existing user database (in /etc/passwd and /etc/shadow) to LDAP and maintain the system. Then, June’s column will describe how to configure Linux systems as LDAP clients.
LDAP Principles
LDAP is a directory protocol. Confusingly, the word directory in this context doesn’t refer to a filesystem directory; rather, a directory is more like a database. There are some technical differences between a directory and a database, but for this brief introduction to LDAP, the differences can be ignored.
Like many protocols, LDAP has its own terminology, with some unique terms. Most notably, LDAP uses a number of acronyms to refer to types of structures within its directories. These include domain component (DC); distinguished name (DN), common name (CN), and organizational unit (OU). You’ll frequently see these acronyms, and others that are defined for specific purposes, in LDAP configuration files and in the files describing user accounts, as in:
dn: cn=Fred Jones,dc=luna,dc=edu
This entry identifies a DN by three components: a CN and two DCs. These elements are organized hierarchically, as shown in Figure One. If this seems confusing or meaningless, don’t fret; I’ll help guide you through the practical steps required to configure LDAP’s alphabet soup for network authentication.
LDAP is a network protocol. To actually store data, LDAP must use some sort of database as a backend. One common backend is the Berkeley DB package (http://www.sleepycat.com), but others are available. To the LDAP client, the backend package is invisible except if it negatively affects the LDAP server’s performance.
LDAP supports secure modes of operation in which critical data are encrypted before being passed over the network. Although enabling encryption is tedious, it greatly improves network security compared to using unencrypted modes of operation.
Once an LDAP server is in place, LDAP-aware clients can use the protocol to retrieve user account information. This information can include both basic account existence (a list of users) and authentication. (You’ll have all the details by the end of this series.)
Installing LDAP
Several LDAP packages are available, but the most common Linux package is OpenLDAP, available from http://www.openldap.org. Most distributions make OpenLDAP available in a package called openldap or openldap2, so the easiest way to install the package is to use yum, apt-get, emerge, or other distribution-specific package tools to install this package. (Of course, you can also build from source.) You must install this package on both your LDAP server and on all of its clients, but only the server host run the server software. As the magazine goes to press, the latest version available is 2.3.32.
Whether you install OpenLDAP from a binary package or build OpenLDAP yourself, you should be aware that OpenLDAP has a rather long list of dependencies. These vary with your compile-time options, but the most notable include SSL and TLS (as implemented in OpenSSL, http://www.openssl.org) and your chosen database backend. If you use a high-end package manager such as yum, apt-get, or emerge, the package manager should install the necessary dependencies automatically. If you build the package yourself or use a lower-end package manager such as rpm or dpkg, you’ll need to track down and install the dependencies manually.
Basic LDAP Configuration
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 argsfile options:
TLSCipherSuite HIGH
TLSCertificateFile /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 procedures 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 bdb
directory /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=luna,dc=edu"
rootdn "cn=Manager,dc=luna,dc=edu"
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 (luna.edu 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.
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=luna,dc=edu" 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.
Next Month
Unfortunately, this is the end of this month’s column. You’re probably best off shutting down your LDAP server software until next month, since it won’t do you much good until it can access user account data. Creating a directory with this information is next month’s topic. June’s column describes how to configure a Linux system as a client, enabling it to authenticate users against your LDAP server and its directory.
From: [Linux Magazine]
No hay comentarios:
Publicar un comentario