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.
--Kevin Kennell
Kevin Kennell August 11, 1999