NT Domains and NDS: How They Stack Up in WAN Administration

The choice of a network operating system should be determined by the needs of each particular network, and how easy it is to manage a WAN definitely factors into the overall needs equation. This article examines NT and NetWare architecture in terms of optimal system design for a fictitious company’s small WAN. In addition to addressing design issues, this article provides a good introduction to the differences between the architecture for these two operating systems.

The initial design of a single-site single-server LAN is similar in both NetWare and NT. One server holds all available information (user name, passwords, account restrictions, group membership, etc.) about the user, and setup is simple: create users, create groups, assign users to groups, and grant rights to groups. There aren’t alot of options to complicate the picture.

However, as a network gets larger, system designers must make several decisions which impact how easily a user can access system resources, along with how much effort the administrator must expend to control access. This system design stage is where many headaches associated with managing a larger network are either started or eliminated. Understanding exactly how your chosen NOS, NetWare 4.1 or Windows NT, stores and distributes this information is vital in using either system optimally.

ACME, Inc.

Design issues to be resolved for this WAN include:

1. how to define the users within each system’s databases
2. how to assign the appropriate file system and print rights to the users
3. how to efficiently utilize WAN bandwidth
4. how to allow each administrator to control his/her department

NDS System Design

Figure 1. Logical Organization for ACME's NDS tree
O = organization
OU = organizational unit

After we have designed the logical structure of our database we must decide where to physically place it. NDS is unique in that we have the flexibility to divide or “partition” the database into convenient chunks and place those chunks in the most convenient locations. The rules for partitioning are fairly straightforward:

1. A container must be the root-most object.
2. A partition may only have one container as the root-most object.
3. A partition may have as many sub-containers as desired.
4. A partition should usually not span multiple sites.

1. We want to place several copies or “replicas” of each partition in case one of the copies becomes either temporarily or permanently unavailable due to system failure.
2. We want to place these replicas close to the users so they don’t have to cross the WAN to access information in the database. User access occurs at authentication (geek-speak for login) or access to additional resources such as a file server at another site. Administrative access occurs when users and groups are added, changed, or deleted—or when system rights are modified.

Figure 2. Partitioned NDS tree for ACME

Every object in the tree can be part of one and only one partition. We have created six partitions as labeled in table 3. An argument exists for creating only four partitions: [Root], LA, CHI, and NYC. But defining partitions by workgroup allows finer granularity of replica placement. We have five distinct workgroups. Add the [Root] for six total partitions. Next we decide where to place the physical replicas of each partition.

We’ll create three replicas of each partition—one Master and two Read/Writes. Master and Read/Write replicas are functionally identical for user and administrative access with the exception that the Master replica must be accessed for partition boundary changes (very uncommon). In other words, for common user login and administrative changes, such as adding a user, the type of replica being accessed does not matter. We’ll place the replicas as shown in Figure 3.

Figure 3. NDS Replica Replacement
M = master
R/W = read/write

The primary server used by each administrator contains the master replica of the partition holding the container managed by that administrator. Technically, administrators manage containers and the objects in those containers. Partition boundaries are unrelated to management of the contents of those partitions. The entire tree could be one large partition with different administrators autonomously managing their own sections. (Partitions are created to allow subsets of the database to be stored throughout the network for efficient access and fault tolerance.)

Read/Write replicas will be placed for efficient user and administrative access. At least one replica will reside at a second site for locational fault tolerance. We’ll pick the second site based on whether users at that second site might need to access information on a given partition. Since production departments in Los Angeles and Chicago share resources with each other, we’ll place replicas of the partitions that contain these departments (LA.ACME and CHI.ACME) in each city. Similarly, design departments in Los Angeles and New York City share resources, so we’ll place the relevant read/write replicas to match. Since field representatives might login from any site, we’ll place a replica of the NYC.ACME partition (including the sales container) on each site. We’ll also place a replica of the [Root] partition on each site.

These replica placements minimize WAN traffic. Users and administrators always have local access to the portion of the NDS tree that concerns them and unnecessary replication is avoided. Chicago, for example, has no use for either design container’s information. So we won’t waste expensive WAN bandwidth by placing a replica there.

Local system administrators maintain complete control over local system resources. Due to time and space constraints, I’ll skip the details of how to set this up. Briefly, it involves blocking all administrative rights at the container level and explicitly assigning those rights to the selected administrator. It would take less than 30 minutes to set up the entire tree.

