![]() ![]() Integrating LDAP and The Exchange Directory |
|
Clicking on an entry in Netscape's address book or directory search results window brings up a fully populated directory entry as a Web page. You can view the published attributes on this page. The contents are not well-formatted, and you must scroll from side to side to get the full details of the entry. Entries display the user's name, which now is the alias, and the object class, such as organizational person, remote address (custom Exchange recipient) or group of names (distribution list). The user's primary e-mail address is a hot link that, when accessed, brings up the new message screen with the address already loaded in the To: field.
Internet Explorer 3.02's interface let us search by name, both first and last, and e-mail address in our Exchange directory. The "name" listed in the r esults window is actually the Exchange alias, not the first name or last name. If your e-mail aliases are composed of a first name and first letter of the last name, or last name and first letter of first name, you will have a problem with the way IE 3.02 returns the search results. Suppose you have 12 Smiths in your directory and your e-mail aliases are SmithJ12. A search for "Smith" would return 12 entries for SmithJ, and you would have to click on each to find a specific J. Smith. Internet Explorer needs to return the results with the first name and last name in the name column and not the alias. The e-mail address must be completely specified, or the user will receive a message stating that there are no entries matching the search criteria. If you know the user's domain, such as bcs.boeing.com, but not the user name, you still can't get the information you need. Fuzzy searches would help tremendously here. The IE 3.02 client has a window for displaying search results, including the user's name, e-ma il address, business phone and home phone. If you want more detailed information, just click on the entry or select properties, and youcan view personal, home, business, notes and certificate information. Once the entry is located, the client fills in the attributes contained in the Exchange directory that the user is permitted to view. IE 4.0's Outlook Express client is fully LDAP-compliant and resolves names against the LDAP directory automatically. Compared to the previous version, the client looks and functions basically the same. In addition, you can now enter NetMeeting information into the user's full directory properties screen and click to place the call from there. The name that appears in the search results window is in the form of first name and last name, not the alias, as in IE 3.02. However, there are no wild card searches based on e-mail address, since it is yet to be completely and correctly specified. IE 4.0 lets you authenticate to the directory using standard LDAP authentication, but i t doesn't let you update. This is annoying; decent administrative interfaces to LDAP are difficult to find, and we were hoping this one would work. Nancy Cox can be reached at ncox@nwc.com.
|
||
|
|
Moving Ahead With LDAP3Most LDAP version 2 servers and clients, among them Microsoft Exchange 5.0, Internet Explorer 3.02 and Internet Explorer 4.03, support a very limited feature set---only bind, unbind and search functions. While add, delete and modify are valid LDAP version 2 verbs, Microsoft has chosen not to support them in its Exchange 5.0 release. But with the implementation of LDAP version 3, new operations, such as intelligent referrals, will be available in Exchange 5.5. Additionally, Exchange 5.5 will implement writes so users can, with permission, modify their own entries. Thi s will free administrators from having to constantly update the directory for simple telephone and mail stop changes. Writes will enable LDAP directories to be synchronized across the enterprise. LDAP version 3 also will provide dynamically extensible schema, multinational language support and modular encryption schemes. Intelligent referrals enable a user's request to be automatically sent to another LDAP directory for handling. Suppose you send a request for John Smith at ABC Co. to the LDAP directory at XYZ Corp. The XYZ directory automatically refers your request to the ABC directory. The ABC directory then completes the search and returns the results to you. Some systems will also support multiple referrals, which will occur in the background. With the widespread adoption and deployment of LDAP-compliant servers and clients, the dream of having a worldwide electronic directory will be much closer to reality. LDAP directories won't replace search engines, but they will function as more refined, tar geted search mechanisms. Integrating LDAP into your Exchange messaging system is the beginning of delivering on the dream for your organization.
|
|
![]() |
|
|
Other Workshops
|















