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

Workstation Manager, a new module in Novell's IntranetWare Client for Windows NT, gives you one logon to NetWare and NT networks and lets you access NT objects via an NDS tree.

Craig Zacker

April 30, 1997

13 Min Read
ITPro Today logo in a gray background | ITPro Today

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--acentrally administered database of objects representing network resources. The upcoming NT 5.0 will include a directoryservice called Active Directory. However, Microsoft won't release NT 5.0 to manufacturing until early 1998 at thesoonest, 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 rightnow. One such alternative is a Novell product--Workstation Manager, part of an updated version of Novell's IntranetWareClient for Windows NT that was released in January. The Workstation Manager module lets you add NT systems to a NovellDirectory Services (NDS) tree in a mixed NetWare and NT environment as shown in Screen 1. NDS is the popularNetWare-based directory service that stores information about network resources (e.g., users, groups, printers, andvolumes) in a distributed database. Objects organized into a hierarchical tree design represent an entire enterprisenetwork's resources. Workstation Manager expands the NetWare Administrator program's capabilities by letting you add anew type of object that represents an NT workstation to the NDS tree. (For information about installing and configuringIntranetWare 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 NetWarefor file and print services and NT application servers and workstations. But with this mixed environment comes thechallenge 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 usergroups and password protection, and is limited to use with Microsoft operating systems. NetWare has the most widelydeployed directory service in the industry, with more than 17 million sites running NDS. NDS supports clients running onDOS and all the Windows platforms as well as UNIX and Macintosh systems. NDS gives users an expandable view of anenterprise network through one user interface (UI), supporting a virtually unlimited number of clients and servers. NDScontains configuration data for many types of network resources in a database that can be distributed among NetWareservers around the office or around the world.

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

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

To accomplish this automation, Workstation Manager lets network administrators create NDS tree objects thatrepresent NT machines. The NDS database on your NetWare servers stores these objects, which are configured with theaccount information needed to perform the NT system logon. The objects are then associated with specific NDS users sothat 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, roaminguser profiles, system policies, and NT user groups.

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

Another product, Novell Administrator for NT (formerly code-named Tabasco), addresses the problem of assimilatingNT domains into NDS. This product is a NetWare Administrator module that synchronizes NT user and group information inthe NDS database. Sometime this year, Novell plans to release a full port of NDS to NT. This port will eliminate theneed 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 completeenterprise directory services solution. Workstation Manager can be especially useful for NetWare sites with many NTdesktops where administrators routinely travel to each system to create user accounts or use NT domains solely forcentralized account management.

Installing Workstation Manager
To obtain Workstation Manager, you must download IntranetWare Client for Windows NT, which is available for freefrom http://www.novell.com.

Workstation Manager consists of two parts. One is an updated version of the NetWare Graphical Identification andAuthentication module (NWGINA) that replaces the Microsoft GINA on the NT system. NWGINA controls the functions of thelogon 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 schemato 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 asetupnw.exe program, which installs the client software (including NWGINA) on the NT system, and an admsetup.exeprogram, which installs NT versions of the NetWare administration utilities (including the new snap-in modules) to theSYS volume on the NetWare server.

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

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 settingsin a file called workman.reg; to apply them to the Registry's HKEY_URRENT_USER hive, you simply double-click thefile in NT Explorer or File Manager. These additional installation procedures are necessary because the new NWGINAmodule 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 aninstallation 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 beaccessed 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 ofobjects that you can create in a directory service, the objects' attributes, and how they interact with other objecttypes). NetWare Administrator, the program that uses the schema to create and manage NDS objects, can access specialWindows DLLs called snap-in modules that extend the schema by providing new object type definitions. Although Novellprovides the snap-in modules for Workstation Manager, third-party developers can also create snap-in modules that definenew 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 yourun NetWare Administrator, you can create NT Client Configuration objects. These objects represent your NT workstationsin the NDS tree and store information used to create NT user accounts. A Registry key stored in the HKEY_CURRENT_USERhive of the system on which you installed Workstation Manager references the snap-in modules that let NetWareAdministrator create NT Client Configuration objects. If you want to manage the Client Configuration objects fromanother NT system, you must either install the snap-in modules on that machine by running admsetup.exe again or use aroaming user profile to store your Registry settings on a network drive. (For information about roaming profiles, see "CommonWindows NT Problems," April 1997.)

