Synchronicity Professional 3.0

Synchronicity provides directory integration for multiplatform networks

When your organization runs multiple OSs, juggling platform-specific accounts can make you feel as if you're running in circles. Single-point-of-administration tools can simplify life for you and for users (who must otherwise remember different passwords for each platform). NetVision's Synchronicity suite of directory-integration products are Novell NetWare—centric programs that work with NetWare 4.1 or later and help you integrate multiple directory services under a central administrative interface. You'll find the programs especially handy if you're an experienced NetWare administrator who also needs to manage Windows 2000 or Windows NT 4.0.

Basic Architecture
The products' free standard versions provide components that turn NetWare Administrator into a central point for creating and managing various platform-specific accounts. Synchronicity for Active Directory deals with Win2K Active Directory (AD) user and group accounts; Synchronicity for NT works with NT user and group accounts. These two products let you use existing Novell Directory Services (NDS) user or group accounts as templates to create corresponding Win2K or NT user or group accounts. Synchronicity for Exchange lets you manage Microsoft Exchange Server mailboxes and distribution groups. Synchronicity for Notes helps you work with Lotus Notes accounts, and Synchronicity for NetWare 3 lets you easily integrate NetWare 3.0 bindery accounts with NetWare 4.1 or later.

Each product's professional version includes the Synchronicity Password Monitor, which lets you synchronize NDS-based passwords and other directory attributes with the product-specified platform. Synchronicity Professional products are also free, but to use these versions, you must purchase a maintenance agreement (which includes product upgrades and technical support) for each product at a cost of $5 for each NDS user account you plan to synchronize. (The products come with the Synchronicity License Auditor utility, which can help you determine your licensing requirements.)

To work its magic, Synchronicity uses three primary components: Global Event Services (GES), synchronization agents, and NetWare Administrator snap-ins. These components work together to track and synchronize changes that occur in your network's various directories.

GES. GES is a NetWare loadable module (NLM) that runs on one or more NetWare servers that hold read/write NDS replicas. GES tracks directory changes that originate on any platform, then relays these changes to registered synchronization agents on other servers in your network. You can configure GES to filter events and forward subset of NDS changes to these agents.

GES uses one of three available security levels to authenticate requests for directory access or updates. Security Level 1 resolves clients' NDS distinguished names (DNs) at logon. Security Level 2 provides authentication when a client first issues a request for a GES-brokered service; that authentication is valid until the client logs off. Security Level 3 provides the same initial authentication as Level 2 and confirms rights at every subsequent request for GES-brokered services. Level 2 is the default, but you can change the level through NetWare Administrator.

Synchronization agents. Each Synchronicity product uses a specific synchronization agent, which registers with GES to receive notification of account or password changes, then implements those changes in the directory service for which you configured the agent. For example, Sychronicity for Active Directory and Synchronicity for NT install services—the Synchronicity for Active Directory Agent service and the Synchronicity for NT Agent service, respectively—on any domain member system that runs the appropriate OS (i.e., Win2K or NT). These services receive data from GES and make necessary updates to their respective databases.

NetWare Administrator snap-ins. Each product also installs a NetWare Administrator snap-in. These snap-ins let you centrally manage other directory-specific objects from within NetWare Administrator.

Synchronicity Password Monitor
The Password Monitor program, which you install on your Win2K or NT domain controllers (DCs), detects all changes to user passwords and forwards the changes to GES through the respective agent service. GES distributes the update to any other GES brokers connected to other Synchronicity products and other synchronized accounts (e.g., an AD account). This architecture lets Synchronicity propagate password updates that originate in Win2K, NT, or NetWare to linked accounts in the other account database structures. (Synchronicity products also include several other Password Utilities, but these are relics of earlier Synchronicity versions.)

Win2K, NT, and NetWare store passwords internally in an encrypted format. To synchronize a password across different formats without compromising security, Synchronicity intercepts, reads, and encrypts the password before synchronizing it across linked accounts. However, the product can't intercept passwords from a few password-change methods, including the NetWare SETPASS utility. Supported password-change methods include the Novell Client for Windows NT/2000's Change Password function and the Synchronicity NetWare Administrator Password Synchronization snap-in.

Putting Synchronicity to the Test
The Synchronicity CD-ROM contains both the standard and professional versions of all the products; you can also download the products from the vendor's Web site. I first installed Synchronicity from CD-ROM but then downloaded an updated version—Synchronicity Professional 3.0 Release 2 build 438. For this review, I tested three products: Synchronicity Professional for Active Directory, Synchronicity Professional for NT, and Synchronicity for Exchange.

