Zoomit VIA and the Dedicated Metadirectory

Discover what makes this integrated metadirectory support and directory service solution tick

Zoomit VIA embodies the concept of the metadirectory: a directory service that integrates numerous other directory services to improve the ease and effectiveness of directory management. (To get an overview of the metadirectory idea and what a metadirectory can do for an organization, see Craig Zacker, "Metadirectories: Directory Services for the Enterprise," page 121.) VIA provides comprehensive metadirectory support for the most common network applications and operating systems used on heterogeneous networks. VIA's proprietary directory service gives users a unified view of all the directories on their network. Unlike many other metadirectory solutions, VIA supports various email, application, and network operating system (NOS) directories (e.g., Lotus Notes, Windows NT domains, and Novell Directory Services--NDS).

Here's how VIA works. You import the data from your network directory services into separate areas (connector spaces in VIA) of VIA's metadirectory. For example, after you import your NDS, NT domains, and Lotus Notes directories into separate connector spaces, you have three objects in the metadirectory for each network user. Then, for each user, you create a composite entry that consists of the user-specific data from each of the other three objects in the metadirectory. Each composite entry becomes the single point of administration for a specific user. The composite entries form the VIA metaverse, a superdirectory that contains information to let users access network services.

When you modify the properties of a composite object, VIA replicates the changes to the source objects in the connector spaces and makes the same changes to the originating directories. VIA does not alter the process by which users log on to their network services. Client systems continue to interact with the services' individual directories, but the information in those directories is derived and updated from the data in the metadirectory.

VIA includes attributes for metaverse objects that you can use to store personal information (e.g., phone numbers, job titles, and photographs) about your users. Users can access the metadirectory through any Web browser and search for other users by name. By granting your users specific directory access rights, you can let them modify specific properties in their metadirectory entries and publish documents for other users by adding the documents to the directory as new objects. Thus, the VIA directory is based on the replication of other directory services into its proprietary structures. Let's examine the VIA directory in detail by looking at how information flows between directories and examining VIA's security model.

Metadirectory Structure
VIA consists of three software entities: the directory server; the Zoomit Compass client program, which lets you view and manipulate the contents of the metadirectory; and a collection of management agents, which provide access to the directory services VIA supports. Because VIA uses its proprietary directory service as the metadirectory, VIA is more complex than products such as NetVision's Synchronicity, which rely on external directories such as NDS. (For information about NetVision's product, see "NetVision's Synchronicity for NT," page 125.)

VIA's directory server software runs on NT Server, NT Workstation, or Windows 95. You can configure VIA to run as an NT service that automatically loads when you boot the system. To publish its services, the VIA directory server uses the well-known port numbers for Lightweight Directory Access Protocol (LDAP) and HTTP, and you can modify these defaults for your system. On large networks, you can distribute the VIA database among several servers. The VIA directory server uses referrals to redirect client requests to other servers that have the requested information. VIA can also replicate the directory at regular intervals to provide fault tolerance and load balancing.

VIA uses the same namespace structure as the X.500 directory. This name-space is identical to that used by LDAP directories such as Netscape's Directory Server and is similar to that used by NDS. (For more information about LDAP directories, see Tao Zhou, "Exploring Netscape's Directory Server 3.0," page 137. For information about NDS, see William Wong, "Novell's NDS for NT," page 131.) You use standard container objects such as countries, organizations, and organizational units to create the metadirectory tree hierarchy, and you populate the tree with objects representing users, groups, and servers. Unlike X.500, VIA does not enforce specific relationships between object classes. For example, traditional X.500 naming requires you to put country or organization objects at the top level of the tree, with organizational units beneath them. In the VIA directory, objects can appear anywhere in the tree. This structure lets you organize a directory for a large international corporation logically--by dividing the tree into departments at the top level and countries at the second level. Another difference between X.500 and VIA naming is that user objects in the VIA directory can have subordinate objects that represent documents or other data files users want to publish to other network users.

Zoomit Compass, VIA's administrative client program, uses the LDAP port to access the directory server and displays the contents of the directory tree, as Screen 1 shows. From the Zoomit Compass interface, which can run on any NT or Win95 system on a network, you can create and delete directory objects and manage their properties. Because VIA supports the LDAP standard, users can use any LDAP client to access the VIA directory; such clients include those integrated into the Microsoft Internet Explorer (IE) and Netscape Communicator clients.

