In: Categories » Computers and technology » Servers » Managing Identity Information Between LDAP Directories and Exchange Server 2007
| LDAP directories are commonplace today and can be found in many business environments. UNIX applications in particular make wide use of the LDAP standard for directories. Along with this proliferation of LDAP directory structures comes a need to synchronize the information contained within them to an Exchange 2007 environment. The Enterprise version of MIIS 2003 contains MAs that support synchronization to LDAP directories. Consequently, a good understanding of LDAP concepts is required before syncing between the environments. Understanding LDAP from an Historical Perspective To understand LDAP better, it is useful to consider the X.500 and Directory Access Protocol (DAP) from which it is derived. In X.500, the Directory System Agent (DSA) is the database in which directory information is stored. This database is hierarchical in form, designed to provide fast and efficient search and retrieval. The Directory User Agent (DUA) provides functionality that can be implemented in all sorts of user interfaces through dedicated DUA clients, web server gateways, or email applications. The DAP is a protocol used in X.500 directory services for controlling communications between the DUA and DSA agents. The agents represent the user or program and the directory, respectively. The X.500 directory services are Application-layer processes. Directory services can be used to provide global, unified naming services for all elements in a network, translate between network names and addresses, provide descriptions of objects in a directory, and provide unique names for all objects in the directory. These X.500 objects are hierarchical with different levels for each category of information, such as country, state, city, and organization. These objects can be files (as in a file system directory listing), network entities (as in a network naming service such as NDS), or other types of entities. Lightweight protocols combine routing and transport services in a more streamlined fashion than do traditional network and Transport-layer protocols. This makes it possible to transmit more efficiently over high-speed networks—such as Asynchronous Transfer Mode (ATM) or Fiber Distributed Data Interface (FDDI)—and media—such as fiber-optic cable. Lightweight protocols also use various measures and refinements to streamline and speed up transmissions, such as using a fixed header and trailer size to save the overhead of transmitting a destination address with each packet. LDAP is a subset of the X.500 protocol. LDAP clients are, therefore, smaller, faster, and easier to implement than X.500 clients. LDAP is vendor-independent and works with, but does not require, X.500. Contrary to X.500, LDAP supports TCP/IP, which is necessary for any type of Internet access. LDAP is an open protocol, and applications are independent of the server platform hosting the directory. Active Directory is not a pure X.500 directory. Instead, it uses LDAP as the access protocol and supports the X.500 information model without requiring systems to host the entire X.500 overhead. The result is the high level of interoperability required for administering real-world, heterogeneous networks. Active Directory supports access via LDAP from any LDAP-enabled client. LDAP names are less intuitive than Internet names, but the complexity of LDAP naming is usually hidden within an application. LDAP names use the X.500 naming convention called attributed naming. An LDAP uniform resource locator (URL) names the server holding Active Directory services and the attributed name of the object—for example: LDAP://Server1.companyabc.com/CN=JDoe,OU=Users,O=companyabc,C=US By combining the best of the DNS and X.500 naming standards, LDAP, other key protocols, and a rich set of APIs, Active Directory enables a single point of administration for all resources, including files, peripheral devices, host connections, databases, web access, users, arbitrary other objects, services, and network resources. Understanding How LDAP Works LDAP directory service is based on a client/server model. One or more LDAP servers contain the data making up the LDAP directory tree. An LDAP client connects to an LDAP server and asks it a question. The server responds with the answer or with a pointer to where the client can get more information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory; a name presented to one LDAP server references the same entry it would at another LDAP server. This is an important feature of a global directory service such as LDAP. Outlining the Differences Between LDAP2 and LDAP3 Implementations LDAP3 defines a number of improvements that enable a more efficient implementation of the Internet directory user agent access model. These changes include the following: . Use of UTF-8 for all text string attributes to support extended character sets . Operational attributes that the directory maintains for its own use—for example, to log the date and time when another attribute has been modified . Referrals enabling a server to direct a client to another server that might have the data that the client requested . Schema publishing with the directory, enabling a client to discover the object classes and attributes that a server supports . Extended searching operations to enable paging and sorting of results, and client defined searching and sorting controls . Stronger security through a Simple Authentication and Security Layer (SASL) based authentication mechanism . Extended operations, providing additional features without changing the protocol version LDAP3 is compatible with LDAP2. An LDAP2 client can connect to an LDAP3 server (this is a requirement of an LDAP3 server). However, an LDAP3 server can choose not to talk to an LDAP2 client if LDAP3 features are critical to its application. NOTE LDAP was built on Internet-defined standards and is composed of the following Request for Comments (RFCs): . RFC 2251—Lightweight Directory Access Protocol (v3) . RFC 2255—The LDAP URL format . RFC 2256—A summary of the X.500(96) user schema for use with LDAP3 . RFC 2253—Lightweight Directory Access Protocol (v3): UTF-8 string representation of distinguished names . RFC 2254—The string representation of LDAP search filters
|
legal disclaimer
1) Our website is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringements, please read the Terms of service and contact us to investigate the problem.
2) The E-articles directory team is not responsible for inaccuracies, falsehoods, or any other types of misinformation this tutorial may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here. Please read the Terms of service
Useful tools and features
If you like this article (tutorial), please link to it from your web page using the information above. Linking to this page, this is the only way to help us improve our service, the same time providing your visitors with a way to improve their online experience.
related articles
In Active Directory, all client logons and lookups are directed to local domain controllers and GC servers through references to the SRV records in DNS. Each configuration has its DNS and resource requirements. Exchange relies on other servers for client authentication and uses DNS to find those servers. In an Active Directory domain controller configuration, on the other hand, the Exchange server also participates in the authentication process for Active Directory. Using DNS in Exchange Server 2007 As has bee...
2. Securing and Maintaining an Exchange Server 2007 Implementation
One of the greatest advantages of Exchange Server 2007 is its emphasis on security. Along with Windows Server 2003, Exchange Server 2007 was developed during and after the Microsoft Trustworthy Computing initiative, which effectively put a greater emphasis on security over new features in the products. In Exchange Server 2007, this means that the OS and the application were designed with services “Secure by Default.” With Secure by Default, all nonessential functionality in Exchange must be turned on if needed. Thi...
3. Improvements in Exchange Server 2007 Relative to Security and Compliance
One of the improvement goals Microsoft has had with all of their products over the past few years has been to constantly improve the security in the products. More recently with all of the regulatory compliance laws and policies being implemented, Microsoft has focused a lot of security enhancements to address privacy, information archiving, and compliance support. The release of Exchange 2007 was no different—Microsoft added in several new enhancements in the areas of security and compliance support. One of the addition...
4. Designing Exchange Infrastructure
After Active Directory and the physical OS has been chosen and deployed, the Exchange infrastructure can be set up and optimized for the specific needs of the organization. With these needs in mind, you can do several things to optimize an Exchange 2007 setup, as detailed in the following sections. Determining the Exchange Version When installing Exchange, the choice of Exchange version needs to be made. As with Windows Server 2003, there are two versions of Exchange, Standard and Enterprise. The Standard Edit...
5. Synchronizing Exchange Server 2007 with Novell eDirectory
Novell eDirectory and Novell Directory Service (NDS) environments are relatively commonplace in business environments, and there is often a need to integrate them into deployed Exchange infrastructures. Several tools exist that can make this a reality, including the MIIS 2003 tools discussed. In addition, tools in the Microsoft-supplied Services for NetWare can be used to synchronize directory information between the two directory systems. NOTE Exchange 2000 Server and Exchange Server 2003 included a GroupWise ...
6. Integrating Client Access into Exchange Server 2007 Design
Although the Exchange server is a powerful systems component, it is only half the equation for an email platform. The client systems comprise the other half, and are a necessary ingredient that should be carefully determined in advance. Outlining Client Access Methods Great effort has been put into optimizing and streamlining the client access approaches available in Exchange 2007. Not only have traditional approaches such as the Outlook client been enhanced, but support for nontraditional access with POP3 and...
7. Domain Name System and Its Role in Exchange Server 2007
For computer systems to communicate with each other, whether you are talking about a local area network (LAN), a wide area network (WAN), or the Internet, they must have the ability to identify one another using some type of name resolution. Several strategies have been developed over the years, but the most reliable one to date (and the current industry standard) is the use of a DNS. Accurate name resolution is critical in a mail environment as well. For a message to reach its destination, it might pass through several syste...