![]() ![]() Integrating LDAP and The Exchange Directory |
|
By Nancy Cox
The Internet is in need of a widely supported, easily accessible electronic directory. Enter the Lightweight Directory Access Protocol. It is an inexpensive, internationally standardized and trim solution that lets users gain access to information locked in proprietary databases across a corporation and the world.
The major selling point to LDAP is the universal agreement to use it. LDAP is supported on servers, in applications and in clients. Because it runs over TCP/IP and does not require an X.500 directory, LDAP makes open directories easier, and it uses less overhead to deploy. Most enterprise-level directories will no doubt have LDAP interfaces. Users can utilize the protocol as a front end for any database stored anywhere to gain authenticated, secure or anonymous access. Organizations are using LDAP in many intriguing and practical ways. For instance, one business has integrated its PBX system into Microsoft Corp.'s Outlook and is using LDAP as a means to access the Outlook database. Wh en a user clicks on a phone number in the directory, his or her telephone begins dialing the call. Another company stores users' bookmarks and preferences in the directory as an aid to remote and mobile users. And a major university is using LDAP to map user addresses to IMAP4 (Internet Mail Access Protocol version 4) servers. Of course, the most universal need driving LDAP-enabled directories is for corporate white pages and yellow pages. This view of a portion or subset of the messaging system's central directory is visible to any anonymous user accessing the directory from any LDAP-compliant client. We wanted to see how this protocol is being implemented, how LDAP-compliant clients access directories and what they can do once they have access. In Network Computing's tests, we used Microsoft Exchange Server 5.0 and evaluated the LDAP-compliant mail clients in Microsoft Internet Explorer 3.02, Internet Explorer 4.0 Preview 2 and Netscape Communications Corp. Communicator 4.03. The test bed in our Orla ndo, Fla., corporate lab used Windows NT 4.0 Service Pack 3 on a Compaq Computer Corp. ProLiant 2500 across a TCP/IP LAN. We used Outlook's IM (Internet Mail) service, IIS (Internet Information Server) and ASP (Active Server Pages) to assemble our testing environment. LDAP version 2 is natively implemented in Microsoft Exchange 5.0, and each object is a record stored as a set of structures within the Microsoft Access database. Basically, Microsoft created an LDAP gateway to its internal user directory. In our environment, LDAP performed well with responses to queries visible instantaneously. We found that LDAP implementations are still a bit immature, and LDAP version 3 probably will not fix most of the inconsistencies we struggled with. Users should familiarize themselves with LDAP version 2 in Exchange 5.0 and at least begin planning and deploying for a white pages project. That way you'll have plenty of experience before version 3's replication and intelligent referral aspects hit you. We discover ed that implementing LDAP into an Exchange messaging system mandates three steps: configuring the protocol in your Exchange Server, deciding which attributes to expose to anonymous users, and configuring the client to access the LDAP-enabled directory. Configuring the gateway is quick and easy, but it'll take some time to configure the clients correctly. You'll need some planning to settle on which attributes to expose.
|
|
|
|
Moving Ahead With LDAP3 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 |
|
|
![]() |
|
|
|
|














