

Metadirectories: Keeping User Info in Sync
January 25, 1999
Every directory and directory-aware application vendor continues to describe LDAP as the directory panacea, but in truth, LDAP is just a common directory-access protocol. It offers little standardized schema other than the basic user information found in LIPS (Lightweight Internet Person Schema). Although nearly every directory product today can speak LDAP as a lowest common denominator, few standards exist for determining how information is stored in the directory or what types of information should be represented.
Unfortunately, efforts at developing a non-partisan, standards-based directory spec, such as X.500 or The Open Group's DCE (Distributed Computing Environment), did not yield the necessary support among enterprise NOS and application vendors. Vendors further stymie interoperability by insisting on proprietary password-hashing algorithms (see "Password Sync: A Directory Sync Headache" on page 54), making enterprisewide password synchronization an ongoing struggle.
Sync Versus Join The metadirectory market offers two types of products: those that synchronize directories, which includes translating the appropriate schema elements, and those that perform a join.
Although simple synchronization involves straightforward copying of directory objects and related objects from one directory to one or more other directories, few installations will be able to perform this task without a hitch. The key issue is the uniqueness of attributes. The amount of care observed by an organization to mandate unique user names that span the organization will be
directly reflected in the ease of directory synchronization. In the best case, user "jsmith" in a specified NDS context represents the same "jsmith" in the target Windows NT domain. In this scenario, synchronization software will assume the user is the same in both directories and will replicate information between them.
But what happens when names collide? NetVision's Synchronicity lets the administrator specify how to deal with this situation: Either replace the target object, create a new object with a new name or generate an error.
When the situation grows more complex, as it will with most medium to large enterprise networks, name collisions between multiple systems will occur. Here, the concept of join comes into play. By creating a space where user objects can be joined logically, objects with different names can be linked. These associations provide a single, logical point of access to user information from metadirectory-aware clients (such as user front ends that query the metadirectory server instead of querying a NOS directory), as well as the glue that links that users' objects throughout various directory services.
While this concept seems simple--assuming that user IDs are standardized among all managed directories--the join function becomes critical when different directories have varying user naming conventions. For example, this join lets the metadirectory link "jsmith" in NDS to "smithj" in an NT domain. If this is as simple as a transposition of the first initial, Zoomit VIA Server offers extensible scripting languages to automate this process. However, first-time installations will likely spend significant time manually reviewing joined objects for accuracy.
If you're planning a metadirectory installation, review synchronizations between various systems to determine accuracy. If you use a non-join product such as NetVision's Synchronicity, user names must be standardized and guaranteed unique throughout all managed directories.
|