You create NT Client Configuration objects in the NDS tree just as you create other types of objects. By assigningvalues to the object's parameters, you can remotely configure an NT workstation's NetWare client and determine how thelocal 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 withthe user's NetWare credentials, or you can specify a username. Screen 3 shows the Dynamic Local User configurationscreen. When the NWGINA module creates the user account, NWGINA assigns it a random password and makes the user a memberof the NT groups you select.

Depending on your users' access patterns, you can configure the NWGINA module to create permanent user accounts orvolatile ones, which the system deletes when the user logs off. If you have many users accessing one machine, usingvolatile 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. Thisassociation triggers the NT account creation during logon. When the logon process begins, the user is alwaysauthenticated to the NDS tree first. Once NetWare grants the user access, the NWGINA module reads the NT ClientConfiguration object and uses its parameters to determine the NT username. NWGINA then checks NT's Security AccountsManager (SAM) to see whether that user name already exists on the system. If not, NWGINA creates a new account and theNT logon proceeds. At the end of the process, the user has access to both NetWare and NT networks with one username andpassword. Figure 1 summarizes the logon process.

Workstation Manager lets a network administrator shift much of the NT workstation security and client maintenanceactivity to NDS. In fact, you can configure the IntranetWare client to deny all access to the NT system unless an NDSlogon is completed successfully. However, if you don't enable this feature, Workstation Manager won't interfere withnormal NT operations. You can still create user accounts manually and disable dynamic local-user account creation simplyby 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 configurationson one workstation that you can apply to NT workstations throughout the enterprise. By modifying the parameters of NTClient Configuration objects, you can alter most of the client settings that you'd typically have to change on each NTsystem being configured. You can control the execution of user and profile logon scripts, specify the names ofalternative script files, and change how the NWGINA appears to your users by specifying a bitmap of your choice andsuppressing 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 installedversion of the Novell client with the source files on a network drive. IntranetWare performs the software upgrade onlywhen 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 privilegesbefore you can upgrade the client software.

Because the user accounts that Workstation Manager creates ordinarily don't have administrator privileges, theClient Configuration object includes a special setting. When enabled, this setting causes NWGINA to compare thetimestamp 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. NWGINAperforms 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 logonprocedure occurs. This way, you can deploy a client software upgrade to all your NT workstations automatically, withouttraveling 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 theaccount information in the NT Registry (not in the NDS database), you can associate one NT Client Configuration objectwith multiple users and have the object service multiple NT workstations. This capability exists even when you use NTfeatures 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 Startmenu--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 aboutroaming 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 thespecific user. The network administrator usually creates policies as a way to limit users' access to certain parts ofthe operating system. (For more information about system policies, see Robert Slifka, "How to Edit NT 4.0 SystemPolicies," February 1997, and Sean Daily, "Further Explorations of the NT System Policies Editor," April1997.)

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

When you create one object to represent multiple workstations, specifying the path to one file isn't practical wheneach user maintains a unique profile. Thus, to accommodate multiple roaming users with one configuration, you select theRelative to Home Directory check box and enter the path to a network directory, instead of a file. Then you createsubdirectories 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:usersjsmith directory. By controlling users' accessrights 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 operatingsystem. Storing client configuration settings in the NDS database preserves the capabilities of both the IntranetWareClient and NT while eliminating the need for administrators to perform account maintenance and client configurationtasks at individual workstations.

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

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

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

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

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like