Classnotes | LDAP01 | RecentChanges | Preferences No diff available--this is the first major revision.
(no other diffs)As we have seen, standard protocols like LDAP do go a long way towards interoperability. However, the problem starts when we encounter applications which disregard these standards and become intimately tied with a particular vendor's rendition of an LDAP server. Many UNIX components require that people be identified under an organizational unit of People with associated UIDs. Many Windows components use the sAMAccount setups for user validation.
In addition to multi-vendor problems, there are the problems an organization has with the way the data in these directories gets distributed. This, in fact, is the reason why our data is so fragmented as is; why we have redundant information between user accounts on one system, email accounts on another, etc.
So why do we want to do it? Why do we want to link these diverse, multi-vendor directories in an amalgam of their parts? Why not settle on a single LDAP vendor, who has no doubt made it easy to build distributed directories and application integration which just aren't addressed by the standards? If it doesn't make our life easier, then why do it?
The answer to this is that, sooner or later a single vendor directory will force you to make decisions that you're uncomfortable with. Let's assume that you're adding a new application server, such as a calendaring system, at your site. This server is backed by an LDAP directory and requires certain protocol extensions from the directory. Naturally, the vendor has tested the application server with a particular LDAP server in mind- perhaps even the vendor sells the LDAP product. But as fate would have it, you have already invested a lot of time and effort into building an LDAP directory, and the directory server that your new shiny calendering program requires is not that one.
In this case, there are three possible solutions:
Abandon the calendar server, since its not supported by your LDAP server.
Replace the existing directory with the one that supports the calendaring server. This will likely mean replacing existing applications that depend on your current server. And what about the next time a strange LDAP requirement is introduced? Do you replace your whole system again then?
Install a new LDAP server that supports the calendaring software and include it in a subtree of your existing directory framework.
The last option is really the one that makes the most sense: It allows you to augment rather than replace. Furthermore, you are still ready and available to impliment additional LDAP servers as further subtrees as the need arises.
Working example with Active Directory
Here's a working example of just how to accomplish something like this using OpenLDAP and Active Directory as our two servers.
Let's assume that we already have our OpenLDAP server in place, and from ldap.odyssey.com it is servicing our root naming context:
dc=odyssey,dc=com
Now, let's assume we need to add in an Active Directory server for compatability reasons with some application. Let's assume this server is known as ad.odyssey.com and is servicing the root Active Directory:
dc=ad,dc=odyssey,dc=com
(This setup is very similar to the example the book gives in chapter 9. Take a look at Figure 9-6 on page 206 for an idea of the layout of such a network)
Note that this very different from what we've looked at today, as now our primary directory is OpenLDAP and Active Directory is just an augmentation.
We now need to add two things to our system to make such a subtree work. First, we need to point from the Active Directory server to the OpenLDAP server for our root server. Second, we need to refer client searches from the OpenLDAP server back to the Active Directory server.
The ADSI Edit MMC snap-in is needed to add an LDAP referral to Active Directory. This tool is included in \SUPPORT\TOOLS on the Windows 2000 Advanced Server CD. From this snap-in, the referral from the Active Directory domain to the OpenLDAP server must be created inside the container:
This entry is the root for all entries processing referrals to subdomains in an Active Directory tree. You create a new crossRef object and place in it the following information
This tells Active Directory to return a referral pointing clients back to the OpenLDAP server.
Next, we need to instruct the OpenLDAP server to point a reference back to the Active Directory server (on the Active Directory domain). This entry is added to the OpenLDAP server:
dn: dc=ad,dc=odyssey,dc=com
objectClass: referral
objectClass: dcObject
ref: ldap://ad.odyssey.com/dc=ad,dc=odyssey,dc=com
dc: ad
The two directories will now be linked in such a way that a query made to one server will be able to locate data from the other.
