LDAP System Administration
Page 17
This configuration assumes that a user named ypldapproxy exists in the directory, and that the following access control rule is defined in slapd.conf. Because of OpenLDAP's "first match wins" algorithm for processing access control rules, this definition should be listed before any others.
## Give the ypldapproxy user read access to all information.
access to dn=".*,dc=plainjoe,dc=org"
by dn="uid=ypldapproxy,ou=people,dc=plainjoe,dc=org" read
However, this configuration allows users to view passwords for all accounts using the ypcat(1) or ypmatch(1) commands. To prevent users from accessing passwords, the hide_password parameter instructs ypldapd to implement shadow passwords:
## Hide the password field from nonprivileged users.
hide_passwords on
Once ypldapd is running, you should be able to test the server using the various yp* commands. For example:
# ypwhich
192.168.1.77
# ypmatch gcarter passwd.byname
gcarter:##gcarter:780:100:G Carter:/home/gcarter:/bin/bash
Chapter 7. Email and LDAP
One of the most important applications of a directory is storing email addresses and other contact information. Although many ad hoc solutions to this problem have been implemented over the years, LDAP provides a natural online publishing service for this type of data. This chapter explores the ins and outs of integrating email clients (MUAs) and mail servers (MTAs) with an LDAP directory. It covers the configuration details of some of the more popular email clients, including Mozilla Mail, Pine, Microsoft Outlook, and Eudora. We'll also discuss the schema required to support these clients and the types of LDAP searches to expect when the application attempts to locate a user in the directory.
On the server side, we'll discuss three popular email servers—Sendmail, Postfix, and Exim—all of which can use a directory. We will cover the level of LDAP support within each MTA, the schema needed to support this integration, and the configuration process for integrating an LDAP directory into a production email environment. This discussion assumes that you are familiar with basic MTA administration and the interaction between SMTP servers.
Representing Users
The server you will build combines the white pages server you created in Chapter 4 and the server for administrative databases you created in Chapter 6 as a replacement for NIS. You already have a head start on integrating user account information because both servers used the ou=people container for storing user account information. With only a few modifications to your directory, the posixAccount and inetOrgPerson object classes can be used to store a single user entry for both authentication and contact information.
Here's an entry for "Kristi Carter," which is similar to those presented in Chapter 4:
dn: cn=Kristi W. Carter,ou=people,dc=plainjoe,dc=org
objectClass: inetOrgPerson
cn: Kristi W. Carter
sn: Carter
mail: kcarter@plainjoe.org
labeledURI: http://www.plainjoe.org/~kristi
roomNumber: 102 Ramsey Hall
telephoneNumber: 222-555-2356
In Chapter 6, this same user might have been presented as:
dn: uid=kristi,ou=people,dc=plainjoe,dc=org
uid: kristi
cn: Kristi Carter
objectClass: account
objectClass: posixAccount
userPassword: {crypt}LnMJ/n2rQsR.c
loginShell: /bin/bash
uidNumber: 781
gidNumber: 100
homeDirectory: /home/kristi
gecos: Kristi Carter
Looking at both examples side by side, some differences can be noted. The first is that the RDN used for each entry is different. It doesn't really matter whether you choose cn=Kristi W. Carter or uid=kristi. Since Unix accounts must already possess a unique login name, the uid attribute is a good choice to prevent name conflicts in ou=people.
The second issue is more serious and shows why the initial directory design should not be rushed. Both the account and inetOrgPerson object classes are structural object classes. Remember that an entry cannot have more than one structural object class and that once an entry is created, its structural class cannot be changed. Some LDAP servers may allow you to reassign an entry's object classes at will, but do not rely on this behavior.
To solve this dilemma, initially create each entry with the inetOrgPerson class and then extend it using the posixAccount auxiliary class. The means that the account entry will have to be filtered from the output of PADL's migration scripts—a simple task using grep:
$ ./migrate_passwd.pl /etc/passwd |
grep -iv "objectclass: account" > passwd.ldif
The combined user entry now appears as:
dn: uid=kristi,ou=people,dc=plainjoe,dc=org
objectClass: inetOrgPerson
objectClass: posixAccount
cn: Kristi Carter
cn: Kristi W. Carter
sn: Carter
mail: kcarter@plainjoe.org
labeledURI: http://www.plainjoe.org/~kristi
roomNumber: 102 Ramsey Hall
telephoneNumber: 222-555-2356
uid: kristi
userPassword: {crypt}LnMJ/n2rQsR.c
loginShell: /bin/bash
uidNumber: 781
gidNumber: 100
homeDirectory: /home/kristi
gecos: Kristi Carter
One final note before we begin looking at specifics of email integration: the mail attribute is optional in the inetOrgPerson schema definition. However, it's clearly mandatory when you're trying to support mail clients and servers.
Email Clients and LDAP
When planning a strategy for supporting an application with a directory, you always start by examining the application and determining what schema has the ability to support it. Using a standard schema is vastly preferable to building your own. Of course, with email you don't have the ability to specify what client users will use: at your site, many different clients are probably in use, and you won't make friends by asking users to change. In this section, we'll look at four clients, all of which are in common use: Mozilla Mail, Pine from the University of Washington, Qualcomm's Eudora, and Microsoft's Outlook Express. Fortunately, the inetOrgPerson schema supports all of the information items we are concerned with using in this section.
The following parameters are common to all clients:
The LDAP server is ldap.plainjoe.org.
The base search suffix is ou=people,dc=plainjoe,dc=org.
Beyond the basic LDAP search parameters and supporting schema, it is imperative to know what version of LDAP the clients will use. Table 7-1 reveals that 3 out of the 4 mail clients listed use LDAPv2 to bind to the directory server. This means that you must explicitly add support for these connections as OpenLDAP 2.1 rejects LDAPv2 binds in default configurations. Add the following line to the global section of slapd.conf:
## Allow LDAPv2 binds from clients needed by several mail client packages.
allow bind_v2
then restart the OpenLDAP server to make it recognize the change.
Table 7-1. LDAP versions used by various mail clients
Mail client
LDAPv2 bind
LDAPv3 bind
Mozilla Mail
✓
Pine 4
✓
Eudora
✓
Outlook Express
✓
Mozilla Mail
In 1998, Netscape Communications announced that it would give away the source code to the next generation of Netscape Communicator browser suites. In the Fall of 2002, the 1.0 release of Mozilla finally saw the light of day. Today, this code base is still alive, well, and growing at http://www.mozilla.org/. Versions of the browser suite are available for various flavors of Unix, Windows, and Mac OS.
When configuring Mozilla's address book client to access a directory, you must keep two questions in mind:
> Should users be required to authenticate themselves, or should they be able to access directory information anonymously?
Should the information sent to and retrieved from the LDAP server be sent in clear-text form (i.e., LDAP), or should it be transmitted over SSL (i.e., LDAPS)?
The simplest method of adding a new directory server profile in Mozilla is through the Address Book application shown in Figure 7-1. Select File → New → LDAP Directory to launch the Directory Server Properties dialog shown in Figure 7-2.
Figure 7-1. Adding a new LDAP directory to the Mozilla Address Book
Figure 7-2. Setting directory search parameters
The Name field lets you provide a descriptive title name for the directory (Plainjoe Dot Org); this name is used in the address book display window, but has no other effect on directory lookups. Put the hostname or IP address of the directory server in the Hostname field (ldap.plainjoe.org). Set the Base DN to the base search suffix used when querying the server (ou=people,dc=plainjoe,dc=org). The Port number, which defaults to port tcp/389 for non-SSL directories, should be set to the port on which the LDAP server is listening. By default, Mozilla uses an anonymous bind when searching the server. If a simple bind is preferred, you can define the Bind DN to use for authentication. Mozilla will prompt you for the corresponding password before it actually performs a search.
Once the directory has been added to the list of address books, you can query the directory by entering a substring to search for, or by using some of the more advanced search dialogs. Figure 7-3 shows the basic substring search test entry box. Any text you enter in this box is used to query the cn, sn, givenName, and mail attributes using a subtree search scope. For example, if you enter the text "carter", the client uses this search filter:
(|(mail=*carter*)(cn=*carter*)(givenName=*carter*)(sn=*carter*))
Figure 7-3. Basic search screen in the Mozilla Address Book
* * *
Tip
A simple way to determine the search filters used by any LDAP client is to enable connection logging on your directory server. OpenLDAP uses log level 256 for this purpose. Another possibility is to use a network traffic-monitoring tool such as Ethereal that can decode LDAP requests and replies. More information about Ethereal can be found at http://www.ethereal.com/.
* * *
The advanced search dialog box (Figure 7-4) allows you to create more elaborate searches. The string entered as the search characteristic is the text for which you're searching; for example, the text "jerry" entered as part of the email address would result in the search filter of (mail=*jerry*).
Figure 7-4. Advanced searching in the Mozilla Address Book
If the user selects the "Use secure connection (SSL)" checkbox on the directory properties window displayed in Figure 7-2, Netscape automatically changes the configured port number to tcp/636 (LDAPS). All traffic between the address book client and the directory server will be encrypted. Do not confuse this secure connection with the StartTLS LDAPv3 extension. Mozilla supports LDAPS only for secure communication with the directory server.
For this configuration to work, the LDAP server must be configured to support LDAPS and be listening on the port specified by the Server Port entry field. In addition, the Mozilla client must trust the certificate used by the LDAP server.
The procedure for configuring a directory server to support LDAPS varies from vendor to vendor; refer to your server documentation for details. In the case of OpenLDAP 2, you must generate a certificate and key file for slapd (refer to Chapter 3 for details on this) and then instruct the daemon to associate LDAPS with the correct port. The -h command-line option tells slapd which protocols to support. The command below starts slapd with support for LDAP and LDAPS on the default tcp ports 389 (for LDAP) and 636 (for LDAPS):
root# /usr/local/libexec/slapd -h "ldap:/// ldaps:///"
Unless the LDAP server's certificate can be verified by a certificate authority (CA), Mozilla will ask you whether it should trust the server before continuing the connection. If you decide that this will be too much trouble (or confusing) for your users, avoid self-signed certificates (or set up your own CA).
Pine 4
Pine is a popular, console-based email client developed by the University of Washington. The source distribution of the mail client is available at http://www.washington.edu/pine/; precompiled versions are available for most modern Unix and Unix-like systems. Support for retrieving addresses from an LDAP directory was introduced in Pine 4.00. A Windows version of Pine, known as PC-Pine, offers similar features to the Unix version, including LDAP support. PC-Pine is available from the University of Washington at http://www.washington.edu/pine/pc-pine/.
If you are using a precompiled version of Pine, you must ensure that LDAP support was enabled when the package was built. LDAP-enabled versions of Pine should allow you to configure a new directory from the Setup menu, as shown in Figure 7-5.
Figure 7-5. Setup menu for Pine 4
Pine's directory configuration screen supports the common LDAP search parameters, including:
ldap-server
The IP address or hostname of the directory server (ldap.plainjoe.org)
search-base
The base search suffix (ou=people,dc=plainjoe,dc=org)
port
The tcp port on which the server is listening (389)
nickname
A descriptive display name (Plainjoe People)
Pine allows users to construct searches using up to four search attributes. By default, it uses the name (cn), surname (sn), given name (givenName), and email (mail) attributes. The default search filters only append the wildcard onto the end of the user's search string. For example, by default, Pine converts an email search for the string "kristi" into the search filter:
(|(cn=kristi*)(mail=kristi*)(sn=kristi*)(givenName=kristi*))
However, Pine offers a fair amount of flexibility for more adventurous users; you can change the kind of substring match (e.g., exact match, match at the beginning, match at the end, match anywhere), change the attributes Pine uses in the search, or specify a custom search filter. All of these settings can be accessed from Pine's directory configuration screen.
One shortcoming of Pine's LDAP implementation is the lack of support for LDAPS (and the fact that it uses LDAPv2). Although Pine supports SSL, it supports SSL only for POP or IMAP access to mailboxes. Pine cannot use SSL to access an LDAP directory.
Eudora
Qualcomm's Eudora has become a popular mail client on both Windows and Mac OS platforms. Configuring access to an LDAP directory in Eudora is similar to configuring LDAP for Mozilla. To start, go to the Modify Database window shown in Figure 7-6 by selecting the LDAP protocol from the directory window (Tools → Directory Services) and clicking the New Database button.
Figure 7-6. Modify Database dialog views used by Eudora 5.1 for Windows
The Network tab allows you to specify connection information for the directory server. If you configure Eudora to use a login name and password to search the directory, the username must be in the form of a DN. The Search Options view shows that Eudora, by default, performs a substring match on the cn attribute; you can customize the search using standard search filter syntax. The Attributes dialog shown in Figure 7-6 provides a way to select which attributes are shown in response to a directory query. Eudora displays all the attributes for each entry that the search returns. You can define more descriptive names for attribute types using the Attributes window; for example, you can display the cn attribute type as "Real Name."
Eudora 5.1 does not support LDAPS when searching directories.
Microsoft Outlook Express
Microsoft Outlook in its various incarnations has become one of the most important mail clients on Windows networks. This section examines the version of Outlook Express that is included with Microsoft's Internet Explorer.
To configure Outlook Express to use a directory, start with the Directory Services configuration
dialog, shown in Figure 7-7. To get to this dialog, select Tools → Accounts. The General tab contains settings for the directory server host information, such as the server's hostname and display name. The Advanced tab provides a means to define the port on which the server is listening and the base search suffix.
Figure 7-7. The Directory Services configuration window from Outlook Express 5.5
To search for someone in a directory, Outlook users go to the Find People dialog shown in Figure 7-8. Outlook Express uses a combination of the cn, sn, mail, and givenName attributes to generate the search filter. A search for the user "carter" is translated into a search filter very similar to the one used by both Mozilla Mail and Pine:
(|(mail=carter*)(cn=carter*)(sn=carter*)(givenname=carter*))
Figure 7-8. Using the Find People dialog to search an LDAP directory
Searches can be customized using the Advanced tab of the Find People dialog in Figure 7-8.
Like both Mozilla and Eudora, Outlook Express can perform authenticated binds when searching a directory. If you check "This server requires me to logon," Outlook asks for a user ID and password, which it uses when binding to the server. Unlike Eudora, which expected a DN only for the username, Outlook Express supports two different styles of usernames. When using a simple bind, Outlook expects the login name to be the DN used in the bind request. However, if the "Logon using Secure Password Authentication" box is checked, Outlook negotiates with the directory server to use the NTLMv1 challenge/response authentication model (or possibly the GSSAPI SASL mechanism).
* * *
Tip
Refer to your directory server's documentation to determine whether it supports NTLM authentication. OpenLDAP does not currently support this feature.