Novell's Workstation Manager-A First Step Toward Windows NT and NDS Coexistence

Access NT and NetWare networks through one user interface and directory tree

Four years have passed since Microsoft announced Cairo, and Windows NT still lacks a functional directory service--a centrally administered database of objects representing network resources. The upcoming NT 5.0 will include a directory service called Active Directory. However, Microsoft won't release NT 5.0 to manufacturing until early 1998 at the soonest, and a shakedown period is certain before network administrators commit to the new service.

In the meantime, technologies are emerging that can provide alternatives to a native NT directory service right now. One such alternative is a Novell product--Workstation Manager, part of an updated version of Novell's IntranetWare Client for Windows NT that was released in January. The Workstation Manager module lets you add NT systems to a Novell Directory Services (NDS) tree in a mixed NetWare and NT environment as shown in Screen 1. NDS is the popular NetWare-based directory service that stores information about network resources (e.g., users, groups, printers, and volumes) in a distributed database. Objects organized into a hierarchical tree design represent an entire enterprise network's resources. Workstation Manager expands the NetWare Administrator program's capabilities by letting you add a new type of object that represents an NT workstation to the NDS tree. (For information about installing and configuring IntranetWare Client for NT, see "Windows NT and NDS," March 1997).

NDS and NT
Many organizations rely on both NetWare and NT for network services. A typical example is a shop that uses NetWare for file and print services and NT application servers and workstations. But with this mixed environment comes the challenge of managing two different access control systems.

NT's domain-based system of access control provides only a directory service's most basic features, such as user groups and password protection, and is limited to use with Microsoft operating systems. NetWare has the most widely deployed directory service in the industry, with more than 17 million sites running NDS. NDS supports clients running on DOS and all the Windows platforms as well as UNIX and Macintosh systems. NDS gives users an expandable view of an enterprise network through one user interface (UI), supporting a virtually unlimited number of clients and servers. NDS contains configuration data for many types of network resources in a database that can be distributed among NetWare servers around the office or around the world.

Unlike the other operating systems that NDS supports, however, NT requires an authenticated logon, even for local system access. With Workstation Manager, you can now use NDS to manage and store the information needed to perform this logon.

Novell Workstation Manager eliminates the need to manually create user accounts on NT 3.51 and 4.0 workstations running Novell's client for NetWare. NDS stores all the necessary user information and dynamically creates accounts during the logon process.

To accomplish this automation, Workstation Manager lets network administrators create NDS tree objects that represent NT machines. The NDS database on your NetWare servers stores these objects, which are configured with the account information needed to perform the NT system logon. The objects are then associated with specific NDS users so that when a user logs on to the NDS tree from an NT system, an account is automatically created on the NT workstation, using the credentials stored in the NDS database. Workstation Manager also supports remote client configuration, roaming user profiles, system policies, and NT user groups.

Workstation Manager's purpose is not to completely resolve the problem of integrating NT with NetWare but to simplify using NT as a client operating system on NetWare networks. If you use NT domains to store account information for your users, Workstation Manager may not be helpful because it does nothing to manage user and group access to NT domain servers.

Another product, Novell Administrator for NT (formerly code-named Tabasco), addresses the problem of assimilating NT domains into NDS. This product is a NetWare Administrator module that synchronizes NT user and group information in the NDS database. Sometime this year, Novell plans to release a full port of NDS to NT. This port will eliminate the need for NetWare servers to store the NDS database.

Despite these drawbacks, Workstation Manager is a significant first step toward the use of NDS as a complete enterprise directory services solution. Workstation Manager can be especially useful for NetWare sites with many NT desktops where administrators routinely travel to each system to create user accounts or use NT domains solely for centralized account management.

Installing Workstation Manager
To obtain Workstation Manager, you must download IntranetWare Client for Windows NT, which is available for free from

Workstation Manager consists of two parts. One is an updated version of the NetWare Graphical Identification and Authentication module (NWGINA) that replaces the Microsoft GINA on the NT system. NWGINA controls the functions of the logon dialog box that appears when you boot the system.

The other part of Workstation Manager consists of snap-in modules. These modules extend the NDS database's schema to let a network administrator create and manage NT Client Configuration objects (more about these later).

