Integrating LDAP and The Exchange Directory

Configuring LDAP Microsoft has simplified LDAP's configuration process into four easy steps, and the protocol is ready to use. In fact, it is enabled at installation, and the default configuration works well in most small messaging environments.

Our first step was selecting the authentication method so that users can securely access the directory. Next, we had to decide whether to permit anonymous access from users outside the organization, then configure the search types that determine how the directory will treat substring searches. The final step was to select the idle time-out interval for TCP/LDAP connections.

For the authentication method, we could select clear text, clear text with SSL (Secure Sockets Layer), or both. If you require secure access to your directory , you should enable SSL access only. To enable SSL, you must register your Exchange Server and obtain a certificate from a CA (certificate authority), which can be a local or enterprise CA or a third party, such as VeriSign.

Next, we decided whether to permit anonymous access. If you plan to expose your directory to the outside world, you must select this option within the Exchange Server. Otherwise, external users will not be given access--soundly defeating the entire global intention of having an LDAP directory. With Exchange, you cannot control overall access to the directory based on user name and password, but you can selectively control access to attributes by anonymous or authenticated users or replicated sites. So an anonymous user could see the directory, but only selected information.

Other LDAP implementations offer more robust authentication. For example, with Netscape's Directory Server 3.0, users can be authenticated based on user name and password, as well as IP address, DNS name and X.5 09 certificate. Users also can be denied overall access to the directory. The ideal security would be public key, but this is not available in current LDAP implementations.

After that, we configured the search types that determine how the directory will treat substring searches. (Substrings are downstream attributes, such as first name and phone number). The default treats any substring search as an initial search, providing better response to the user. Other default options involved allowing only initial searches (fast) or all substring searches (slow). On this screen, you can specify the maximum number of search results returned by the directory to the user. Our default was 100, but you can raise or lower this number depending on how many directory entries you have, or how much data you want to transmit back to the user. In Exchange 5.5, the directory can be configured to return search results in chunks, such as 100 entries at a time (a practical amount).

We then selected the idle time-out interval fo r TCP/LDAP connections. The default setting in Exchange 5.0 was 10 minutes. This is extremely high, and you should change this to one minute or less to improve directory access and query response times.

Specifying Attributes for Public View The next step involves going into the Exchange Site Addressing to select which attributes you want internal users and the public to see in their search results. Here is where you permit or deny access by attributing and publishing a subset of the Exchange Global Address List to the Internet as white pages, which are accessed by LDAP clients.

Which particular attributes should you expose to the public? Resolving this dilemma usually requires a committee. In the final analysis, most companies hold their contact information close to their vests, exposing the smallest set of attributes required for an external user to contact the person (usually last name, first name and e-mail address).

In the past, information like a person's title or ID number did not appea r in a messaging directory, discouraging hackers or headhunters. You probably would not want to expose some attributes, such as title, or cellular phone, pager or home numbers, but you may want to expose others, such as business phone number, fax number, mailing address, personal or company Web URL and the user's public encryption key. Exchange 5.0 supports 50 of these attributes.

Netscape takes a different approach and offers a dynamically extensible schema (part of the LDAP version 3 Specification) in Directory Server 3.0. Exchange does not permit you to dynamically extend your directory schema in 5.0, but it does provide 10 custom directory attributes. (Five additional items will be available in Release 5.5.) You'd most likely want to use attributes such as fax, telephone, cellular phone and pager for your sales staff, but provide little or no information about engineering or accounting staff.

What should you do about users with several e-mail addresses in the directory? One solution is to publish on ly the user's Internet mail address to anonymous users. For internal users, you can publish all of the addresses (cc:Mail, Microsoft Mail, X.400) if you are certain that this would not cause too much confusion. Senders would select the one address that would be handled correctly by their own messaging system.


Side Bar On
Moving Ahead With LDAP3

Other Workshops
Guarding the Flaank With RADIUS & TACACS+
By Dan Backman
The Ups and Downs of Analyzing Middleware
By Barry Nance
Achieving Production Quality Messaging
By Nancy Cox

Valley View, Live!

Research and Reports

Storage Virtualization Guide
May 2012

Network Computing: May 2012

TechWeb Careers