Managing Mixed intraNetWare and Windows NT Networks with NDS for NT
Articles and Tips: article
01 Mar 1998
Take a quick look at Novell's cool new solution for reducing the complexity and cost of maintaining NT Domains by making them manageable objects within Novell Directory Services.
Introduction
To have services work across a network, there needs to be a directory service in place that spans that network. To enhance network management and functionality, it is becoming increasingly common for networks to contain bothWindows NT and intraNetWare Servers. Novell Directory Services (NDS) offers many powerful networks services, while Microsoft NT offers many powerful application services. The combination of these two services is NDS for NT.
NDS for NT was developed to enhance NT Domains by making them manageable objects within NDS, offering the following:
A single login
A single point of administration for an entire network
A lower cost of network ownership and operation
A more reliable, scalable, and secure network environment
In addition to the these NDS benefits, NDS for NT enhances domains by:
Reducing the complexity and cost of managing domains
Simplifing the deployment of NT applications
NDS for NT integration is seamless and offers many enhancing features to NT Server functionality. This AppNote briefly examines how NDS for NT works and looks at some of the services it offers.
How NDS for NT Works
NDS for NT works by integrating the NT domain namebase into NDS. This allows network administrators to administer all aspects of the NT domain through NDS. In addition, NDS for NT is designed so that any application requiring domain information will receive that information from NDS.
For example, a user needs access to both an NT domain and an intraNetWare server. If NDS for NT is not installed, the network supervisor would need to create and maintain two accounts for that user, one on each platform. If several hundred users need accounts in a domain as well as on NDS, the amount of work and time required to maintain those accounts would be enormous. However, if NDS for NT is installed on the NT Server, all requests to the domain User object are directed to a single User object in NDS. This object controls access to Microsoft network resources and NDS, thereby greatly reducing the work of the network administrator.
NDS for NT installs directly onto the NT Server. No workstation components or workstation configuration are required. From the perspective of the Microsoft clients or applications using that domain, nothing has changed. All workstations and applications will continue to function as they previously had, before NDS for NT was installed.
As an example, if an administrator needs to add a new user with access to an NT Server using NDS for NT, the administrator can use NetWare Administrator (NWAdmin) and the provided snap-ins to add the user in NDS and grant the new user rights to the NT Server. Also, the administrator can use Microsoft User Manager to create the user. User Manager sends requests to the NT Server to create the user in the domain, and NDS for NT directs those requests to the NDS database. The user is created in NDS with the same properties and access restrictions that are available from the domain itself. Any subsequent modifications made to that user with User Manager or any other domain administration utility is serviced in the same way. While Microsoft User Manager can be used to create and modify users in NDS, NWAdmin and its snap-ins offer all the same administration features, as well as significantly more configuration options.
The architecture of the Windows NT domain is illustrated in Figure 1. In a Windows NT domain, all applications needing access to information from the NT domain make requests to SAMLIB.DLL (including applications run on the NT Server or an NT Workstation, such as NT User Manager, NT Server Manager, or Microsoft Exchange). SAMLIB.DLL then communicates to SAMSRV.DLL using Remote Procedure Calls (RPC). For applications run on the server, this is all done internally. For requests originating from a workstation, the RPC requests are received at the server via the network. Once the request is received by the server RPC, the request is extracted and passed to SAMSRV.DLL. SAMSRV.DLL then accesses the Windows NT Security Accounts Manager (SAM) where the domain namebase is stored and performs the requested operation.
Figure 1: Windows NT Server domain architecture.
NDS for NT integrates Windows NT domains into NDS by renaming the NT SAMSRV.DLL and replacing it with a new DLL that redirects domain access calls to NDS. Figure 2 shows how this change is implemented.
Figure 2: NDS for NT architecture.
The only difference is that the new SAMSRV.DLL directs all requests from the domain to NDS through the intraNetWare Client. NDS can then be populated with User, Computer, and Group objects that take the place of the objects previously used from the domain.
Improved Domain Flexibility Through NDS
The NT domain namebase is stored in the Windows NT SAM. The domain is identified by a unique number. This number, or the Security Identifier (SID), uniquely identifies an NT domain across a network. Objects in the domain are also identified by a SID which is created by combining the domain SID with a Relative Identifier (RID). This object SID is used throughout the Microsoft network to identify the object and its access to system resources.
When using NDS for NT, each Windows NT domain is represented by a domain object in NDS. This object behaves similarly to a Group object in that it not only holds information about the domain and users which are members of the domain, but it also contains member objects such as computers and groups, similar to an actual domain. This is illustrated in Figure 3.
Figure 3: Domain objects in NDS, as viewed with the NetWare Administrator utility.
The domain object acts as a group with a list of domain members. The computers and groups associated with the domain are represented as objects contained within the NDS domain object. By making User objects "members" of the domain, rather than actually residing within the domain, administrators can place the NDS User objects anywhere in the tree and still give them access to specific domains. Because NDS for NT stores each user's RID in the NT Domain object and not as part of the User object, one NDS User object can be a member of more than one NT Domain object. This provides a way for a single NDS user to access resources in multiple domains without having to set up complicated trust relationships.
Integrating Domains to NDS
For servers that are already installed and that contain a large number of users and computers, NDS for NT provides a utility which allows the NT Server administrator to easily migrate Windows NT domains into NDS. This utility guides the administrator easily through the process of creating the Domain object in NDS and then proceeds to create all defined Computer and Group objects. User objects from the domain can either have new NDS User objects created for them, or they may be associated with existing NDS User objects. This greatly simplifies the task of moving an existing domain to NDS. New domain user members, computers, and groups can also be created using NWAdmin and the snap-in provided with NDS for NT, or with the appropriate utility provided with NT Server.
NDS for NT and Windows NT Domain Controllers
Windows NT networks are installed with a primary domain controller (PDC) and one or more backup domain controllers (BDC). The domain namebase is stored on each of these domain controllers in a single master configuration. This means that each domain controller can provide information requesting entities, but all changes to the domain must be made at the PDC. The PDC then replicates the changes down to each of the backup domain controllers, as shown in Figure 4.
Figure 4: All changes must occur at the PDC, which then updates the BDCs.
NDS for NT moves the domain namebase into NDS where it is referenced by both primary and backup domain controllers. In order for all domain controllers to have access to the domain information stored in NDS, all primary and backup domain controllers must have NDS for NT installed.
User Authentication and Single Sign-On
To effectively integrate Windows NT networks and NDS into a single heterogeneous network solution, there must be a way to provide users with single sign-on capability. Single sign-on means that when a user needs to access network resources from intraNetWare or Windows NT, the user simply enters a single username and password and is granted access to the appropriate resources. Using NDS for NT and the intraNetWare Client for Windows NT, information system managers have a reliable authentication solution that will provide the desired single sign-on capability.
User Passwords
Windows NT uses an MD4 password encryption algorithm while NDS uses the RSA encryption. When user passwords are created, they are hashed (encrypted or scrambled) by the respective algorithms, then these hashed values are stored on the respective servers. When a user logs in, the password is passed through the RSA encryption algorithm at the workstation and the encrypted value is sent to NDS for verification. If the hashed value of the entered password matches that stored in NDS, the user is authenticated to NDS.
At the same time, the password is also hashed with the MD4 algorithm and sent to the Windows NT domain controller. This hashed value is compared to that stored in the domain User object; if they match, the user is authenticated to the NT Server. This authentication process is secure because the encryption process that is performed on each password is non-reversible. This means that even though the hashed value is sent on the wire, there is no way to reverse the encryption process and determine the clear text password from the encrypted value.
When a domain is migrated to NDS, the hashed user passwords are also migrated. This allows a user to log in to a recently migrated domain using the same password that was defined before the migration took place. NDS holds both hashed passwords for the user, one encrypted using the MD4 algorithm and one encrypted using RSA.
Because there is no modification to the workstation, the login process used to authenticate to NDS and the NT Server does not change. The login process hashes the user password with RSA and sends that directly to a Novell server for authentication to NDS. The login process also hashes the password using MD4 and sends that to the Windows NT domain controller. The redirected domain controller retrieves the hashed user password from NDS and compares it to that sent from the workstation. If they match, the user is authenticated to the Windows NT domain.
All of this information is sent using multiple encryption techniques. The clear text and hashed password values are not sent natively on the wire. Novell will not jeopardize any Microsoft security that is a part of domains. For this reason, it is necessary to store both the Microsoft and NDS passwords in NDS. This way when the workstation sends an MD4 encrypted password to the domain controller, the NT Server is able to retrieve the encrypted password from NDS and authenticate the user to the NT Server.
Maintaining Password Synchronization
Because Novell maintains Microsoft's security, it is necessary to keep the NDS and NT passwords synchronized. Most users will change their password when prompted or when they have forgotten and have to call their network administrator. In either case, the passwords are easily changed and synchronized. The methods used to maintain this synchronization are identical to those used when authenticating users to standard NT domains.
The best way to maintain synchronized passwords involves configuring the client workstation to simultaneously authenticate to both NDS and Windows NT. The following methods and utilities will help you maintain password sychronization:
Use the intraNetWare Client for Windows NT and check the "Automatically Synchronize Passwords" check box at login if the passwords are not currently synchronized. The intraNetWare Client change password feature is done through the NWGINA module. You can also use Novell Clients for Windows NT, Windows 95, and Windows 3.1x, which also provide password change utilities that will simultaneously change the password for all servers currently attached. For Client 32, this is the Change Password utility.
Use the NWAdmin and the snap-in provided with NDS for NT to change user passwords. This snap-in provides a change password option that will change both the NDS and NT passwords. Using the snap-in for NWAdmin instead of User Manager, NETADMIN, and SETPASS will ensure password synchronization.
Set the passwords to expire through NDS and not through NT. This ensures that an NT password is not changed without changing the corresponding NDS password. Making sure users who need both NDS and NT resources authenticate to both NDS and NT simultaneously avoids any rare password synchronization issues.
The NDS For NT Service Account
Once a Windows NT domain has been integrated with NDS, the Windows NT domain controller must be authenticated to the NDS tree in order to store, modify, and retrieve domain information from the Domain objects. The NDS for NT service running on the domain controller will authenticate to the NDS tree using a service account created for this purpose.
The Service Account
NDS for NT must be able to create, delete, and modify the objects in NDS that represent the Windows NT domain. This requires the service account to have administrative rights to the container where the domain resides. In addition, the service account must have administrative rights to all containers holding the NDS User objects of the domain members. This may require the administrator performing the migration to grant trustee rights to containers where future domain members may exist.
Creating the Service Account
When the domain migration utility is used to integrate a Windows NT domain with NDS, the administrator doing the migration is asked to specify a service account. A pre-existing NDS user account may be used or a new account may be created at the time of the migration. Because the service account must have the administrative privileges previously mentioned, the administrator doing the migration must be able to grant the necessary trustee assignments to the service account.
After the service account has been created, the account credentials are encrypted and stored in the secure portion of the domain controller registry. Once the service account credentials are in place, they can only be changed using the maintenance utility provided with NDS for NT. Because this credential set is very static, the service account password should be set to never expire. Otherwise, at the end of the expiration period, the administrator will be required to use the maintenance utility to manually change the service account password stored on all domain controllers of the domain.
Using a Single Service Account for Multiple Domains
It is not recommended that you use a single service account for all domains placed in the NDS tree to reduce the number of accounts with administrative privileges to portions of the tree. There are two reasons why you should do this. First, using a single service account for all domains creates a single point of failure. If something happens to the service account, such as being inadvertently deleted, all domains would be affected. Second, the service account is only going to be used by the NDS for NT service running on the domain controllers, so the password of the service account can be made very complex and secure. While a normal user would find this vexing, the NDS for NT service will get it right every time. With the service account secured with a complex password, the risk of having multiple service accounts, one for each domain, is minimal.
Summary
NDS for NT upgrades the Windows NT Domain system to a true directory service and provides single login, single point of administration, and full NT application support for mixed intraNetWare and NT networks. NDS for NT also helps eliminate the high costs associated with the cumbersome NT domain system. It also greatly reduces the amount of time network administrators spend managing the multi-platform networks that have become the norm in today's workplace. It allows administrators the flexibility of managing all Windows NT domains and their resources in NDS using either NWAdmin or the analogous Windows NT utilities. NDS for NT also allows a single NDS User object to become a member of multiple domains, thus doing away with the complexity of trust relationships that are inherent with multi-domain installations.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.