Your First Steps to Data-Sharing and Syncing
Articles and Tips: article
01 Jun 2003
Without knowing your company's name or business, I'll bet I know at least this much about its network: it includes a variety of systems that run on a mix of platforms. If you're not impressed by this guess, you shouldn't be. Guessing that a network today runs a variety of systems is as safe as presuming that San Diego will enjoy sunshine tomorrow.
System diversity on your network is the unavoidable result of "business as usual." Each time a business problem arises, you naturally purchase the system that best solves the problem. Occasionally, the winning system is platform-specific, so you install the required platform. Meanwhile, department managers install the systems with which they're most familiar. Perhaps your company merges with another company, introducing still more systems.
The point is that as your company grows and changes, your network necessarily incorporates new systems. By now, you may have concluded that system diversity is a necessary evil. To the extent that system diversity is and always will be the inevitable state of networking affairs, this conclusion is valid. However, system diversity does not have to give rise to the administrative and security headaches, a.k.a. "evil", typically associated with managing identity information across multiple systems.
As a network administrator, you're familiar with the inefficiencies of this task. When employees get hired, fired, transferred or simply get a new telephone number, you and your coworkers are stuck entering and re-entering the same information multiple times. In fact, you might be managing identity information across 50 or more directories. If you are, you don't need to imagine the administrative burden this causes; you're living with the burden even as you read this.
Manually managing identity information across multiple systems not only costs time (and money), but also increases the risk for inaccuracy, which can lead to security breaches. For example, if you forget to delete a user's account only once in one system, you leave your network vulnerable to attacks from disgruntled former employees.
Furthermore, when identity information exists in disparate systems, users may have more than one password. This takes a toll not only on users' production, but also on the number of help desk calls. More to the point, this password juggling act takes a toll on network security. If users have multiple passwords, they tend to create simplistic passwords or remember complex ones by printing them in easy-to-find places.
NetWare 6.5 offers you a bundle
Unlike the system diversity from which they stem, these headaches are unnecessary, just ask Novell. Novell, as you may know, has a solution to the problems associated with managing identity information across virtually all of your disparate systems: Novell DirXML 1.1a. (For more information about DirXML 1.1a, see The DirXML Basics.) What you might not know is that Novell bundles with NetWare 6.5 a collection of DirXML 1.1a components that together form the DirXML Starter Pack. DirXML Starter Pack enables you to share data and synchronize passwords between three directories that commonly co-exist on today's networks: Novell eDirectory, Microsoft Active Directory and Microsoft Windows NT Domains.
With DirXML Starter Pack, you experience the automated and bidirectional exchange of data between a few systems. In the process, you get a little taste of the vast potential of DirXML 1.1a, a full-scale deployment of which enables you to share data bi-directionally (if you choose) between hundreds of network directories, databases and critical applications, including PeopleSoft, SAP HR, Lotus Notes, Novell GroupWise, Active Directory and NT Domains. (For more information on DirXML, see DirXML 1.1: Syncing with Style online at www.novell.com/connectionmagazine/2001/10/dirxmlo1.pdf.)
An Architectural Overview
Like DirXML 1.1a, DirXML Starter Pack delivers a data transformation engine and system-specific drivers that work together to communicate data changes between an eDirectory tree and other systems. To gain a big-picture sense of the DirXML 1.1a and, consequently, DirXML Starter Pack architecture, picture these components working together to create what amounts to a figurative system wheel. (See Figure 1.)
Figure 1
The DirXML Engine
The hub of this wheel is a server running eDirectory 8.6.2 or later and the DirXML 1.1a engine. As you can guess, the eDirectory tree running on this server should hold replicas of the data you want to synchronize. The license for DirXML Starter Pack entitles you to run the DirXML 1.1a engine on NetWare only. (If you later upgrade to DirXML 1.1a, you can run the engine on most popular platforms, including NetWare, Windows, Solaris and Linux.)
This engine is responsible for processing any data that travels from your central eDirectory tree to other systems or from other systems to your central eDirectory tree.
When changes occur in your central eDirectory tree, the DirXML engine uses eXtensible Markup Language (XML) to create a Document Object Model (DOM) that describes these changes. The DirXML engine then processes these changes according to rules, filters and transformation documents that are associated with drivers' subscriber channels. The DirXML engine hands these changes to the DirXML drivers, which push the information through to their respective systems.
Similarly, when the DirXML engine receives changes from a DirXML system driver, the engine processes these changes according to rules, filters and transformation documents that are associated with this driver's publisher channel. The DirXML engine then pushes these changes to eDirectory. (See Figure 2.)
Figure 2
With Novell exteNd 4.1, you can realize the image of building a portal that delivers information, regardless of its location, to users who need it, when they need it, how they need it, and on any device they need it, including wireless devices.
The DirXML Drivers
When you deploy DirXML 1.1a, any system for which you have a DirXML driver can form the perimeter of the figurative architectural wheel. As already implied, DirXML Starter Pack, includes licensed DirXML 1.1a drivers for the following systems:
Active Directory
NT Domains
eDirectory
In addition, DirXML Starter Pack includes evaluation copies of DirXML 1.1a drivers for the following systems:
Lotus Notes
LDAP
Exchange 5.5 and Exchange 2000
GroupWise
Delimited Text
JDBC
PeopleSoft
SAP HR
You can install and test any of these evaluation drivers and, if you choose, can purchase and activate them during or after the 90-day evaluation period. (If you wait until after the 90 days, the drivers cease to function until you activate them.) These evaluation drivers simplify the process of extending the data-sharing foundation that you build using DirXML Starter Pack.
Each of the systems for which you have a driver can be configured to subscribe to data changes made in the figuratively central eDirectory tree and publish data to this tree over their drivers' subscriber and publisher channels, respectively. These publisher and subscriber channels represent the spokes that enable the exchange of data between your central eDirectory tree and the systems on the wheel's perimeter. (For more information about DirXML 1.1 drivers in general, see From the Drivers' Seat.)
The good news is that for each of the licensed drivers, DirXML Starter Pack includes a configuration file that you import into the driver as part of the installation process. These configuration files set up the driver's rules, filters and transformation documents that dictate what data from this system should be exchanged with other systems, and how this data should be exchanged.
These configuration files greatly simplify the process of installing and deploying DirXML Starter Pack in a lab environment. In fact, Novell estimates you'll need approximately two days to get DirXML Starter Pack up and running in your lab. Several wizards walk you through the processes of installing DirXML Starter Pack and importing the configuration files that pre-configure the DirXML 1.1a drivers for the aforementioned systems. Hence, within relatively short order, you can observe DirXML Starter Pack in action in your lab and begin sensing the potential of DirXML 1.1a.
The Remote Loader Service
Another critical component to the success of your DirXML Starter Pack deployment is the DirXML Remote Loader service. This service enables the DirXML engine to communicate with a system running on a remote computer.
To be more specific, the DirXML Remote Loader enables you to run a driver's API and shim on one computer, while running the DirXML engine and eDirectory tree with which this system will communicate on another. (For more information on drivers' API and shim, see From the Drivers' Seat.)
The Default Configuration
By default, the licensed and preconfigured drivers included in DirXML Starter Pack synchronize data bi-directionally. The specific object data that these drivers are configured by default to synchronize is different for each driver.
For example, the Active Directory driver synchronizes Group and Organizational Unit object data between an Active Directory domain and an eDirectory tree, whereas the driver for NT Domains synchronizes only user object data between an NT domain and an eDirectory tree. (For a complete list of the specific data each driver synchronizes by default, see Table 1, Table 2, and Table 3 respectively.)
Table 1
Table 2
Table 3
In addition to User, Group, and Organizational Unit object data, the eDirectory driver also synchronizes Country and Organizational object data between two eDirectory trees. However, what makes eDirectory more unique than the data it synchronizes is the method by which it synchronizes this data. Whereas the drivers for Active Directory and NT Domains (like most DirXML 1.1a drivers) exchange information with an eDirectory tree by way of the DirXML 1.1a engine, the eDirectory driver exchanges information directly with another eDirectory driver in a different eDirectory tree.
As mentioned, the license for DirXML Starter Pack included with NetWare 6.5 entitles you to load the DirXML 1.1a engine only on NetWare. The license then enables you to connect from this DirXML 1.1a engine the eDirectory tree running on this server to the following systems:
Active Directory on a Windows 2000 server by way of the DirXML Remote Loader and DirXML 1.1a Driver for Active Directory running on the same server.
NT Domains running on a Windows NT 4 server by way of the DirXML Remote Loader and DirXML 1.1a Driver for NT Domains running on the same server.
From The Drivers' Seat
Like all DirXML drivers, the three licensed drivers and eight evaluation drivers included with DirXML starter pack consist of three main parts:
System application program interface (API) The system API enables the driver to communicate with and make changes in the driver's respective system.
Driver shim The shim uses the API to push information (most commonly via the DirXML engine) in two ways: from an eDirectory tree to the system over the driver's Subscriber Channel or from the system to an eDirectory tree over the driver's Publisher Channel.
Rules, Filters and Transformation Documents Each driver includes a collection of XML and eXtensible Style Sheet Language Transformation (XSLT) documents comprised of rules, filters and other parameters (such as event and data transformations) that together determine the scope and nature of information exchanges between a system and your logically central eDirectory tree.
These rules, filters and transformation documents are associated with drivers' publisher and subscriber channels; this enables the DirXML engine to apply the appropriate parameters to data coming from another system into eDirectory (over a driver's publisher channel) and data coming from eDirectory into another system (over a driver's subscriber channel).
Filters specify which objects and attributes can be shared between the target system and eDirectory. Generally speaking, drivers have two filters, one each for the publisher and subscriber channel.
Rules define requirements for object creation, matching and placement.
Transformation Documents specify how various events and data should be transformed so that the format is appropriate for the receiving system.
The license also entitles you to connect your figuratively central eDirectory tree to another eDirectory tree running on another NetWare server. This server can be running NetWare 5.1 or higher. (The license does not entitle you to connect your figuratively central eDirectory tree to another eDirectory tree running on another platform.)
Starting up Starter Pack
To get DirXML Starter Pack up and running in the manner just described, you begin by installing the DirXML 1.1a engine on a NetWare 6.5 server that is running replicas of the object data you want to synchronize between your eDirectory tree and your other systems. Beyond this initial step, the specific installation procedure varies from network to network, depending, among other things, upon the components and products you choose to install, and where you choose to install them.
Consequently, providing step-by-step instructions regarding how to setup DirXML Starter Pack is impossible (not to mention boring). However, I can give you enough information for you to gain a sense of the relative ease with which you setup DirXML Starter Pack in a lab environment and the general steps required to do so. For the purposes of this discussion, assume you are setting up DirXML Starter Pack so that the final result is the same as the setup shown in Figure 3.
Figure 3
In the setup shown in Figure 3, the server running the DirXML engine also runs a DirXML driver for eDirectory. When you install the engine, you'll see a list of all the licensed and unlicensed DirXML drivers on the DirXML Starter Pack CD. From this list, you click to select the DirXML Driver 1.1a for eDirectory. Doing so is taking the first step to enabling the exchange of information between the eDirectory tree on this server and an eDirectory tree on another NetWare server.
iManager Plug-ins
Once you've installed the DirXML engine and before you begin to setup other systems in your DirXML setup, you install the Novell iManager 2.0 plug-ins for DirXML Starter Pack. That is, you install these plug-ins if you plan to use Novell iManager to setup and manage DirXML Starter Pack, as Novell recommends. If Novell iManager is not an option in your environment, you can also use ConsoleOne to manage DirXML Starter Pack, which includes the necessary plug-ins.
Fueled by Novell's goal to simplify access to and management of eDirectory, Novell iManager enables you to use a browser and, in some cases, a handheld device to manage your company's eDirectory tree. Using Novell iManager, you can access your tree over wired or wireless connections to an intranet, an extranet or the Internet.
The Novell iManager plug-ins for DirXML Starter Pack provide a graphical view of DirXML objects and their relationships to one another. Perhaps more important, these plug-ins enable you to access and use wizards that walk you through various tasks, such as importing configuration files into the licensed drivers.
Novell iManager also enables rolebased administration (sometimes called delegated administration). What this means in this context is that by using Novell iManager, you can farm out to users specific sets of administrative tasks related to managing your DirXML setup. These users receive only the rights they require and see in the iManager interface, and only the tools they need to complete the tasks you assign them.
You can install Novell iManager and the iManager plug-ins for DirXML Starter Pack on the same server running the DirXML engine. However, for performance reasons, and as shown in Figure 3, Novell recommends installing Novell iManager and the plug-ins on a separate NetWare 6.5 server. (At this point, by the way, Novell iManager 2.0 runs only on NetWare 6.5.)
Setting Up Your Systems
After installing the DirXML engine and the iManager plug-ins, you're ready to set up the systems you want to include in your data-sharing and synchronization solution. For Active Directory and NT Domains, you complete several steps, including the following:
Create an eDirectory account for the driver that the driver alone uses to access Active Directory or NT Domains
Install the DirXML 1.1a drivers and the DirXML Remote Loader service:
- You install the DirXML 1.1a Driver for NT Domains and the DirXML Remote Loader on the Primary Domain Controller. The server on which you install these components must also be running Windows NT 4 with Service Pack 6 or later. - You install the DirXML 1.1a Driver for Active Directory and the Remote Loader on the Domain Controller. The server on which you install these DirXML components must also be running Windows 2000 Server or Windows 2000 Professional with Support Pack 1 and Internet Explorer 5.5 or later.
Gather and record system-specific details, such as the password and the IP address and port number to the DirXML Remote Loader that the DirXML driver will use to access a system.
Import the drivers' configuration files. (For more information about these files and the process of importing them, see the next section: Configuration Files.)
Setting up an eDirectory tree to exchange information with your centrally located eDirectory tree requires fewer steps. Basically, you install a second DirXML 1.1a Driver for NetWare on a NetWare server running a replica of the information you want to synchronize with your logically central tree. In the setup shown in Figure 3, the other eDirectory tree is running on a NetWare 5.1 server with ConsoleOne as the management tool.
As you did for the NT Domains and Active Directory drivers, you should also gather and record some configuration information, such as the IP address and port number for your logically central eDirectory tree.
Configuration Files
After you've installed the DirXML drivers on each of the systems you want to include in your DirXML Starter Pack setup, you import these drivers' configuration files. To do so, use the Import Drivers Wizard in Novell iManager. This wizard prompts you for information you recorded during the driver installation process, as well as other information. Using your responses and information from the configuration files, the wizard configures your DirXML drivers.
Your responses to the wizard's prompts impact your driver's final configuration. For example, during the import process, the wizard prompts you to specify whether this driver is remote or local, and to indicate the direction of data flow.
The default setting is for data to flow bi-directionally. However, you can change this setting by indicating you want data to flow from one system to the others. For example, you could respond to the prompt by indicating that you want data to flow from Active Directory to eDirectory, in which case you make Active Directory the authoritative source for identity information.
Now for the Results
Assuming you accept the default, bi-directional data flow setting, the result of your setup is simply this: When you or one of your co-workers changes identity data in any one of these systems, the Active Directory Domain, the NT Domain, the eDirectory tree on the perimeter or the centrally located eDirectory tree, DirXML Starter Pack ensures this change is pushed through to the other systems. In other words, you enter data once in one system, and DirXML Starter Pack automatically updates all other systems.
The Quick Path to Password Synchronization
In addition to enabling you to share data bi-directionally between eDirectory, Active Directory and NT Domains, DirXML Starter Pack also enables you to synchronize passwords between these systems by way of DirXML Password Synchronization for Windows.
DirXML Password Synchronization for Windows (hereafter, PasswordSync) allows passwords to be securely, consistently and automatically synchronized between eDirectory and the Active Directory domains and NT domains that participate in your DirXML Starter Pack setup. (The DirXML 1.1a Driver for eDirectory manages password synchronization between eDirectory trees.)
PasswordSync is a distributed application that requires DirXML drivers, and that includes PasswordSync Filters and PasswordSync Agents. Basically, PasswordSync Filters capture changes to passwords and pass these changes to PasswordSync Agents over encrypted channels.
PasswordSync uses DirXML to determine associations between various systems. For example, PasswordSync might determine that a new password sent by JJOHNSON in an NT domain should be associated with user jjohnson.myorg.corp in eDirectory.
Because Microsoft clients forward password change requests to domain controllers for processing, you install PasswordSync Filters (for Active Directory and NT) on all domain controllers, even domain controllers that are hosting DirXML drivers. This means that every NT Primary Domain Controller (PDC), every Backup Domain Controller that might be promoted to a PDC, and every Active Directory Domain Controller requires a PasswordSync Filter.
In contrast, you install the PasswordSync Filter for eDirectory on a Novell Client. This is because, unlike Microsoft clients, the Novell Client does not forward the password itself to other network resources. The PasswordSync Filter for eDirectory is an update to the latest version of the Novell Client that transmits the password securely to the PasswordSync Agent for processing.
You install PasswordSync Agents on any Windows NT 4 or Windows 2000 server or workstation that is continuously available and running the latest Novell client. You should install a PasswordSync Agent on as many computers as you deem necessary to achieve the domain coverage and redundancy you need. PasswordSync Agents communicate to eDirectory the notifications of password changes they receive from PasswordSync Filters. (See Figure 4.)
Figure 4
You and your users can change a password from several different workstations and servers, and PasswordSync automatically synchronizes across all systems. However, there are instances when PasswordSync Agents are not involved in a password-change transaction; hence, PasswordSync is unable to synchronize the changed password across Active Directory and NT Domains.
For example, if a user changes her password from a workstation using an LDAP client, such as the client provided by Novell eGuide, only the eDirectory password will change. This is because the PasswordSync Agent is not involved in the transaction, so the NT and Active Directory domain controllers receive no notification of the change.
This same situation occurs if you change a password from ConsoleOne running on a non-Windows workstation or server, and also if you change a password using Novell iManager.
However, PasswordSync Agents are involved in most password-change scenarios. For example, when you or your users change a password on any of the workstations or servers listed below, PasswordSync Agents are involved; hence, PasswordSync is able to automatically synchronize the change across your systems:
Workstation running the Novell Client
Workstation not running the Novell Client
Windows server or workstation running Microsoft Management Console
Windows workstation or server running ConsoleOne
Workstation or server running Novell iManager
One Small Step to Solve One Big Problem, and a Giant Leap Toward Solving an even Bigger One
When you upgrade to NetWare 6.5, you have the opportunity to deploy DirXML Starter Pack and observe it in action. When you do, you begin to gain a sense of the vast potential of DirXML 1.1a, which Novell product manager Doug Anderson calls "great technology." Novell believes that DirXML 1.1a is so great that "every customer should have it," says Anderson.
He might be right, but here's the catch: As a complete data-sharing and synchronization solution, DirXML is inherently complex. Consequently, deploying DirXML 1.1a is an involved and lengthy process. In fact, to take full advantage of all that DirXML 1.1a has to offer, you probably need help from Novell consultants or partners.
Before you invest your time in building a complete data-sharing solution with DirXML 1.1a, you probably want to see it in action. Ideally, you'd like to put DirXML 1.1a to work on your own network and use it immediately to solve a real problem. This allows you to determine for yourself whether this technology is as great as Novell seems to think and, by extension, whether a full-scale DirXML 1.1a deployment is worth the effort. The question is, how can you experience DirXML 1.1a without investing a lot of time?
The answer is by upgrading to NetWare 6.5, which entitles you to DirXML Starter Pack. You can deploy DirXML Starter Pack with relative ease in a lab environment and, from there, observe, test and train on DirXML to ease the transition to a fullscale DirXML 1.1a deployment.
The bottom line is that by taking one relatively small step to install and deploy DirXML Starter Pack, you take one giant leap toward building a complete data-sharing and synchronization solution.
The DirXML Basics
Novell DirXML, an award-winning data-sharing and synchronization product, works with your existing network infrastructure to automatically distribute new and updated information across hundreds of your directories, applications and databases. As a key component of the Novell Nsure secure identity management solution, DirXML enables you to simply update identity data in one system and, in so doing, instantly and automatically synchronize the identity data in all of your systems.
DirXML also enables you to dictate what data flows between systems and also control the direction that this data flows. This ability to control the direction of data flow enables you to both automate and preserve your existing business processes.
Your ability to control the direction of data flow between systems also enables you to designate which system is the authoritative source for specific data. For example, you can configure DirXML so that PeopleSoft is the authoritative source for employees' names, titles and IDs. As a result, DirXML ensures that PeopleSoft alone publishes this information, which flows only from PeopleSoft to eDirectory and, from there, to other systems, never vice versa. In other words, with DirXML, you can automate your business processes while ensuring that departments retain ownership of the data they currently manage and thus avoid the political problems that might otherwise arise.
You can also configure DirXML so that systems exchange information bi-directionally and are thus equally responsible for updating data. When systems participate in this type of DirXML configuration, DirXML publishes to eDirectory any data that is updated on any one of the systems. Once eDirectory is updated, DirXML pushes the updates through to other systems participating in this configuration.
The fact that DirXML securely and automatically shares data across all of your systems is impressive but is not the limit of the DirXML potential. What comes closer to this limit is the fact that DirXML can trigger automated and complex workflow processes. For example, on the internal network at Novell, DirXML plays a critical role in enabling the internal identity management solution. This solution ensures that with the creation of a new account in PeopleSoft, all other systems, including a workflow system, are automatically updated. The end result is that with this single entry, new Novell employees have literally everything they need to be productive from the moment they step through the doors.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.