In-Depth
Integrate an LDAP Server Into Your System
Distinguished Names (DNs) are one of the least-understood LDAP server components. Get an introduction to them, and see how a virtual directory can help with DN management.
Windows Server System (WSS) administrators often have a difficult time comprehending one of the Lightweight Directory Access Protocol (LDAP) server components: Distinguished Names (DNs). In this article you will learn about this concept and see how a virtual directory can help with DN management.
A DN is the name of an entry in an LDAP server. It acts as the primary key (or address) for an LDAP entry. The DN is composed of attribute value pairs that identify where the LDAP entry is located in the Directory Information Tree (DIT). The child attribute or value pair on the far left is called the Relative Distinguished Name (RDN). Here is a typical DN:
uid=mwilcox-1234,ou=people,dc=oracle,dc=com.
The uid attribute means username, the ou attribute means organizational unit, and the dc attribute is short for domain component. A domain component describes an element in an Internet domain name. An organizational unit attribute has multiple values when it's referenced in an entry, as opposed to a DN. An organizational unit for a person contains the "people" or "users'" value, and at least one other value to define the user's department in his or her organization, such as product management. For example, ou=people is a common definition because it provides an easy way to group all user objects in most LDAP management tools.
The RDN element exists because a DN is designed to be unique in its LDAP server—ideally it should be globally unique, such as an Internet hostname. The RDN element must also be unique in its section of the DIT. So you can have only one entry named uid=mwilcox-1234,ou=people,dc=oracle,dc=com in your LDAP server, and you can have only one entry with the RDN element uid=mwilcox-1234 under the ou=people,dc=oracle,dc=com branch.
According to modern LDAP best practices, the best way to provide global uniqueness in your DIT is to use the domain component (dc) attribute. The dc attribute stores values from an Internet domain name. For example, the dc attribute in the code shown earlier is dc=oracle,dc=com, which would conceptually map to oracle.com.
You can easily use Internet domain names to guarantee that your directory is globally unique. This is a simple solution because public domain name server (DNS) hostnames are globally unique by definition. You can also use DNS hostnames to prevent Org A from pretending to be Org B in its directory because hostname ownership is trackable. This naming scheme isn't foolproof, but it's better than alternatives that don't include ownership tracking.
But what do you do if you have an LDAP server that doesn't base its namespace on a domain component? For example, you deployed LDAP in 1999 and used o=oracle.com as your domain name. Or, perhaps your prototype WSS Active Directory forest named o=Staff Directory is now part of production? In either case, you need to expose an LDAP face that maps to the new tradition of dc=oracle,dc=com.
A virtual directory server can help you solve this problem. It exposes a public LDAP server that becomes any base DN that you need. For example, when using a virtual directory, you can configure an LDAP adapter. This adapter lets the virtual directory communicate with an internal LDAP server on behalf of its client connection. You can configure it so that it maps to the internal DN (or remote base) of ou=people,o=octet.com, but has a public base DN (or virtual root) of ou=people,dc=oracle,dc=com. So any entries returned to the LDAP client would have the public form of uid=mwilcox-1234,ou=people,dc=oracle,dc=com.
If you bind an LDAP to the virtual directory, you must use the public DN uid=mwilcox-1234,ou=people,dc=oracle,dc=com. Before performing other operations, the virtual directory's LDAP adapter transforms the DN into the proper internal DN. This process also happens for any modify- or add-entry operations.
Finally, what do you do if you work for a higher education institution and you need to deploy two independent WSS Active Directory forests? Suppose you name one with a base DN of dc=staff,dc=myuniversity,dc=edu, and the other with a base DN of dc=students,dc=myuniversity,dc=edu. Although both forests have similar roots, you have a problem: They require at least two different LDAP server hosts. In addition, many applications have trouble dealing with a split user population. This scenario happens not only in academia (where administrator computing and student computing are often managed separately), but also in Forbes Global 2000 companies (where the parent corporation is composed of many independent organizations).
You can most easily expose LDAP applications to a single LDAP server with a base root of ou=people,dc=myuniversity,dc=edu. You can also munge all the data into a single directory server, but you would be adding yet another synchronization process. And, munging is not always possible because of political or legal reasons. For example, data owners might not want to relinquish control of their data, or you might be legally compelled to protect the privacy of your users' data.
A virtual directory can also assist you in this scenario. You can merge all directory services into a single view easily, without setting up any type of synchronization process. This type of architecture system helps you avoid potential political and legal obstacles.
Using a virtual directory to configure two LDAP adapters maps your internal roots to their proper user sub-trees (such as cn=Users,dc=staff,dc=myuniversity,dc=edu and cn=Users,dc=students,dc=myuniversity,dc=edu). However, each adapter's public interface would become a child of ou=people,dc=myuniversity,dc=edu. For example, the WSS Active Directory server would be called ou=staff,ou=people,dc=myuniversity,dc=edu for a member of your staff. And for your students, the virtual directory would be called ou=students,ou=people,dc=myuniversity,dc=edu. With a single base of ou=people,dc=myuniversity,dc=edu, you can now search both systems using a single LDAP server. So this:
cn=Mark Wilcox,cn=Users,dc=staff,dc=myuniversity,dc=edu
becomes this:
cn=Mark Wilcox,ou=Staff,ou=People,dc=myuniversity,dc=edu.
Whenever you are dealing with names in your DN, you run the risk of duplicate DNs. The virtual directory allows you to define business rules that handle these collisions. For example, you can create a business rule to throw an error message or append a number to a name automatically.
Virtual directories that rely on direct data access offer additional benefits as well. For example, they provide transaction-based fail-over and seek another path automatically if the first is blocked because they go directly to the source directory rather than a separate data store. Virtual directories also act as an LDAP firewall for WSS Active Directory servers. They stand between an Internet application and the source directories, and let you expose selected data to authenticated users in outside organizations more securely than you can with a synchronized database. These additional attributes deliver more value than proxying LDAP services.
Distinguished Names are important factors in an LDAP directory. But they can be difficult for new users to implement&madash;particularly if the directory has limited name space. A virtual directory helps you use DNs more simply, and lets your older applications interface with new ones without requiring you to change the structure of the older applications. If you're facing LDAP challenges, check out a virtual directory.