Novell's NDS for NT

Combine Windows NT reliability with NDS architecture and scalability

Novell released Novell Directory Services (NDS) in 1993 and has continued to refine it. The company has now developed NDS for NT, a directory services solution that builds on NDS's strengths and unique architecture. NDS for NT takes maximum advantage of its primary strength: the NDS database. NDS for NT assimilates the user and group information from Windows NT domains into NDS to bypass the weaknesses of NT's domain system. Users retain NT's reliability and can gain improved directory performance. Systems administrators gain a heterogeneous network with a single point of directory service administration. In addition, NDS for NT's partitioning and replication capabilities make NDS scalable to an almost unlimited degree; Novell engineers have created a 2-million-user NDS tree.

Just what is NDS for NT, and what can it do for your network environment? Can a product with such a high degree of scalability be easy to install and manage? To answer these questions, I'll describe NDS for NT's features and how it integrates NT and NDS. Then, I'll walk you through the installation process and discuss management issues. Finally, I'll discuss how well NDS for NT functions on an NT-only network.

NDS for NT
NDS for NT is a limited metadirectory (see Craig Zacker, "Metadirectories: Directory Services for the Enterprise," page 121) in that it integrates two of the most common network operating system directory services: NDS and the NT domain directory. NDS is a hierarchical directory service that can manage large network environments. NDS stores all directory objects, including users and groups, in a database and displays them in the form of a tree. NDS for NT extends the schema of the NDS database by adding NT domains and groups to the list of objects that can exist in the tree, letting network administrators manage those NT domain objects with NDS tools such as NetWare Administrator. This management capability is particularly useful in a heterogeneous environment with NT and NetWare servers.

Improved synchronization. In contrast to Novell's earlier NT-NDS integration product, Novell Administrator for Windows NT, NDS for NT is an evolutionary advance in the integration of NT into NDS. Improvements in synchronization and security are mainly responsible for this advance. In an NT network, NT domains use Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs) to store user and group account information and to verify resource usage on NT servers and on client systems that share resources. NT clients usually log on to the network using an account stored on a PDC. Novell Administrator for Windows NT uses a replication process to synchronize the NT domain and NDS directories. That is, when you create a new NT object or modify the properties of an existing object in the NDS tree, Novell Administrator for Windows NT automatically copies the changes to the NT domain directory. Similarly, Novell Administrator for Windows NT copies changes you make in the NT domain to the NDS tree. This automatic replication lets users log on to the NT network using their standard domain accounts, even though the network's administrators maintain those accounts in the NDS tree, not in the NT domain directory. The NT domain directory uses replicated data from the NDS tree to process domain-account requests.

NDS for NT uses a redirection system (rather than a replication system) to improve synchronization. When a user logs on to an NT client, NDS for NT redirects the logon request to the NDS database, bypassing the domain accounts on the PDC entirely. NDS for NT eliminates NT's native directory service from the logon process after its information migrates to the NDS database.

NDS for NT implements its redirection capability by replacing the NT security module, samsrv.dll, with a new DLL that runs on NT PDC and BDC servers. The new DLL lets NDS for NT bypass domain accounts on the PDC and redirect logon requests to the NDS database on an intraNetWare server. Figure 1 shows the architecture of NDS for NT and the NT standalone security configuration it replaces. In addition, NDS for NT includes snap-in modules that let NetWare Administrator display, create, and modify new NT domain objects in the NDS tree.

An improved security model. NDS for NT's replacement of NT's security module, samsrv.dll, is transparent to users, but it makes a difference to network administrators, especially those who manage multiple domains. An NT domain is a collection of one or more NT servers, including one PDC and at least one BDC. Administrators typically use multiple domains to partition large networks and make them more manageable. Without multiple domains in a large network, user and resource management tasks must span the entire network. As a result, letting individual administrators take responsibility for the administration of different parts of the network is difficult.

In a network with multiple domains, users in one domain can access resources in another domain only if a trust relationship exists between the domains and users have rights to the resources. The necessity for trust relationships between domains can cause administrative problems in a multidomain network because moving users between domains and setting up trust relationships with NT server tools are tedious and time-consuming tasks for the administrator. NDS for NT eliminates these domain-related headaches because it funnels all security operations through its single NDS tree and lets administrators easily grant users access rights to any resource in the tree. Add to this capability the fact that NDS can support networks of virtually unlimited size, and you can see how NDS for NT can lighten a large-network administrator's load.

