Since the release of Windows 2000 and Active Directory, administrators have had to support both the NetWare NDS directory platform as well as the newer Active Directory, despite the fact that the two have difficulty communicating with each other. Windows Services for NetWare 5 includes Microsoft Directory Synchronization Services (MSDSS), and File Migration Utility provides a two-way synchronization service that assists administrators in maintaining a central point of administration. In this Daily Drill Down, I’ll show you how to install and configure the Microsoft Directory Synchronization Services.
For the purposes of this Daily Drill Down, I’ll be running a NetWare 6 SP2 server, a Windows 2000 Server running Windows Services for NetWare 5, a Windows XP Professional workstation running Novell’s Novell Client 4.83 SP1, and a Windows XP Professional workstation without Novell client software. If you have other Services for NetWare products or programs that rely on Gateway Services for NetWare, you may have difficulty with MSDSS. It’s better to install this product on a fairly pristine system. Once installed, I’ve logged in to the Windows 2000 server as Administrator in Windows and .admin.slowe, where slowe is the name of my NDS organization.
Before you begin
Before you install MSDSS, there are some requirements you should be aware of. First, your Windows 2000 Server must be configured as a domain controller for the Windows domain for which you wish to enable synchronization with NDS. Second, you must install the Novell’s Client on this server—not Microsoft’s Novell client. Novell’s Client for Windows 2000 is available from the Novell web site. As of this writing, the latest version of the client is 4.83 SP1.
MSDSS also supports one-way synchronization of data between a Novell NetWare bindery and Active Directory. For this Daily Drill Down, I’ll only cover Active Directory and NDS synchronization.
Novell Client for Windows 2000
To find out more about Novell’s Client For Windows 2000, see the Daily Drill Down “Novell’s new client improves Windows XP connectivity.” The Novell Client works on Windows XP as well as Windows 2000.
With the Novell Client installation out of the way, it’s time to install MSDSS. Begin by inserting the Windows Services for NetWare 5 CD-ROM into the Windows 2000 domain controller’s CD-ROM drive. Navigate to the MSDSS folder on the CD-ROM and double-click the MSDSS.msi installation file.
Once you get past the license agreement, you’ll choose which product to install from Services for NetWare. Choose MSDSS and click Next. For this example, I chose Typical for a typical installation.
Once the files are copied, the installation program will ask to extend the Active Directory schema. Make sure that you’re logged in as a user with enough rights to make this change. If you aren’t, exit the installer, log out, and log back in as such a user. After Setup extends the schema, you must reboot the server. That’s all there is to the installation. From here I’ll focus on making the product work with your NDS tree.
MSDSS includes three synchronization options:
- Two-way synchronization—changes made in either Active Directory or NDS are automatically synchronized with the other directory service.
- One-way synchronization—this allows changes made in Active Directory to be synchronized back to NDS.
- One-time synchronization (migration)—this option is useful if you’re changing from a Novell bindery or NDS server completely to Active Directory and want to migrate your users to the new directory.
Configuring MSDSS for one-way synchronization
Configuring MSDSS for one-way synchronization allows an administrator to use the Active Directory tools as a central point for user administration. Changes made in Active Directory are replicated to NDS, but the reverse is not true. This could be useful when an organization is working to migrate users from Novell products to Microsoft systems.
Before one-way synchronization can work, Active Directory needs to know what objects already exist in NDS, as well as some information about their attributes. This is done through a process called the initial reverse synchronization. I’ll discuss this in greater detail later on.
After installing MSDSS and rebooting your server, go to Start | Programs | Administrative Tools | Directory Synchronization. To begin a one-way synchronization, right-click MSDSS and click New Session to open the New Session Wizard. The first step, shown in Figure A, asks what kind of synchronization you wish to perform. For this example, I’ll choose One-Way Synchronization.
|Choose your sync type.|
On the Active Directory Container And Domain Controller screen shown in Figure B, you must tell MSDSS which Active Directory containers you’d like to use to synchronize NDS. You can either type in the container name using LDAP syntax, or you can click the Browse button to find the container. For my example, the LDAP syntax for my entire domain is LDAP://lab2kd.com/DC=lab2kd,DC=com. The Domain Controller field indicates which domain controller will be responsible for handling synchronization. Be careful to choose a reliable server because it will be a single point of failure.
|Choose the appropriate Active Directory container and replication server.|
Choosing the NDS container on the NDS Container And Password screen shown in Figure C can be an exercise in frustration. In my installation, which I attempted with various Windows 2000 Server configurations, I was unable to use the Browse button to choose the NDS container that I wanted to synchronize. Using Novell’s typical syntax for locating NDS objects didn’t work any better. Instead, in order to synchronize my entire NDS tree named slowe, I had to manually enter the NDS path of NDS://slowe/O=slowe and supply NDS credentials to make it work.
|The NDS path is not a straightforward Novell syntax if you’re used to NetWare.|
The Initial Reverse Synchronization page shown in Figure D asks you to make some decisions regarding initial reverse synchronization. In order to be able to properly synchronize NDS objects with their Active Directory counterparts, AD needs to have information on what already exists in NDS. This helps to avoid problems with duplicates and such. In most cases, you shouldn’t skip this step. Perhaps the only time you should skip this step is if you have a pristine NDS tree with no new objects.
|Reverse synchronization options.|
This page also has a button marked Password Options. Unfortunately, passwords can’t be synchronized between the directories, so you need to determine a way to handle them. You have four choices for handling passwords. The first two are to set them as blank or as the user name, neither of which I’d recommend if you’re serious about security. Your third choice is to allow the utility to generate them randomly, in which case it will create a log file listing the new passwords. And finally, you can set them to a specific value. For this example, I’ve chosen to set them to a random value.
Step five of the wizard, the Object Mapping Scheme screen shown in Figure E, provides you with a mechanism by which to map objects between directories. For example, if you have containers in both directories that have the same users but different names, this is where you’ll enter it in the wizard. For this example, I’m going to use the default object mapping, which assumes that the naming between directories is identical. I also had trouble with the NDS Browse button on this screen. For object mappings here, you may need to type the NDS path to the object.
|Object mapping options|
Everything needs a name, including your synchronization session. The sixth step of the wizard, the Session Name screen, provides a place for this information. Enter the name in the Session Name field, as shown in Figure F.
|Naming the synchronization session|
The final screen in the wizard just outlines the choices previously made. Clicking the Finish button completes the wizard, at which point the reverse synchronization is performed. Depending on the number of objects in NDS, this can take a few seconds or much longer.
When completed, clicking View Log shows the details of the process. This brings up an Event Viewer showing just MSDSS details. One of the events holds a file name that stores the passwords that were randomly generated upon synchronization. Access to this file is restricted to Administrators. When everything is finally finished, MSDSS has a session listed on the management screen, as shown in Figure G.
|MSDSS reports the status of the session.|
The real power of MSDSS comes to light in two-way synchronization. Two-way synchronization allows you to use management tools from either directory. If you prefer working with NetWare Administrator and don’t like Active Directory Users And Computers, you can create all of your users in NetWare Administrator. The two-way synchronization in MSDSS will then replicate the changes to Active Directory automatically. If another network administrator in your organization makes a subsequent change using Active Directory Users And Computers, that change will appear later in NetWare Administrator.
When working with two-way synchronization, you need to know two different terms: Forward Synchronization and Reverse Synchronization. Forward Synchronization stands for data going from Active Directory to NDS. Reverse Synchronization refers to data that originates in NDS and is replicated to Active Directory.
The process is the same as it was for the one-way synchronization, except for two differences. First, on the Synchronization And Migration Tasks screen shown in Figure A, you must choose Two-Way Synchronization. Next, when the Object Mapping Scheme window shown in Figure E appears, you’ll probably want to click Custom and specify how to map up objects between the two disparate directory systems. You also may want to click Filter to select the exact object types to synchronize, as shown in Figure H.
|You can set filters to replicate only selected object types.|
The first time you create a two-way synchronization session, MSDSS informs you that the NDS schema needs to be updated to support this process. If you allow this to take place, two-way synchronization will be enabled after the NDS schema is extended. If you cancel the procedure, a one-way Active Directory to NDS synchronization session will be created instead, even if you selected two-way synchronization.
Once the session is active, objects created in either directory will be replicated to the other. Upon completion of both forward and reverse replication, it’s easy to see if these objects are being properly replicated. Opening Active Directory Users and Computers yields the result in Figure I, showing the replication from NDS to Active Directory. As a test, I’ve created an account in NDS called NDS User and an account in Active Directory called Another AD User.
|The NDS User user exists in ADUC|
Likewise, opening up NetWare Administrator shows that the user Another AD User does indeed exist, thus showing that replication from AD to NDS is also working.
Once a synchronization session is established, you can control the times at which replication takes place and change other options for the session by right-clicking the session name in MSDSS and choosing Properties. The properties page gives you a place to adjust the level of logging information as well as a place to schedule when both forward and reverse synchronization will take place.
One big happy family
Just because you run both Windows 2000 and NetWare on your network, you don’t have to go crazy administering two different directories. As a part of Windows Services for NetWare 5, MSDSS gives administrators an excellent tool in keeping directories synchronized and helping to avoid the double duty of creating users separately for each.