I set up a multi-OS test network consisting of five computers. For my NetWare server, I used an 850MHz dual—Pentium III server with 512MB of SDRAM running NetWare 5.1 with Support Pack 2A.

I then set up two Win2K machines. I configured a 450MHz Pentium II server with 256MB of SDRAM, running Win2K Server with Service Pack 1 (SP1), as a DC. For a Win2K client machine, I used a 200MHz Pentium Pro machine with 128MB of SDRAM running Win2K Professional. I installed Novell Client for Windows NT/2000 4.8 and configured the system to use IP to communicate with the NetWare 5.1 server.

For my NT server, I used a 533MHz Celeron system with 128MB of SDRAM running NT 4.0 with SP6a; I configured this server as a PDC and installed Novell Client for Windows NT/2000 4.8. For an NT member server, I used a 600MHz Celeron machine with 128MB of SDRAM running NT 4.0 with SP6a. On this server, I installed Novell Client for Windows NT/2000 4.8, Microsoft Exchange Administrator, and Exchange Server 5.5; I configured the machine to use IPX to communicate with the NetWare 5.1 server.

For Synchronicity to synchronize account information between NDS and a Win2K or NT domain, you must install the product on a computer that's a member of the domain. Synchronicity for Exchange further requires that you install the product on the same computer as Exchange Administrator. I first in-stalled Synchronicity for NT and Synchronicity for Exchange on my NT 4.0 member server.

At the InstallShield Wizard's module-selection screen, which Figure 1 shows, I selected four components: Synchronicity for Exchange, Synchronicity for NT, Synchronicity Password Utilities, and NLM File Installation for NDS Servers. The installation process installed Microsoft Data Access Components (MDAC) 2.5 and copied product files to the system. I then needed to reboot. When I logged on after the reboot, the installation process displayed a summary of upcoming installation steps.

The wizard asked me to select the NDS tree with which I wanted to synchronize NT. I had already configured Novell Client for Windows NT/2000 to log on to my NetWare 5.1 server, so I could and did select the tree for that server. The installation program prompted me to confirm my selection, then made the necessary NDS schema changes to support the NDS objects that Synchronicity needed to add.

Next, the installation program asked me to select the servers on which I wanted to install Synchronicity's NetWare Administrator snap-ins. I selected my NetWare server. The installation program then asked me to select a server on which to install the Synchronicity NLMs; again, I selected my NetWare server.

Next, the wizard began installing GES. The installation process copied the necessary Synchronicity NLM files to the NetWare server. The program then gave me the option to immediately load the GES NLM and to update autoexec.ncf so that the GES NLM would load each time the server rebooted. I accepted both options.

I could load GES in one of three modes. Mode 1 requires installation of GES on all servers that contain an NDS master or read/write replica. This mode supports immediate updates to all NDS replicas. Mode 2 relies on NetWare's NDS synchronization services and permits installation of GES on as few as one NetWare server containing a master or read/write replica of the NDS partitions to be synchronized. Mode 3 is similar to Mode 2 but doesn't distribute updates to other GES brokers on other servers. This mode lets you confine updates to a locally maintained NDS partition and thus avoid unnecessary WAN traffic that can result from replicating changes to unused partitions at other sites. Because I had only one NetWare server in my test bed, I accepted the default (and recommended) Mode 1.

The process then asked me to enter product license strings. Without these licenses, the products will expire after 30 days. (You can enter the license information later from NetWare Administrator.) I pasted in the license strings that NetVision had provided.

The next step involved configuring the agent service and related NDS object for each product I wanted to install. First, the program displayed my computer's NT domain name and asked me to select an NDS container to hold Synchronicity's NT domain object. Next, the program prompted me to configure the Synchronicity for Exchange Agent service. I needed to enter a name for the NDS object that would represent the Exchange Server organization (the agent also uses this object), a service account and password, and the name of the NDS container that I wanted to hold the NDS object. I used the same name for the Exchange Server organization and its corresponding NDS object, and I selected the same NDS container that I had chosen to hold the NT domain object.