The local administrator then assigns file system and print queue rights as desired by groups. If a group in another container needs access to a resource in her container, the administrator simply grants the appropriate rights to the group in the other container. Using the Chicago client-server database as an example, the Los Angeles production group needs to access the database on a server in Chicago. The Chicago administrator selects one or more of the 10 LA production groups and assigns the appropriate rights. If the entire LA production container needed access, rights could be assigned to the container object. Every user in that container and all lower-level containers, if any existed, would then acquire those rights.

The advantages of NDS in a multi-server and/or WAN environment follow:

1. Single network login. Users can access all system resources with only one username and password. Authentication to additional resources, even if at another site, is transparently handled by NDS.
2. Single point of administration. Users and administrators only need to make changes once. For example, a user only needs to change one password and an administrator only needs to add the user account once.
3. Minimized WAN traffic. LAN/WAN traffic is minimized because only partition changes are copied to other replicas, and partitions can be sized to eliminate unnecessary replication.

NT System Design

Single Domain
Master Domain
Multiple Master Domain
Complete Trust

Master Domain, Multiple Master Domain, and Complete Trust are all multiple domain models that differ in how they store, access, and administer user accounts.

Single Domain. The single domain model is similar to NetWare 3 with NNS (NetWare Name Service). Any given Windows NT Server domain starts with the first server creating the domain; this server is called the Primary Domain Controller (PDC). Subsequent NT servers can be designated as Backup Domain Controllers (BDC) or can be plain NT servers. All user account information is maintained in the Security Account Manager (SAM) database on the PDC. Information on the PDC (such as administrative changes) is replicated to the BDCs at predetermined intervals; the default interval is five minutes but can be set from one minute to one hour. (Administrative changes occur only at the PDC, while authentication occurs at both the PDC and the BDC.)

The administrator chooses how many BDCs to use and where they should physically exist. Multiple domain controllers (a PDC with multiple BDCs) provides fault tolerance for the security account database. Should the PDC fail, a BDC can be easily promoted to a PDC.

As shown in Figure 4, the PDC (Primary Domain Controller) can exist at any of the three sites, but only one PDC can exist per domain. The domain database resides on the PDC. At least one domain controller should exist at each site.

Figure 4. NT Single Domain. The domain includes 815 users, 37 workgroups, 61 printers, and 10 servers. The domain's clients include Win95, Windows for Workgroups, NT Workstation, and NT Server.

The single domain model is best applied to a LAN or small WAN. There is no ability to divide administration between site administrators, and excessive bandwidth is consumed by replicating information to sites that do not need it. For a small WAN that requires central administrative control, a single domain network would be a workable model. Single domain networks are also easier to set up and maintain than multiple domain models. However, because all changes are made to the PDC and replicated to BDCs, administrators should be local to the PDC to avoid unnecessary WAN usage. Additionally, single domain networks that span multiple locations force users to browse the entire domain whenever they attempt to connect to shared directories and printers, which frequently results in maddeningly slow responses.

For our sample company, we would place the PDC and one BDC in New York City and one BDC at both other sites. This would allow users to access authentication information conveniently, without crossing the WAN. However, the single domain model would not allow the site administrators to control their part of the system independently. This model would also require replication of production information in New York and design information in Chicago where it is really not needed.

Multiple Domains. A WAN like our example fits a multiple domain model better. The single domain model is most appropriate for smaller networks that require centralized administration and which have only a few sites, preferably one.

Microsoft uses three types of multiple domain models: Master, Multiple Master, and Complete Trust. Domains function administratively as separate networks with their own administrators, users, and resources. System administration is more complex in a multiple domain model because administration between domains must be coordinated. Any two domains can set up a trust relationship to allow users from one domain to access resources in another. For example, if domain A has resources that domain B needs access to, then the two domains can set up a trust relationship. In doing so, domain A must trust the authentication (login) process of B; when A gives access to B, A essentially gives access to an entirely separate network. Trust relationships can be one-way or two-way, with one domain trusting the other or both trusting each other, respectively. Regardless of where a user logs in, the authentication request is passed to a domain controller in the appropriate domain.

Just as with NetWare, system access rights are most easily assigned using groups. Windows NT uses two types of groups: local and global. Local groups are used within a domain as a convenient way to assign rights to multiple users. Global groups are used to give a group of users in one domain access to resources in another domain. In our example with Acme, the administrator of the client/server database in Chicago needs to allow the users in Los Angeles access to her database. The Chicago administrator creates a local group, DB_USERS, makes all Chicago users members of the group, and grants access to the database to the group. The Los Angeles administrator creates a global group, LA_DB_USERS, and makes all Los Angeles users members. The Chicago administrator then adds the global group LA_DB_USERS to her local group, DB_USERS. All of the LA users can then access the database in Chicago. Global groups must be added to local groups because a global group cannot have rights assigned directly to it.

