Blaine Homer
In a perfect world, the entire network would have one directory, which would be the central management point for the network, its resources, applications, user information, and workstations. This directory would lower the cost of ownership, provide a single login for users, and make networks more accessible to more users.
Novell Directory Services (NDS) is currently the only directory that offers a fully distributed architecture that scales from small networks to global intranets. With NDS, you can design a hierarchical directory to manage your company's network resources, and you can modify NDS on the fly, without shutting down or restarting any servers.
Over the next twelve months, Novell will deliver even more enhancements to NDS--enhancements that will make NDS the standard for a universal directory. For example, Novell plans to make NDS platform independent: Novell has already ported NDS to Santa Cruz Operation (SCO) UNIX and is working with Hewlett-Packard (HP) and other vendors to port NDS to more industry-leading UNIX platforms. In addition, Novell has promised to deliver NDS on Windows NT Server in two stages, the first of which is NDS for NT. (For more information about future enhancements to NDS, see "What's Ahead for NDS?")
By providing a common directory across a heterogeneous environment, NDS eliminates the redundancy of managing separate databases for each network operating system. As a result, your company has more management options and can preserve investments in its existing network infrastructure.
With NDS for NT, Novell has greatly simplified management of Windows NT domains. And because you can manage Windows NT domains directly from NDS, you can now manage a mixed IntranetWare/NetWare and Windows NT Server environment more easily and efficiently.
NDS for NT provides the following benefits:
With NDS for NT, you can eliminate Windows NT domains, including trust relationships and dedicated Windows NT authentication servers. (For more information about Windows NT trust relationships and authentication servers, see "Four Types of Windows NT Domains.") Instead, you can use NDS for NT to integrate your company's Windows NT domains with NDS.
If you are adding a new Windows NT domain to the network, you simply use the NetWare Administrator (NWADMIN) utility to create a Domain object and assign users rights to this object. In addition, you create only one User object for each user, no matter how many Windows NT domains the user needs to access.
NDS for NT also allows you to migrate existing Windows NT domains to NDS. During the migration process, NDS for NT creates a Domain object for each Windows NT domain and retains all of the information about the domain's resources. For example, during the migration process, you are prompted to create a User object for each domain user account or to merge the user account with an existing User object. The new User objects are then placed in the Domain object.
NDS for NT augments your company's Windows NT domains with the advanced features of NDS, such as distribution and replication. For example, when you update a Windows NT domain, the changes are made at the primary domain controller (PDC), which then sends these changes to each backup domain controller (BDC). (For more information about PDCs and BDCs, see "Four Types of Windows NT Domains.") During this synchronization process, the PDC sends the entire account, not just the changes made to this account, to the BDCs. If your company has a large network, these changes can consume a lot of network bandwidth.
When you update an NDS object, on the other hand, NDS sends the changes to each server that holds a replica of the partition in which the object resides. As a result, NDS synchronizes only these changes, saving network bandwidth.
In addition, if you want to make changes to a Windows NT domain, you must have access to the PDC. If the PDC is unavailable, you cannot load the Windows NT User Manager utility. For example, if you accessed the PDC over a WAN link and that WAN link went down, you could not make changes to the Windows NT domain until the PDC was available again.
Of course, you could promote a BDC to a PDC and then update the Windows NT domain. However, this solution could cause serious problems with the domain structure if the PDC were unavailable simply because a WAN was down. When the WAN connection was reestablished, you could not demote either PDC back to BDC status. The new PDC would not recognize the security ID (SID) of the original PDC. (Each Windows NT domain is identified on the network by a unique number, which is called the SID.) The original PDC could not join the Windows NT domain in any capacity.
With NDS for NT, you do not have to worry if the PDC is available because each BDC receives information from NDS. And if a replica of a particular partition is unavailable, you can still update the NDS database because NDS will automatically distribute these changes to the replica when it becomes available again.
NDS for NT also simplifies the management of user accounts in a Windows NT environment. If your company's network includes more than one domain, you cannot move a user account from one Windows NT domain to another domain, even if you have created a trust relationship between these domains. Instead, you must delete the user account from one Windows NT domain and then recreate this user account in the other domain.
Because NDS for NT treats Windows NT domains as NDS objects, you can easily revoke a User object's rights to one Windows NT domain and grant the User object rights to another domain. You do not have to delete or recreate the entire User object, as you do with Windows NT domains.
With NDS for NT, each Domain object functions much like a Group object: In addition to holding information about the Windows NT domain and the domain's users, the Domain object includes information about Computer objects and Group objects. In other words, a Domain object acts as a group with a list of group members. (See Figure 1.) As a result, you do not have to place the same User object in multiple Windows NT domains. You can place a User object anywhere in the NDS tree and then grant the User object rights to resources in a specific Windows NT domain or rights to resources in multiple domains. For example, if Susan were part of the Pay-roll department, you would want to place the SUSAN User object in the PAYROLL Organizational Unit (OU) object in your company's NDS tree. To grant the SUSAN User object rights to the ACCTG Domain object, you would simply use the NWADMIN utility to grant the appropriate rights.
With Windows NT domains, you must either grant a user administration rights to the entire domain or grant the user no administration rights. For example, suppose that your company had three departments--Payroll, Engineering, and Marketing--located in the same geographic area, such as Provo, Utah. Although these departments needed access to resources within the same Windows NT domain, each department wanted administration rights to manage its own users.
Furthermore, each department wanted exclusive administration rights to its own users, preventing other departments from managing these users. For example, the Payroll department did not want the Engineering department to have administration rights to manage the users in the Payroll department, and vice versa.
With Windows NT domains, you have little flexibility in setting up rights. You would have to assign administration rights to each department's workgroup administrator, giving him or her rights to manage user accounts in the other departments. Of course, this solution would be unacceptable to all of the departments.
By contrast, NDS for NT allows you to set up workgroup administrators who manage a specific set of domain resources. You could grant these workgroup administrators rights to manage their own department while revoking rights to manage the other departments, and all of the users in these departments could access services in the same Windows NT domain.
NDS for NT works within the architecture of Windows NT domains. In a Windows NT domain, a user who needs access to the domain sends a request to the SAMLIB.DLL file on the Windows NT server. The SAMLIB.DLL file is essentially the domain database to which all users must request authentication.
When a user or an application requests access to a domain resource, the Windows NT server uses remote procedure calls (RPCs) to send the requested information from the SAMLIB.DLL file to the SAMSRV.DLL file, which is also stored on this server. The SAMSRV.DLL file then accesses the Windows NT Security Accounts Manager (SAM), which accepts or denies the request. (See Figure 2.)
When you install NDS for NT, the SAMSRV.DLL file, which holds authentication information for the Windows NT domain, is renamed as the SAMSRV.OLD file. NDS for NT then adds an enhanced SAMSRV.DLL file that redirects all requests from the Windows NT domain to NDS through IntranetWare Client for Windows NT. (See Figure 3.)
Because the original information in the Windows NT domain is retained, you can back out of the conversion process by changing the SAMSRV.OLD file back to the SAMSRV.DLL file. (However, the SAMSRV.OLD file will not contain any changes you made to the Windows NT domain after this file was renamed.)
Using NDS for NT does not affect domain-based applications; these applications continue to function without modification. If an application requests access to the domain database, the request is handled in the same way a user's request is handled: The application queries the SAMLIB.DLL file, and the Windows NT server uses RPCs to send the request to the SAMSRV.DLL file. If the application is running on a Windows NT server, this process happens internally. If the application is running on a workstation, the request is sent to the Windows NT server, which, in turn, passes this request to the SAMSRV.DLL file. The SAMSRV.DLL file then accesses the SAM, which processes the request.
After NDS for NT is installed, domain-based applications (even Windows NT utilities) are unaware that the requested information is actually coming from NDS. In fact, you could use the Windows NT User Manager utility to create or modify user accounts. NDS for NT would direct these requests to NDS, and the user accounts would be created in NDS with the same properties and rights that are available in a Windows NT domain.
With NDS for NT, domain-based applications function flawlessly, but now these applications can access the power of NDS. And more importantly, you can easily manage these applications.
Because NDS for NT moves the domain namebase into NDS, both PDCs and BDCs must reference NDS when changes are made to a Windows NT domain. As a result, you must install NDS for NT on all PDCs and BDCs. However, you do not need to install any workstation components or change the configuration of workstations in the Windows NT domain.
Before installing NDS for NT on a PDC or BDC, you should install IntranetWare Client for Windows NT, which passes domain requests to NDS. If you are using Microsoft's client software for NetWare, the NDS for NT installation program automatically detects this client software and removes it. The installation program then installs IntranetWare Client for Windows NT.
To install NDS for NT on a PDC or a BDC and migrate your company's existing Windows NT domains into NDS, you complete the following steps:
1. After you insert the NDS for NT CD-ROM into the CD-ROM drive on the PDC or BDC, the NDS for NT installation program automatically begins. A screen appears prompting you to log in to the NDS tree and the Windows NT domain you want to migrate to NDS.
2. After you authenticate to both the NDS tree and the Windows NT domain, a welcome screen appears, explaining the steps the Domain Object Wizard will perform. This welcome screen also reminds you that you must have ADMIN rights to the container object in which the Domain object will reside and administration rights to the Windows NT domain. If you have logged in with the necessary rights, you can continue to install NDS for NT, and the Domain Object Wizard displays the current Windows NT domain and the available NDS trees.
3. Specify which container object will hold the new Domain object. The Domain Object Wizard then creates a Domain object for the Windows NT domain you are migrating.
4. The Domain Object Wizard begins to migrate users and resources from the Windows NT domain to NDS. During this process, the Domain Object Wizard searches the NDS tree for usernames that appear both in NDS and in the Windows NT domain. If duplicate usernames are found, you are prompted to select one of the following options:
- Create. If you select the Create option, the Domain Object Wizard uses the user account to create a User object in the NDS context you specify.
- Associate With. If you select the Associate With option, the Domain Object Wizard merges the user account with an existing User object.
- Don't Migrate. If you select the Don't Migrate option, the Domain Object Wizard does not migrate the user account to NDS, and this user will not have access to the NDS tree.
For example, you could associate the Guest user account with the GUEST User object. You would simply select the Guest user account and click the Associate With button.
You must resolve user conflicts before continuing the installation process. If these conflicts are not resolved, the affected user accounts are not migrated.
5. After you resolve user conflicts, a dialog box appears, prompting you to create a User object with ADMIN rights to the new Domain object.
6. After you create this User object and assign it a password, a migration status window appears, displaying the status of users and resources in the Windows NT domain. This window shows the number of users and resources that needed to be moved, the number of users and resources that were actually moved, and any errors that occurred during the installation process.
7. After the Domain Object Wizard has migrated the Windows NT domain to NDS, another screen appears, giving you the option to view the results of the installation process in a log file.
8. Reboot the PDC or BDC on which you installed NDS for NT.
NDS for NT provides cross-platform administration in a mixed IntranetWare/ NetWare and Windows NT Server environment. In addition, NDS for NT offers users a single login and eliminates the daunting task of creating and managing trust relationships.
NDS for NT demonstrates that NDS is a next-generation directory capable of providing authentication services across multiple network operating systems. Products such as NDS for NT will ultimately produce a network that is easier to manage and capable of making information more accessible--enabling NDS to fulfill its role as a critical business tool.
Blaine Homer is a network consultant who installs both IntranetWare and Windows NT networks. Blaine is based in Provo, Utah.
NetWare Connection, December 1997/January 1998, pp. 6-12