The setup instructions in the Synchronicity Overview and Installation Guide (which you can download from the product's Web site) instructed me to add the Log on as a service user right to the newly created Synchronicity service account (i.e., SyNT_Service_Account) in my NT domain. I followed this instruction. At first, however, the Synchronicity for Exchange Agent service failed to start. By default, this service runs under the local system account. The agent service started successfully after I reconfigured it to run under a Domain Administrator account that had Service Account Admin role permissions for Exchange Server organization, site, and configuration containers.

Next, I installed Synchronicity Password Monitor on my PDC. I needed to reboot the PDC to complete Password Monitor installation.

My next step was to install Synchronicity for Active Directory on my Win2K DC. The process was similar to the installation of the NT and Exchange products: I selected the same NDS tree, NetWare server, and NDS container. I didn't need to reenter the license keys because the installation process automatically located them on the NetWare server.

The Synchronicity for Active Directory installation process automatically updates the AD schema when you install the product on a DC. (When you install the product on a server that isn't a DC, you must run a separate NetVision schema-update program on the DC to change the schema.) Although the presence of the Synchronicity-specific attributes is probably benign, you can't remove these schema modifications from AD should you decide to stop using Synchronicity in the future. I rebooted the DC to finalize installation.

Testing Integration Capabilities
To test Synchronicity for Active Directory, I first used the program to create an equivalent account in AD for an existing NDS account—a process that NetVision calls integration. The Synchronicity for Active Directory snap-in, which I found under the NetWare Administrator's Tools menu on my Win2K Pro machine, gave me the option to Integrate NDS Users and Groups with Active Directory. I selected the NDS User ID for the account I wanted to integrate and the AD tree and container that would hold the new object. Synchronicity then displayed a Naming Rules dialog box, which Figure 2 shows. This dialog box presents options that determine how Synchronicity will create new AD objects and update existing AD objects. You can also select one of several rules for Synchronicity to follow when it matches an NDS object and an existing AD object. After Synchronicity matches these objects, it links them so that future synchronization of equivalent directory attributes occurs automatically.

Next, the NDS to Active Directory Integration — Select Options dialog box, which Figure 3, page 83, shows, offered several password options for the new AD user account. When you integrate an AD group account, this dialog box lets you select the scope (i.e., Domain Local, Global, or Universal) and type (i.e., Security or Distribution) of the account object that Synchronicity creates for the corresponding NDS group. I integrated several users; to confirm that the new AD accounts functioned, I used each account to log on and change the account password.

Now I was ready for a more ambitious test: I decided to simultaneously integrate all but a few users and groups in the NDS organizational unit (OU) that I'd configured to synchronize with users and groups in my domain's AD. The integration produced the desired results. Several of the NDS users were also members of an NDS group. Synchronicity created corresponding AD user accounts that were also part of a new corresponding AD user group. The program didn't create new AD user accounts for the NDS group members I didn't select for integration, nor did it include them in the AD user group.

To test Synchronicity's password capabilities, I used NT User Manager for Domains, the Win2K Microsoft Management Console (MMC) Active Directory Users and Groups snap-in, NetWare Administrator, and Novell Client for Windows NT/2000 to make password changes. In each case, the products successfully synchronized the password updates, and I could use the new passwords to log on to member servers in each domain. The only failures occurred when I used the NetWare SETPASS utility to change an NDS account password. I contacted a NetVision technical support person, who explained that Synchronicity can't detect changes you make through that utility.

To test Synchronicity for Exchange, I first used an NDS user account as a template to create an Exchange Server mailbox. The vendor refers to this process as NDS-to-Exchange integration. I opened the Integrate NDS Users and Groups with Exchange snap-in under the NetWare Administrator's Tools menu on my NT 4.0 member server. I selected an NDS user account, my Exchange Server organization, a Recipient container, and an NT domain to host the user account and authenticate mailbox access. The NDS to Exchange Integration — Select Options dialog box, which Figure 4 shows, presented options for creating mailboxes that link to existing NDS users and groups, let me choose renaming options for duplicate mailbox or group names, and asked for the path to the integration log file. After integration, I opened Exchange Administrator and verified that Synchronicity had successfully created the account.

For my final test, I integrated several NDS user and group accounts simultaneously. Synchronicity had little difficulty creating corresponding user and distribution group objects in Exchange Server. However, the Synchronicity NetWare Administrator snap-in didn't provide the ability to view or change permissions when I used the snap-in to view the attributes of an Exchange Server mailbox. (The default permissions are usually sufficient, so I didn't consider this lack of ability to be a problem.)

The Synchronicity products that I tested installed easily, performed as advertised, and seemed to require little maintenance after initial implementation. At $5 per synchronized NDS user account, the products are reasonably priced and would be valuable for IT shops that need to support both NetWare and Win2K or NT users.