Administrators of NDS trees can distribute the database among multiple NetWare servers and replicate the database to provide improved performance and fault tolerance. This capability is not possible with an NT domain directory. All NT domain users log on through one PDC. (BDCs handle logon requests only when the PDC fails.) When NDS for NT replaces PDC logons with NDS calls, NDS for NT maintains the use of NT's object security identifiers (SIDs), which usually correspond to a user's logon password and are activated when the user logs on. SIDs give clients secured access to NT server-controlled resources.

NDS for NT and Network Client Software
You need not change existing NT domain client systems to use NDS for NT. If your clients access both NT and NetWare resources, under NDS for NT those clients still must use the client software for NT and NetWare. You won't find keeping the NT and NetWare client software a burden, however: In NDS for NT, one NDS user object gives you access to the resources that the NT and NetWare client software manages.

To use NDS for NT, you must run the latest intraNetWare Client for Windows NT software on your NT PDC and BDC servers. NDS for NT's security module uses intraNetWare Client for Windows NT to communicate with the NDS tree on the network's intraNetWare servers. In addition, intraNetWare Client for Windows NT gives clients normal server access to intraNetWare services.

Installing NDS for NT
Installing NDS for NT consists of three simple procedures: installing intraNetWare Client for Windows NT and the NDS for NT security module, running the NDS for NT Domain Object Wizard, and installing the NetWare Administrator for NT and the schema extension snap-in modules.

To begin the first procedure, run the ndssetup.exe program, which installs intraNetWare Client for Windows NT and the NDS for NT security DLL that replaces the NT security module. After the system reboots, it automatically begins the second procedure by running the NDS for NT Domain Object Wizard, which migrates the NT domain information to the NDS database. To initiate the third procedure, run the admsetup
.exe program, which installs the NetWare Administrator application for NT and the snap-in modules for the schema extensions.

The first and third procedures take only a few minutes to copy files and restart the server. The second procedure, Domain Object Wizard processing, can take more time, depending on the number of domains and users it migrates. The NDS for NT Domain Object Wizard runs through a set of questions and scans the server for details about the current domain configuration. The Domain Object Wizard can create a special service account that the NT domain controller uses to access the NDS database with administrator privileges. When you use the special service account, you can name the container in the NDS tree in which particular NT domain objects and users will be created. (For more information about container objects and directory trees, see Craig Zacker, "NetVision's Synchronicity for NT," page 125.)

The Domain Object Wizard also communicates with the NDS database to detect conflicts between object names that might occur during the migration process. The Domain Object Wizard alerts you to conflicts between NT domain user names and existing NDS users in the Domain Object Wizard Summary window. As Screen 1 shows, you see the status of each user before migration, and you can change a user's status to resolve conflicts. The Domain Object Wizard lets you resolve user conflicts in three ways: you can create a new NDS user with a different name, associate an NT user with an existing NDS object (effectively merging the rights for both accounts), or ignore the NT username.

Protecting user passwords is one of the most important elements in any migration of directory service information. Because the NT domain database stores passwords in an encrypted state, they can be safely transmitted over the network to the NDS servers during the Domain Object Wizard migration process. Because all NT domain users retain their original passwords during the migration, the process is transparent to network clients.

After you answer the configuration questions, the Domain Object Wizard begins the data migration process and displays a status report, which you can see in Screen 2, page 134. If your NT domains have many users, the migration process can be lengthy. After the migration process, the Domain Object Wizard displays a log file, similar to the one in Screen 3, page 134, that includes a list of all the processed users and groups.

If your network consists of multiple NT domains, you must run the Domain Object Wizard from each PDC to migrate all your users to the NDS tree. Install NDS for NT on each of your network's BDCs. This way, if a PDC fails, access to NDS is still available on any BDC promoted to PDC.

