LDAP System Administration [Electronic resources] نسخه متنی

7.2 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.

7.2.1 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

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).

7.2.2 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.

7.2.3 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.

7.2.4 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).

Refer to your directory server's documentation to determine whether it supports NTLM authentication. OpenLDAP does not currently support this feature.

Outlook Express is a little more friendly than Mozilla when it comes
to using LDAPS to connect to a directory server. On Windows 98,
simply indicating that the directory server should be accessed using
SSL on port 636 is enough. It is not necessary to tell Internet
Explorer or Outlook to trust the self-signed certificate used by an
OpenLDAP server. I'll let you decide whether this is
a good thing; Mozilla was less trusting, requiring you to tell it to
trust the LDAP server's certificate.