The HTTP protocol lets clients use any Web browser to view the VIA directory and provides read-only access to the metaverse. However, because the default Web pages are frames-based, users must have IE 3.0 or later, or Netscape Navigator 2.0. VIA includes intelligent directory agents (IDAs), which let users of major email packages search the directory for user addresses from within their client applications.

To access other directory services running on a network, VIA uses management agents, synchronization modules that run on the VIA directory server and communicate with directories using the directories' native protocols. VIA includes management agents for many of the most commonly used directory services, including the NT domain, NDS, NetWare bindery, and Banyan VINES NOS directories; Netscape's Directory Server; and email packages such as Lotus Notes, cc:Mail, DaVinci, Microsoft Exchange, Novell GroupWise, and Banyan BeyondMail. The VIA program includes a development kit that lets programmers create management agents. Most VIA management agents do not require client software modules on the systems that host the subordinate directories. Two exceptions to this rule are Lotus Notes and NDS (NDS communicates with VIA using LDAP, and therefore requires that you install Novell's LDAP Services for NDS). Management agents log on to the directories like any other client, using credentials you supply in the Compass application.

Directory Information Flow
You populate the VIA metadirectory by creating a management agent for each directory service on your network. VIA accesses each directory through a management agent that uses a protocol the service supports. VIA replicates the directory entries to a connector space that is dedicated to the service's management agent. The management agent then functions as the conduit through which VIA continually synchronizes the data in the connector space with the data in the original directory.

During the replication of the directory data to the connector space, you can have VIA create a metaverse entry for each new user and group it imports. At first, this entry contains only the information from the single directory service object that was imported during the entry's creation. To combine the attributes of user objects in multiple directories into one metaverse entry, VIA must join (a Zoomit term) the metaverse entry to the connector spaces in which the other network directory entries reside. VIA performs the join operation based on the value of a property you select. The common name (cn) property is the default, but in large organizations you can avoid conflicts between users with similar names by specifying a property based on an employee number or Social Security number.

As in Figure 1, the joining process creates a two-way relationship between the metaverse entry and the corresponding entries in the connector spaces, and the metaverse entry and the original directory services. Through this bidirectional flow, VIA replicates changes you make to the metaverse entry to the connector spaces and then to the original directories. Conversely, the bidirectional flow means you can modify an entry in one of the original directories and VIA will update not only the corresponding connector space and metaverse entries with the new information, but also the entries in the other connector spaces and source directories. VIA uses rules contained in its Attribute Assignment List to control the processes by which VIA updates entries in all three directories (the metaverse, the connector space, and the original directory service). The Attribute Assignment List rules specify which attributes VIA modifies and how VIA resolves conflicting values. Separate rules apply to relationships between the connector space and the metaverse and between the original directory service and the connector space.

Metadirectory Security
VIA provides a detailed security model that lets you control users' access to specific areas of the directory, specific entries, and specific attributes. You can configure VIA to use encrypted passwords for the logon sequence so that network monitoring tools cannot intercept the data. As with most hierarchical directories, access rights in the VIA metaverse flow downward through the tree until they reach the end of a branch or are overridden. This downward flow means configuring rights for large groups of users is a simple matter. However, each object can contain security rules that override those inherited from objects higher in the tree.

When you apply security rules to a container object in the tree, that object becomes an administration point. The security rules take the form of two new objects, Context Security and Context Shared Data, that are subordinate to the administration point. At each administration point, you can give specific users access to the objects in the container or to specific attributes of those objects. By default, VIA gives users read-only access to the entire tree, but you can hide certain objects or attributes from public view. Each user's object dialog box contains a security screen with which an administrator can control specific attributes and grant or deny users' rights. In Screen 2, the security screen grants user craigz permission to change the home phone number property in his directory entry.

A Full-Featured Solution
Zoomit VIA is a turnkey metadirectory solution. It comes with management agent support for many other directory services and does not require custom programming or additional modules. In addition, the VIA directory service has distribution and replication features that make it sufficiently scalable to support large networks with thousands of users. These capabilities have a price, however: VIA takes time and effort to learn, deploy, and administer. Unlike metadirectory products that rely on other directories to store objects, VIA offers a full-featured directory service in addition to its metadirectory capabilities. As with any new directory service, effecting a VIA rollout on your network requires careful consideration and planning.