Apart from the schema extensions that enable the creation of new object types, NDS support on the intraNet-Ware servers does not change. You don't need additional NetWare loadable modules (NLMs) to support NDS for NT. The intraNetWare Client for Windows NT on the NT server provides the conduit to NDS that the NDS for NT security module uses to communicate with the directory.

NDS for NT does not include an uninstall program, but you can easily reverse the basic architectural change the NDS for NT installation makes. Keep a copy of NT's original samsrv.dll module. If you decide to reverse the changes NDS for NT makes to your system, you can use the samsrv.dll module you've copied to replace the NDS for NT security module. When you reinstall the samsrv.dll module, it will direct clients' domain logon requests to the PDC. The NT directory database will remain intact after you reinstall samsrv.dll, but you will lose object changes you made after you installed NDS for NT.

Managing NDS for NT
Novell created NDS for NT to make network management easier, and the software accomplishes this purpose by delegating all object manipulation to the NetWare Administrator utility, as Screen 4 shows. NetWare Administrator is available in versions that run under NT, Windows 95, and Windows 3.1x. However, only the NT version of NetWare Administrator includes the snap-in modules that support the object classes that NDS for NT creates. Novell has announced that the Win95 version of NetWare Administrator will include these modules, although the company has not said when.

NDS for NT caches only the username of the administrator. The cached username lets the network administrator access an NT server even if the NT server cannot communicate with any NDS servers.

You can manage NT domain objects by running NetWare Administrator from any NT server or workstation system on the network that has NDS for NT, intraNetWare Client for Windows NT, and the snap-in modules installed. One reason why the NetWare Administrator setup procedure has its own installa-tion program (admsetup.exe) is that this program facilitates the installation of the snap-ins on systems other than the PDCs.

You can continue to use NT utilities such as the User Manager for Domains. Because NDS for NT redirects application directory requests to NDS, NT utilities are transformed into NDS maintenance utilities, although they don't have the full capabilities of NetWare Administrator.

Network administrators who are familiar with the look and feel of the NetWare Administrator tree display will feel at home with the addition of the new objects. The NT domains that the Domain Object Wizard imports show up as container objects in the NDS tree, and you can manage these objects just as you do any other NDS container. NT domain groups take the form of NDS groups that you maintain under the domain container object. You can grant any user in the NDS tree access to any or all of the migrated domains by adding the user to these groups. NDS for NT also supports Microsoft Exchange Server user creation, a feature available in NT user management tools. Unfortunately, NetWare Administrator does not support NT file and disk management.

Even though the directories and files that make up the NetWare file system are not part of the NDS database, NetWare Administrator can manage their access control lists (ACLs) through the NDS tree's interface. However, you must continue to use NT Explorer to manage permissions for NT shares. NDS for NT makes all the users in the NDS tree available for selection from Explorer's user lists to reduce the problems associated with conventional NT cross-domain management.

Running NDS on an NT Network
NDS for NT is an excellent directory services solution for heterogeneous networks that use NDS for intraNetWare resources. What about homogeneous NT networks? Does NDS for NT make sense for them? The answer is no, and yes. Strictly speaking, NDS for NT does not function on an NT-only network. Currently, you must have at least one NetWare server to host the NDS database. However, Novell originally intended NDS for NT to run natively on NT, without NetWare servers. Novell plans to release a native-NT version of NDS for NT in the first half of 1998.

In the meantime, you can download a free two-user runtime version of intraNetWare from Novell's Web site. You can use this version of NetWare to host an NDS tree for an unlimited number of NT clients, because NDS for NT uses security connections to the NetWare server rather than licensed user connections. You can also run multiple runtime servers to take advantage of NDS's partitioning and replication capabilities. Thus, you can add NDS to your NT network for the cost of some extra servers.

Is NDS for NT Right for Your Network?
Because NDS for NT supports only NT, it is a limited metadirectory. However, if you're running an NT-only network, that limitation might not pose many problems for you. Right now, determining whether the NDS for NT solution is viable for your network depends on two considerations: whether you think using separate computers solely to host a directory service is worthwhile, and whether you're willing to retrain your NT support personnel to administer NetWare servers. If you decide to go with NDS for NT on your NT-only network, you must decide how large your network must be before NDS for NT is necessary, and at what point your network is too large to rely on runtime directory servers.