Novell is now a part of Micro Focus

Top Eight Reasons to Use NDS for NT

Articles and Tips: article

01 Jun 1998


1. To eliminate trust relationships

Old way:

Before a user could be granted access to resources in other domains, an NT domain trust relationship was required between the user's domain and every other domain where the desired resources existed. As the number of NT domains with both users and resources grew, the number of trust relationships increased exponentially as n*(n-1), where n is the number of domains, quickly resulting in an unmanageable trust relationship configuration.

NDS for NT:

With NDS for NT, NT administrators may reduce or eliminate NT trust relationships at their leisure. Rather than requiring trust relationships between the user's domain and other domains that contain resources, simply add the user to the "members list" of the domains where the user must access resources. Because NDS for NT is 100 percent backwards compatible with NT domains, NT administrators may continue to use trust relationships to other domains, including domains that have not been upgraded to NDS for NT. NDS for NT provides NT deployments the flexibility to choose the best trust relationship strategy necessary for delivering enterprise NT services, including the flexibility to completely eliminate trust relationships if desired.

2. To eliminate NT Domain synchronization

Old way:

All updates to the domain originated at the primary domain controller and propagated out to each backup domain controller. NT domain synchronization sends the entire object, not just the updates to the object. For example, if a username is changed, the entire user object (not just the new name) was replicated to all BDCs in the domain. Large numbers of domain updates triggered a PDC to BDC synchronization of all objects in the domain database, resulting in high utilization of network links.

NDS for NT:

NDS for NT uses multi-master replication, whereby changes to the NT domain information may occur at any NDS server that holds the NT domain object. NDS replication is extremely efficient; only changes to an object are synchronized, not the entire object.

3. To control your own users and groups

Old way:

NT domain administration was "all or nothing." It was not possible to grant a manager administrative to just a few users in the domain. Rather, the user was given full administrative rights to the entire domain, allowing the user to modify or delete any other user in the domain. For example, if engineering, marketing, and sales shared a common NT domain, it was impossible to grant an engineering manager rights to manage other users in the engineering department. With NT domains, the engineering manager was granted administrative rights to manage all other users in the domain, including users in the marketing and sales departments.

NDS for NT:

With NDS for NT there is only one user account for both IntranetWare and NT resources. Even if users from different departments share a common NT domain, NDS for NT provides the flexibility to delegate user and group administrative rights based on NDS. For example, with NDS for NT, an engineering manager could be granted administrative rights to manage all users within the engineering organization but not the sales and marketing organizations.

4. To manage NT users and groups when NT Servers are unavailable

Old way:

All additions, deletions, and modifications to the domain required access to the primary domain controller (PDC) of the domain. If the PDC was unavailable, either due to a server outage or communication problem, it was impossible to manage the domain. An NT administrator must manually "promote" a backup domain controller (BDC) to act as the primary domain controller. It was also possible to accidently promote a BDC to act as the PDC when the real PDC was online but unreachable, resulting in an inconsistency of the domain database and possible loss of any domain changes while the two PDCs were both available.

NDS for NT:

All domain information is stored in NDS, which is dynamically replicated across multiple servers. When the primary domain controller is unavailable it is not possible to manage the NT domain with standard NT management tools, such as User Manager, because these NT tools must communicate with the PDC. However, NDS for NT provides full domain management using the standard NDS administrative tools. Because the backup domain controllers (BDCs) use NDS (not the PDC) for domain information, users added to the domain through NDS may use NT resources immediately, regardless of the state of the primary domain controller.

5. To deploy more flexible NT domains

Old way:

Medium and large customers were forced to choose between distributed administration, fault tolerance, and scalability when deploying NT servers. Many NT customers wanted to deploy lots of small domains that contained both users and resources, as this greatly simplified delegation of administration over a department's users and resources.

However, due to the n*(n-1) trust relationship scalability problem inherent in NT domains, this configuration (also known as the "complete trust model") was discouraged by Microsoft. Medium and large customers were forced to deploy "single master" or "multi-master" domain configurations, whereby users were stored in large, centrally managed domains. In small, remote sites with a single NT server, users authenticated across WAN links before using resources on segments local to their workstation, increasing login times and placing the user at the mercy of the WAN.

NDS for NT:

With NDS for NT, NT customers may deploy several smaller domains that contain both users and resources. Without NDS for NT, deploying domains with both users and resources was discouraged because of trust relationship scalability problems inherent in this "complete trust model." Since NDS for NT eliminates trust relationships, NT customers may deploy domains based on geographical location or departments. NDS for NT allows NT customer to choose the most flexible NT deployment, maximizing scalability and fault tolerance while providing a flexible user and group administrative capabilities.

6. To eliminate dedicated NT authentication servers

Old way:

Large NT domain deployments require placing user accounts in separate domains from resources. Microsoft recommends a "single master" or "multi-master" configuration whereby all user accounts are created in a large account domain while resources, such as servers, are in separate resource domains. Servers in the master account domains are only used for authentication but often require powerful (and expensive) machines. Users authenticate to these dedicated servers, and then "pass-thru" to servers located in resource domains for network services.

NDS for NT:

NDS for NT eliminates the need for dedicated authentication servers in large, master account domains. With NDS for NT, users may be created in any domain through the enterprise and may be added to as many domains as necessary for consumption of network services. NDS for NT customers do not need to deploy PDCs and BDCs for single master or multi-master account domains. NDS for NT customers can mix user accounts with resources, effectively eliminating master account domains.

7. To move users between domains

Old way:

Consider two domains--Seattle and Provo. If a user was transferred from Seattle to Provo it is not possible to move the user between the Seattle and Provo domains. The user must be deleted from the Seattle domain and recreated in the Provo domain. All user account information, such as the user's password and login restrictions, are lost when the user is deleted from the Seattle domain and recreated in the Provo domain.

NDS for NT:

Since NT domains are represented as objects in NDS, moving the user between Seattle and Provo is a simple "point-and-click" operation. Remove the user from the "members list" of the Seattle domain and add the user to the "members list" of the Provo domain. All user information remains intact because NDS for NT provides the ability to move users between domains without deleting and recreating the user's account.

8. To have a single button for all user/group domain membership

Old way:

The NT domain does not maintain group information on the user account for groups outside of the user's domain. Since access to NT services is often delegated through NT group membership, it is very important to quickly determine a user's rights to resources in a multi-domain environment. Current NT domain tools do not provide this functionality. For example, consider an enterprise with 30 NT domains. How would an administrator determine a user's group membership throughout the NT enterprise? (Hint: assume 10 groups per domain)

  1. Connect to the user home domain.

  2. Select the user, choose "Groups", and write down all group memberships. Note which groups are "local groups" and which groups are "global groups."

  3. Connect to the next domain.

  4. Select the first group and scan the group membership for either the username or any global groups from the user's home domain.

  5. Repeat step 4 ten times, once for every group in the domain.

  6. Repeat steps 3 - 5 for the remaining 28 domains.

Total steps: approximately 300, using a conservative estimate of 10 groups per domain.

NDS for NT:

NDS for NT stores all NT domain and group membership as attributes of the NDS user object. Viewing a user's group membership across multiple domains is a single "point-and-click" operation in NDS. How would an administrator determine a user's group membership throughout an NDS for NT enterprise of 30 domains? (Hint: assume 10 groups per domains)

  1. Select the user in NDS.

  2. Click on "Domain Access."

* 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.

© Copyright Micro Focus or one of its affiliates