[an error occurred while processing this directive]
Windows NT and 2000 servers are sometimes a necessary evil in a NetWare environment. Fortunately, Novell has had the Novell Account Management product available for several years to ease the burden of maintaining user accounts between NDS and Windows servers. Account Management provides the tools necessary to synchronize user accounts between NDS and Windows, Unix or MVS servers.
The primary purpose of using a product such as Novell Account Management is to cut down on the amount of "hands-on" administration you must perform on differing network platforms. For example, in a mixed NetWare and Windows server environment, if you don't have a product such as Account manager, whenever you create a new user in one server platform, you then have to do the same (usually) on the other platform. By using Account Management you only have to create the user once in NDS, and then NAM takes care of duplicating the user information on the Windows server along with their NetWare password.
As you know, NDS has been proven and mature for many years, and now, finally, Microsoft's directory services offering, Active Directory, is finally moving in the right direction. Many of us, though, with only a single Windows server hosting a few services, have seen little if no reason to make the change from the NT Domain system to Active Directory. Unfortunately, with the 3.0 upgrade to Novell Account Manager, the synchronization process coordinates better between NDS and Active Directory rather than the older NT Domain structure. This article documents the process I worked through in order to properly synchronize users from our eDirectory 8.7 NetWare network with a Windows 2000 server using NT Domains.
In order to make the process as simple as possible, I decided to use membership in an NDS Group object as the "trigger" for synchronization. One reason was to properly track the license count for NAM users – we purchased 10 licenses because only few people need file-level access to the Windows 2000 server. Another reason is that by granting access rights to a Windows server by Group association rather than by Organizational Unit, you simplify the NDS management of users who may need to access the Windows server.
In any NAM installation, setting up the Census is critical to getting User and Group objects to replicate between eDirectory and Windows NT/2000. The Census is the list of NDS objects (Users and Groups) that will be synchronized to the Windows server.
Create an eDirectory Group to Coordinate user accounts
Using ConsoleOne, create a Group object in your NDS tree. Use a name that is different from any other Group name that currently exists in the NDS tree. This is to minimize potential name conflicts when NDS objects with the same name (but different contexts in the tree) become members of the Census. You have the option to name the NDS Group the same as an NT Domain group, at which point Account Management will synchronize the two same-named groups.
The advantage to having an NDS Group name that is different from the NT Domain Group is that if this group gets deleted from your NDS tree, it won't delete the corresponding Group on the Windows server. You can also modify the value of the Inactive Enterprise User Actions under the Census configuration to define how many days after an NDS object is deleted that the corresponding platform object gets deleted.
Create a NAM search object pointing at the eDirectory Group to create eUser objects
This object will allow for the management (creating, deletion, modification, etc) of user accounts on the Windows server. Use the following options when creating this Search object:
Create a NAM search object pointing above the Group level to create eGroup objects
This object will allow for the management (creating, deletion, modification, etc) of Group accounts on the Windows server. Use the following options when creating this Search object:
Perform a Trawl to make sure objects are getting replicated to the Windows Server
Once the search objects have been created and tied to the correct platform sets, you should run a Trawl to start the replication process from NDS to the NT/2000 server. The purpose of the Trawl is to refresh the Census list, removing outdated objects and verifying that all current Census members are correct.
Once the Trawl is complete, there are two different places to visit in Account Management to make sure that the NDS objects have been replicated properly, the first is the Log Viewer. The Log Viewer will show you the creation of NAM eObjects based on the contents of your NDS tree and the Search Objects.
The second place to check is the Provisioning Details for Active users and Groups. This will show you the eObjects that are created (both eUser and eGroup) and, by drilling down through the object information, show you if they have been associated with the platform correctly.
Modify the Windows Platform Receiver scripts
The management of NDS objects on the Windows server is carried out by the Platform Receiver scripts. These files are the same as any other Windows script file, they're written in a language similar to Visual Basic, and executed by the Windows Script Host. Typical Windows scripts are executed by simply running them from Windows Explorer or the command-line script host. The Account Management Platform Receiver Scripts are also run by the Windows Script Host, but instead of manually selecting them from Explorer, the Platform Receiver Service watches for LDAP events and then executes the various scripts based on the LDAP event triggers.
Locate and modify the AddToGroup script
Windows Platform Receiver Scripts are located in the following directory on your Windows server:
There are many script files in this directory, but the AddToGroup script specifically deals with the process of taking a user name and associating it with a specific NT Domain or Active Directory group. The code for this script is broken down into 4 sections:
This four-part pattern is pretty consistent in the majority of the script files. In general, we're going to "tap in" to the third section by seeing which Group name is passed into the script.
Clean up the script file debug settings
Before we add any new code to the AddToGroup script file, we need to make sure we can properly provide debugging information. Debugging the NAM receiver scripts is an arcane process at best - unlike "normal" Windows script debugging where you can output variables to a window, the Account Management debug output is sent to a log file. Novell TID #10077136 describes how to turn on debug mode for the various NAM modules, but the Platform Receiver Script code needs a "tweak" so that any new information you add for debugging can be properly output to the debug log file.
In the AddToGroup code, right before clearing the values of any defined variables in the Shutdown "section", there is a debug output statement that writes out container, user, and group path information to the log file, then closes the debug output file for writing.
The code isn't wrong, but it's poorly organized, so that if you were to add new code before the shutdown section, but after this IF statement, your debug statements would never get written to the log file. By moving the "d.close" statement to it's own IF statement before the Shutdown section you easily resolve this problem.
Add the new code for assigning NT Domain Group membership
The code you will add so that the NDS-replicated user objects are associates with your NT Domain groups is a simple copy from the existing "associate" code already present in the AddToGroup script file. The lines highlighted in the code below perform all the "work" that you will need.
First, create a new variable in the Startup section to hold the CommonName value of the NDS group that the useris added to. This will be necessary for you to perform an IF test to determine if this is a group we are watching.
Next, add the following code before the Shutdown section:
Here's the logic of the code above:
Download the zipped AddtoGroup.WSF (Windows Scripting File), to make copying of the samples above easier.
Now for the fun part! Go to the server where you're running NAM and shut down the platform receiver service from the services control panel. Next, follow the instructions from Novell TID #10077136 and open a Command Prompt window, navigate to the directory where the platform receive script executable code is located (it's usually C:\NOVELL\ASAM\), and run the receiver code with the debug switch.
Open ConsoleOne on a server or local workstation and add a user to the NDS Group that is being replicated to the NT Domain server. Depending on the amount of traffic between your servers, you should soon see an echoed prompt in the open DOS window of the Windows 2000 server that indicates the scripts are running. Once you've seen the prompt, then open the User and Group Manager and see if the user you added to the NDS group has also been associated with the NT Domain Group.
For additional help with Novell Account Management 3, check out the eDirectory-Windows support forum at http://support.novell.com/forums. During my deciphering of the Platform Receiver scripts I used the "Windows 2000 Scripting Guide" from Microsoft Press and the "Windows 2000 Scripting Bible" by William Stanek from Wiley Publishing.
My sincere thanks to Eric Stika of Novell's DirXML Team for his help during my rather lengthy tech support incident trying to get this whole thing figured out!