Master Domain. The master domain model segments the WAN into multiple domains. One domain holds all user accounts and groups, while other domains contain the computer systems that represent the system resources (file systems and printers) that users need to access. This model allows centralized management of user accounts and distributed management of system resources (Figure 5).

Figure 5. NT Master Domain

Multiple Master Domain. A variation on the master domain model involves multiple master domains, all trusting each other. The resource domains trust each of the master domains. This variation allows segmented user account administration in addition to separate resource administration. It can also scale to any desired size (Figure 6).

Figure 6. NT Multiple Master Domain

Complete Trust. The complete trust domain model fully distributes administration of users and resources to each domain. One way to think of it is as completely separate departmental or divisional networks that have agreed to allow groups of users (global groups) from other domains to access their resources. This model is appropriate when centralized user account control is not desired. It is similar to the multiple master domain model except that the resources are managed within the same domain as the users (Figure 7).

Figure 7. NT Complete Trust Domain

The multiple master and complete trust domain models both scale to any desired size, but both suffer from the same potential drawbacks. A large number of potential trust relationships are possible that would have to be established and maintained. For example, a network of 6 domains would have 30 trust relationships (6 * (6 - 1)) to manage. Trust relationships, by their very definition, rely upon the security policies and practices of the trusted domain. The trusting domain has no ability to verify the trusted domain’s security procedures. Large networks involving many interconnected domains may have difficulty maintaining and verifying system security.

Does This Mean Anything

IMHO, NDS is far superior to NT’s domain architecture. On the other hand, NT is a better application server than NetWare 4.1—but not as mature or capable as UNIX-based systems. NetWare 4.1 is much more efficient for file and print, but additional Pentium processors are great equalizers, and they’re cheap and getting cheaper still. NT allows tighter integration for clients we aren’t using yet but will soon. I can play a wicked game of Free Cell on my dedicated NT Server but I don’t want to leave my office to manage whatever network server is running.

I don’t see choice of network operating system as an either/or choice. An administrator for a small network might need to select only one, but larger networks could easily use both. NetWare 4.1 with NDS for a corporate-wide directory services and high-performance file and print; and Windows NT Server as an applications platform. Once Windows 95 and Windows NT Workstation become the primary client platforms, NT Server might become the preferred initial authentication point for the network (gaining superior client control in the process), followed by a connection to the enterprise NetWare 4.1 network and NDS.

Walter Boyd is an independent ECNE/CNI and a principal in Certified Network Solutions, a Novell Authorized Service Center based in Salt Lake City, Utah. You can contact him at 801-553-2440 or wboyd@certifiednets.com.

Return to top of page

Sidebar: NDS: How it works

Novell’s greatest strategic advantage for the next decade is NDS. Novell has staked its future on the success of NDS in the marketplace. Realizing that today’s systems administrators demand more than simple file and print services, they have delivered a directory service that can form the cornerstone of a corporate information network. NDS provides a single globally available database containing the information necessary to access and authenticate a user to all available network resources. It has taken Novell two years to release versions of NFS, SAA and Macintosh products that fully integrate with NDS. Fully NDS-integrated desktop applications such as Novell’s GroupWise e-mail are also starting to appear.

Third party developers are also beginning to release their own NDS integrated products. The programming hooks (APIs) allow developers to access this information and integrate their applications with NDS. Hewlett-Packard has just released JetDirect support for NDS, and by the time you read this, Cheyenne will have released FAXserve 3.0 which directly supports NDS. Expect to see increasing support from major third-party vendors for NDS this year.

Return to article

Sidebar: NT Leads the Way in Client Desktop Management

Return to article

This article originally appeared in the June 1995 issue of Network News, the technical journal of the Network Professional Association. The NPA's mission is to advance the network computing profession. NPA is an independent, self-regulating, non-profit association of network computing professionals that sets standards of technical expertise, professionalism, and ethical behavior to promote a common profession. Membership in the NPA is $175 U.S. per year to all individuals who qualilfy. Associate membership in the NPA is available for $175 U.S. per year to individuals who qualify. For more information, call 1-801-379-0330.