The IntranetWare Client's automated setup procedures install both modules. The IntranetWare package includes a setupnw.exe program, which installs the client software (including NWGINA) on the NT system, and an admsetup.exe program, which installs NT versions of the NetWare administration utilities (including the new snap-in modules) to the SYS volume on the NetWare server.

setupnw.exe installs the IntranetWare client software to an NT workstation, replacing any NetWare client that's already installed. To install Workstation Manager and activate the NWGINA module, which creates the dynamic user accounts on the NT system, you must run the setupnw.exe module with the /W switch. Include the name of your NDS tree, as follows:

SETUPNW.EXE /W:treename

The switch specifies the name of the NDS tree in which the new objects will be created.

After you run setupnw.exe, you must make the necessary changes to the NT Registry. Novell provides these settings in a file called workman.reg; to apply them to the Registry's HKEY_URRENT_USER hive, you simply double-click the file in NT Explorer or File Manager. These additional installation procedures are necessary because the new NWGINA module must run with Administrator privileges in order to create the dynamic user accounts on the NT machine.

The new version of the admsetup.exe program includes the Workstation Manager Administration Module as an installation option with the NetWare Administrator and Novell Application Launcher programs, as you see in Screen 2. When you select this option, admsetup.exe copies the new snap-in modules to the NetWare server, where they will be accessed the next time you run the NetWare Administrator utility.

One of NDS's primary strengths is that you can modify its schema (guidelines that define the types of objects that you can create in a directory service, the objects' attributes, and how they interact with other object types). NetWare Administrator, the program that uses the schema to create and manage NDS objects, can access special Windows DLLs called snap-in modules that extend the schema by providing new object type definitions. Although Novell provides the snap-in modules for Workstation Manager, third-party developers can also create snap-in modules that define new NDS object types.

Creating NT Client Configuration Objects
After you've installed the schema extensions by running admsetup.exe from an NT system, you'll find that when you run NetWare Administrator, you can create NT Client Configuration objects. These objects represent your NT workstations in the NDS tree and store information used to create NT user accounts. A Registry key stored in the HKEY_CURRENT_USER hive of the system on which you installed Workstation Manager references the snap-in modules that let NetWare Administrator create NT Client Configuration objects. If you want to manage the Client Configuration objects from another NT system, you must either install the snap-in modules on that machine by running admsetup.exe again or use a roaming user profile to store your Registry settings on a network drive. (For information about roaming profiles, see "Common Windows NT Problems," April 1997.)

You create NT Client Configuration objects in the NDS tree just as you create other types of objects. By assigning values to the object's parameters, you can remotely configure an NT workstation's NetWare client and determine how the local NT user account will be created on the system during an NDS logon. When you enable the dynamic local user feature (which enables the client to automatically create user accounts as needed), you can choose to create NT accounts with the user's NetWare credentials, or you can specify a username. Screen 3 shows the Dynamic Local User configuration screen. When the NWGINA module creates the user account, NWGINA assigns it a random password and makes the user a member of the NT groups you select.

Depending on your users' access patterns, you can configure the NWGINA module to create permanent user accounts or volatile ones, which the system deletes when the user logs off. If you have many users accessing one machine, using volatile accounts can prevent an unwieldy buildup of accounts in the Registry.

After you've created an NT Client Configuration object, you associate it with one or more NDS users. This association triggers the NT account creation during logon. When the logon process begins, the user is always authenticated to the NDS tree first. Once NetWare grants the user access, the NWGINA module reads the NT Client Configuration object and uses its parameters to determine the NT username. NWGINA then checks NT's Security Accounts Manager (SAM) to see whether that user name already exists on the system. If not, NWGINA creates a new account and the NT logon proceeds. At the end of the process, the user has access to both NetWare and NT networks with one username and password. Figure 1 summarizes the logon process.

Workstation Manager lets a network administrator shift much of the NT workstation security and client maintenance activity to NDS. In fact, you can configure the IntranetWare client to deny all access to the NT system unless an NDS logon is completed successfully. However, if you don't enable this feature, Workstation Manager won't interfere with normal NT operations. You can still create user accounts manually and disable dynamic local-user account creation simply by removing the NDS user object association or logging on with a different NDS account.

Configuring a Remote Client
Even without the dynamic local user feature, Workstation Manager lets you create InternetWare Client configurations on one workstation that you can apply to NT workstations throughout the enterprise. By modifying the parameters of NT Client Configuration objects, you can alter most of the client settings that you'd typically have to change on each NT system being configured. You can control the execution of user and profile logon scripts, specify the names of alternative script files, and change how the NWGINA appears to your users by specifying a bitmap of your choice and suppressing the display of specific screens in the logon dialog box.

All of Novell's IntranetWare clients have an Automatic Client Upgrade (ACU) feature that compares the installed version of the Novell client with the source files on a network drive. IntranetWare performs the software upgrade only when the source files are newer than the installed version. When you use this feature with dynamic local users on NT, however, a problem arises. Unlike with Windows 3.1 or Windows 95, you must log on to NT with administrator privileges before you can upgrade the client software.

Because the user accounts that Workstation Manager creates ordinarily don't have administrator privileges, the Client Configuration object includes a special setting. When enabled, this setting causes NWGINA to compare the timestamp of the configuration object during the current logon with that of the previous logon.

When the timestamps differ, the discrepancy signifies that an administrator has modified the object. NWGINA performs a logon with administrator rights and executes a special logon script that launches the upgrade procedure.

After the upgrade, you must restart the system. This time, the object timestamps are the same and the normal logon procedure occurs. This way, you can deploy a client software upgrade to all your NT workstations automatically, without traveling to each machine or violating security procedures.

Roaming Users and System Profiles
Because Workstation Manager is only a mechanism for creating user accounts on your NT machines and stores the account information in the NT Registry (not in the NDS database), you can associate one NT Client Configuration object with multiple users and have the object service multiple NT workstations. This capability exists even when you use NT features such as roaming user profiles or system policy files.

User profiles are collections of NT Registry settings that define the desktop environment for a specific user. These settings control different elements of the UI--such as desktop icons, wallpaper, and configuration of the Start menu--that are unique to each NT user. If you store a user's profile on a network drive (creating a roaming profile), that user can log on from any NT machine and work with the same personalized configuration. (For more information about roaming profiles, see Rodger Seabourne et al., "Common Windows NT Problems," April 1997.)

System policies are another way to store Registry settings, but these settings apply to the computer, not the specific user. The network administrator usually creates policies as a way to limit users' access to certain parts of the operating system. (For more information about system policies, see Robert Slifka, "How to Edit NT 4.0 System Policies," February 1997, and Sean Daily, "Further Explorations of the NT System Policies Editor," April 1997.)

Creating dynamic local user accounts with Workstation Manager complicates the use of roaming profiles and system policies but doesn't prevent them. You can configure an NT Client Configuration object to access profile and policy files from specific locations on the network, as Screen 4 shows. Because the user profile format is different in NT 3.51 and 4.0, the configuration screen provides fields for separate path names to accommodate multiple workstations running different operating system versions.

When you create one object to represent multiple workstations, specifying the path to one file isn't practical when each user maintains a unique profile. Thus, to accommodate multiple roaming users with one configuration, you select the Relative to Home Directory check box and enter the path to a network directory, instead of a file. Then you create subdirectories named for your users under the specified directory and store their user profiles there. For example, entering the path sys:users stores user JSMITH's profile in the sys:users\jsmith directory. By controlling users' access rights to these directories, you can enforce the use of a specific profile or let users change their profile.

Future Developments
Novell Workstation Manager provides a useful solution for NetWare networks that include NT as a desktop operating system. Storing client configuration settings in the NDS database preserves the capabilities of both the IntranetWare Client and NT while eliminating the need for administrators to perform account maintenance and client configuration tasks at individual workstations.

Using NDS as an enterprise directory service has several advantages, especially its immediate availability. Because of NDS's integration with NetWare, many sites already have NDS installed, though they may not be taking full advantage of its capabilities.

NDS has also had several years of development and debugging under working conditions; it's a stable, reliable directory service. Many upgrades and patches have made NDS what it is today, and the same will probably be true for any directory services released in the future.

Novell is now concentrating on expanding NDS's capabilities. Future articles will examine Novell products that more fully integrate NT networks into NDS. For example, the Novell Administrator product lets you manage NT server domain accounts with NetWare network accounts. Ultimately, with a Novell product now in development, you'll be able to use NDS on an NT network without running NetWare at all.

Other vendors' directory services are in development. Also in development are standards such as the Lightweight Directory Access Protocol (LDAP) that are designed to facilitate directory service connections over intranet and Internet links. However, if you need a solution now, NDS fits the bill.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.