Chapter 4: Growing Your NT Server Network

Abstract

This chapter explains how to design single and multiple domain networks to handle large numbers of computers, users, and groups. You will learn how to analyze your network to determine the number of domains you need and the number of backup domain controllers within each domain.

---

As your network grows in number of users, number of computers, overall network traffic, and number of geographical sites, you need to maintain an acceptable level of network performance. Unfortunately, as some of these factors increase, performance will decrease unless you do some careful planning.

In this chapter, I fill you in on how to plan single domain and multiple domain networks to handle large numbers of computers and users. I show you how to analyze your network requirements and design a network containing multiple domains. Finally, you’ll get a glimpse of how Microsoft has used Windows NT Server domains as the basis for its huge worldwide network.

HOW MANY BDCS DO YOU NEED?

In planning large domains, you need to consider the number of BDCs required in each of them. As I said in Chapter 1, you should always have at least one BDC in each domain, even if your domain is small. This allows users to log on to the domain when your PDC is down.

How many additional BDCs are needed? The answer depends on the number of user accounts in your domain. The rule of thumb is that each BDC can support up to 2,000 users. So, if your domain contains 4,000 users, you need at least two BDCs. Likewise, if you have 10,000 users, you need five BDCs. If you use this formula, you’ll do an effective job of spreading the user validation load across your domain controller computers.

HOW MANY DOMAINS DO YOU NEED?

Many organizations, especially those that are small- or medium-sized, do just fine with a single Windows NT Server domain to centralize security and administration for the entire enterprise. Indeed, this is the simplest approach for organizing and administering an NT Server-based network. There are, however, a few reasons why you might want to divide your enterprise network into multiple domains. These include:

 

• Administering by autonomous departments
• Administering multiple sites connected by WANs
• Offering increased security between departments
• Enhancing performance
• Increasing the number of computers
• Increasing the number of users

 

All of these are excellent reasons for designing an NT network based on multiple domains. Some of them are based on your organizational structure. For example, if you have two departments, each with local network administration responsibility, you’ll want to consider giving each department its own domain. Moreover, you may want to prevent users in one department from having access to certain information or resources in another department. Or, perhaps your organization is divided into multiple sites, each with local administration responsibility. The remaining reasons for using multiple domains are based primarily on the size of your network, in terms of network traffic, number of computers, and number of users.

 

Note: If you’re familiar with NetWare, NT domain design is similar to NDS in NetWare 4. NDS is considered somewhat more flexible, but also a lot more complex. As you’ll see later in this chapter, NT’s multiple domain approach uses trust relationships to design multiple levels of network hierarchy. By using NT domains as basic building blocks for directory services, you can create just about any network structure.

One of the key reasons why folks use multiple NT domains is to improve performance. First, you can lighten the load on the PDC and BDCs and thus lessen overall network traffic within a domain. PDCs, especially in large networks, can spend all of their time replicating account database updates over the network. What’s more, they can generate lots of network traffic to keep all of those BDCs in sync. The problem is exacerbated if the database updates are being done over a slower WAN link to another site. Once all this database updating becomes a performance bottleneck, your real applications (and your users) begin to suffer.

WHAT ABOUT CENTRAL ADMINISTRATION?

By breaking your network into multiple domains, aren’t you defeating the purpose of centralized security and administration? Well, yes, at least potentially. Users can only access resources in domains in which they have accounts. Thus, if a user needs access to resources in all three domains in your organization, he or she has to have a separate account in each domain—very reminiscent of the workgroup account administration fiasco discussed in Chapter 1.

You can set up your accounts this way, but you’d defeat the whole purpose of Windows NT Server domains. NT Server provides a solution to this problem—namely, trust relationships.

DEVELOPING A TRUST RELATIONSHIP

By setting up trust relationships between domains, a user needs only one account in one domain. If that user’s domain is trusted by another domain, the other domain will accept his or her initial logon as valid. There’s only one user account to maintain, but the user has access to resources in multiple domains. This approach, called single network logon, makes your life as an administrator much easier. Just log on to your own domain, and all domains that trust your domain will grant you access. Trust relationships move the benefits of centralized administration from the domain level to the network level. As an administrator, you need only create one account for each user on the network.

 

Caution: It’s easy to lose sight of who is really being trusted here. When you allow your domain to trust another domain, you’re actually saying that you fully trust the administrator of the other domain to provide adequate security and prevent unauthorized access to the network. You’re essentially putting access to your domain in the other administrator’s hands. Of course, if you administer both domains, you’re just saying that you trust yourself, and I hope you do.

Trust relationships always go one way (that is, one domain trusts another domain). However, you can set up two separate trust relationships between two domains, so that they trust each other. One domain can trust many other domains, and many domains can trust one domain. This allows you to build up all sorts of combinations of relationships.

Note: You may hear or read about two-way trust relationships. This really implies two separate one-way trust relationships. Each domain must be explicitly told to trust the other domain.

 

Trust Only Goes So Far

Trust relationships aren’t transitive. If DOMAIN1 trusts DOMAIN2, and DOMAIN2 trusts DOMAIN3, DOMAIN1 doesn’t automatically trust DOMAIN3. You, as an administrator, must set up an explicit trust relationship between domains 1 and 3, if that’s your intent. This actually provides you with more control over your domain, since you explicitly have to know about all domains that your domain trusts.

For example, say you have a domain established for each department in your organization. The accounting department might need access to resources in all other departments to continuously gather budget and invoice information. However, you don’t want other departments to have access to all of the accounting department’s resources, such as the payroll database, for example. So, you set up trust relationships wherein each departmental domain trusts the accounting domain. Thus, users in the accounting domain can access resources using their accounting domain user accounts. However, folks in other departments can’t access the accounting domain, unless they have a separate account in that domain.

Now, say you have a product development department and a customer support department, each with its own domain. You want to allow these departments to access each other’s resources, so you establish two trust relationships, one in each direction, between the domains. Users in the product development domain can use their accounts to access resources in the support domain, and vice versa. In this situation, the network appears to users as one large domain, although the two groups log on to different domains.

Establishing a Trust

There are two tasks you need to perform to establish a trust relationship between two domains. Let’s say you want DOMAIN2, the trusting domain, to trust DOMAIN1, the trusted domain. First, you must warn DOMAIN1 that DOMAIN2 is about to trust it. At this point, you establish a password for the trust relationship that will be required to complete the arrangement. Then, you need to tell DOMAIN2 to trust DOMAIN1.

Tip: If the two domains are administered by two different people, a quick way to complete this task is for one administrator to perform steps 2 through 8 in the following steps. The other administrator can then perform steps 9 through 15. The two of you can talk on the phone as you walk through the steps. You’ll need to agree on a password for the trust relationship anyway, and you can communicate any error conditions to each other immediately.

If you have administrative access to both domains, you can create both sides of the trust relationship from a single computer. When you need to administer a different domain, just use User Manager for Domains, click Select Domain on the User menu, and select the domain you need to alter.

Here are the steps to create a trust relationship between two domains:

 

1. Make sure that the PDCs for both domains are running on the network.
2. Log on as an administrator to the PDC of the domain to be trusted and
perform steps 3 through 8 there.
3. Start User Manager for Domains by clicking Start Programs Administrative Tools User Manager for Domains.

 

Cross-Reference: You’ll find out more about User Manager for Domains in Chapter 9.

 

4. On the Policies menu, click Trust Relationships.
5. Click Add next to the Trusting Domains box, as shown in Figure 4-1.
6. In the Trusting Domain box, type the name of the trusting domain, as shown in Figure 4-2.
7. In the Initial Password box, type the password for this trust relationship. Then, type the same password in the Confirm Password box, as shown in Figure 4-2.
8. Click OK.
The trusting domain that you typed is now added to the Trusting Domains list.
9. Log on as an administrator to the PDC of the trusting domain and perform steps 10 through 15 there.
10. Start User Manager for Domains by clicking Start Programs Administrative Tools User Manager for Domains.
11. On the Policies menu, click Trust Relationships.
12. Click Add next to the Trusted Domains box.
13. In the Domain box, type the name of the trusted domain, as shown in Figure 4-3.
14. In the Password box, type the password for this trust relationship. This is the same password entered in step 7. See Figure 4-3.
15. Click OK.
If the password is correct and the trusted domain is able to confirm, the trust relationship is established. The trusted domain name that you typed is now added to the Trusted Domains list.

 

Figure 4-1: You click Add to add to the list of trusting domains.

Figure 4-2: You add a trusting domain by typing its name and assigning a password to the trust relationship.

Figure 4-3: You add a trusted domain by typing its name and specifying the trust relationship password.

Figure 4-4: Local groups can contain both individual user accounts and global groups, defined in either the local domain or a trusted domain.

Breaking a Trust

To break a trust relationship completely, you must remove both halves of the trust. Again, this requires administration tasks in both domains involved in the trust relationship. Here are the steps to break an existing trust between two domains:

 

1. Make sure that the PDCs for both domains are running on the network.
2. Log on as an administrator to the PDC of the trusted domain and perform steps 3 through 6 there.
3. Start User Manager for Domains by clicking Start Programs Administrative Tools User Manager for Domains.
4. On the Policies menu, click Trust Relationships.
5. In the Trusting Domains box, select the trusting domain to be removed from the list. Then click Remove next to the Trusting Domains box.
6. Click OK.
The trusting domain name that you selected is now removed from the Trusting Domains list.
7. Log on as an administrator to the PDC of the Trusting Domain and perform steps 8 through 11 there.
8. Start User Manager for Domains by clicking Start Programs Administrative Tools User Manager for Domains.
9. On the Policies menu, click Trust Relationships.
10. In the Trusted Domains box, select the trusted domain to be removed from the list. Then, click Remove next to the Trusted Domains box.
11. Click OK.
The trusted domain name that you typed is now removed from the Trusted Domains list. The trust relationship has now been broken.

 

Note: The password used to establish a trust relationship is immediately changed internally by the operating system, once the trust relationship is created. Thus, you can’t use this same password again to reestablish a trust relationship that’s been half torn down. Each trust relationship must be completely broken and started from scratch with a fresh password.

SIZING UP YOUR DOMAIN

Beyond purely organizational and location issues, a key reason for creating multiple domains as a network grows larger is to improve network and server performance. In this section, I help you to analyze your network size parameters to determine if and when you should use multiple domains. The primary consideration for domain size is the size of the SAM database required to manage it. Its size has implications on both server hardware requirements and network traffic.

 

The Size of SAM

Your NT domain’s SAM database consists of computer accounts, user accounts, and groups. Each of these consumes space in the SAM database. Computer accounts take up about 512 bytes each. User accounts occupy 1KB each, and every group eats up 4KB. (Your group mileage may vary depending on the average number of members in each group, but use 4KB as a rule of thumb.) Built-in local groups (such as Administrators, Guests, and Server Operators) consume 44KB right off the top. Since the SAM database consists of all of these elements, you can’t just look at the number of computers or the number of users in a vacuum and determine the total size of the database. You need to look at a combination of factors in your particular network environment.

How large should you allow your domain’s SAM database to grow? Faster processors and more memory on your PDC and BDC computers translate to the ability to handle larger SAM databases. Table 4-1 shows what minimum processors and memory sizes are recommended in PDCs and BDCs within a domain to handle various sizes of SAM databases. Remember that since BDCs can act as PDCs, all BDCs must be just as well-equipped to deal with a large SAM database as the PDC.

TABLE 4-1   PDC AND BDC HARDWARE RECOMMENDATIONS FOR SAM DATABASES
SAM Database Size	Minimum CPU Recommended	Minimum RAM Recommended
5MB	486/33	32MB
10MB	486/66	32MB
15MB	Pentium or RISC	48MB
20MB	Pentium or RISC	64MB
25MB	Pentium or RISC	96MB
30MB	Pentium or RISC	128MB
35MB	Pentium Pro or RISC	144MB
40MB	Pentium Pro or RISC	160MB
> 40MB	Not recommended in a single domain	Not recommended in a single domain

Microsoft recommends that you don’t grow your SAM database larger than 40MB. This is the upper limit of what they’ve successfully tested in the lab. If you exceed this limit, you’ll probably experience degraded performance, both in terms of database replication from the PDC to BDCs and lengthy waits while the database loads into memory for administration tasks. If the analysis that you do in this section leaves you with a database approaching this limit, it’s definitely time to establish multiple domains.

Tip: As you proceed through this size analysis, think in terms of your immediate plans as well as your plans 6 to 12 months down the road. You may want to move to multiple domains now, in anticipation of later network growth or changes in your organizational structure.

What’s in a SAM?

As mentioned earlier, the SAM contains several elements. Whenever you add a computer running Windows NT (client workstation, stand-alone server, or BDC) to an existing domain, you create a computer account for that computer. Although you may have multiple users making use of the same computer during a given day, you only have one computer account per NT node in your network. Thus, you can calculate how the number of computers in your network will affect SAM’s size.

Note: Computer accounts are created in the SAM database only for computers running Windows NT Workstation or Windows NT Server. Other operating systems (such as Windows 95 or Windows for Workgroups) don’t participate in computer account validation.

You need an account for each user in your domain. Some users may utilize multiple computers, whereas some may share a single computer. Still others may require multiple user accounts for specific purposes. When calculating the volume of the SAM database required to handle your user accounts, keep all of these situations in mind.

There are two flavors of groups in the SAM database: local groups and global groups. If you’ve dealt with groups in a single domain model, you’re already familiar with local groups.

Local Groups A local group describes access permissions to resources that are local to the domain. The scope of a local group is limited to the domain in which it was created. It can’t describe access permissions to resources outside of this domain. Moreover, you can’t see or use a local group outside of its home domain. However, you can include a user account from another domain within a local group, as long as the other domain is trusted by the local domain. This capability allows you to grant resource access to users in other domains. (You can also include global groups within local groups, but I discuss global groups later in this chapter.)

The Guests group is an example of a predefined local group provided by NT. You can grant permission to access resources in the local domain to members of the Guests, but you can’t specify access permissions to resources in other domains.

Global Groups A global group, on the other hand, is simply a list of users from a specific domain. A global group includes user accounts only from within the domain in which the global group was created. A global group can’t contain any other groups (global or local), and you can’t assign access permissions to it.

The Domain Users group is an example of a predefined global group provided by Windows NT Server. You can’t assign any access permissions to this group, but you can include it in a local group in any trusting domain, thus granting access permissions in that domain to the users in the Domain Users group.

Global vs. Local Groups So what good are global groups if you can’t use them to define access permissions? If local groups can include user accounts from other trusted domains, why not just include them directly in local groups as needed and skip the global group idea completely? Doing so can become unwieldy, especially when there’s a large number of user accounts from another domain that you want to include in multiple local groups.

Think of a global group as a building block that can be used in other domains to build local groups. Global groups provide a handy means of exporting a group of users in a domain to other domains on the network. When you define a local group within a domain, you can include a global group of users within that local group. The resource access permissions that you assign to the local group are granted to the users in the global group, even though those users exist in a different domain.

As long as the domain that defines a local group trusts the domain that defines the global group, the global group can be added to the local group and users within the global group have the same access permissions as other members of the local group. Table 4-2 summarizes the characteristics of local and global groups. Figure 4-4 illustrates the relationship among local groups, global groups, and user accounts.

TABLE 4-2   A COMPARISON OF LOCAL AND GLOBAL GROUPS
Group Characteristic	Local Group	Global Group
Group can contain individual user accounts defined in the domain in which the group was created.	ü	ü
Group can contain individual user accounts defined in a different (trusted) domain.	ü
Group can contain global groups defined in the local domain.	ü
Group can contain global groups defined in a different (trusted) domain.	ü
Group can contain local groups.	ü
Group can be assigned privileges in the domain in which the group was created.	ü
Group can be assigned privileges in other domains.		Only through membership in a local group

 

Time to Regroup?

The distinction between global groups and local groups is sometimes difficult to grasp. Let’s look at a practical example. Say you have three domains, one each for the Engineering, Accounting, and Marketing departments. Because Accounting controls the company’s purse strings, they’ve somehow managed to get all of the best laser printers in the firm. The poor engineers have only clunky dot-matrix printers in their department. The Marketing department has no printers at all, having spent their budget on the latest advertising blitz. Both Engineering and Marketing want to use the fancy laser printers in the Accounting department. You, as the domain administrator in Accounting, have agreed to provide users in the other domains with access to your printers. To accomplish this, you first establish trust relationships that allow the Accounting domain to trust the Engineering and Marketing domains. Then, in both of those domains, you create global groups that include all of the users in these departments who need access to the printers in Accounting. Next, in the Accounting domain, you create a local group whose members are the two global groups just created, plus the user accounts in the Accounting domain that need access to the same laser printers. Finally, you set the access permissions on these printer resources so that the members of the local group can print to them. At this point, all local user accounts that you included in the local group as well as all members of both global groups have access to the printer resources. Figure 4-5 illustrates the group relationships in this example.

Figure 4-5: A local group in the Accounting domain provides access to members of global groups in two trusted domains.

Tip: Consider using global groups exclusively as the building blocks of your local groups. Remember that local groups can contain global groups defined in the local domain and in trusted domains. (Refer to Figure 4-4.) If your local groups are composed entirely of global groups, whenever you change the membership of a global group, the local groups that contain it are automatically updated–a real time-saver.

Built-In Groups Windows NT Server includes several built-in groups. Table 4-3 presents a list of these built-in accounts, indicating which are local groups and which are global. Groups that are local only on PDC or BDC computers are created when you install Windows NT Server as a domain controller (either primary or backup). Note that the Power Users group exists only when NT Server is installed as a stand-alone server.

TABLE 4-3   BUILT-IN GLOBAL AND LOCAL GROUPS
Built-In Group	Global or Local Group	Description
Account Operators	Local (PDC/BDC only)	Members can administer user accounts and groups in the domain.
Administrators	Local	Members can fully administer the computer or domain.
Backup Operators	Local	Members can bypass normal file security to allow backup of files.
Domain Admins	Global	List of all designated administrators in the domain.
Domain Guests	Global	List of all guests in the domain.
Domain Users	Global	List of all users in the domain.
Guests	Local	Members are granted guest access to the computer or domain.
Power Users	Local (non-PDC/ BDC only)	Members can share resources and create nonadministrator accounts.
Print Operators	Local (PDC/BDC only)	Members can administer printers in the domain.
Replicator	Local	Supports file replication within a domain.
Server Operators	Local (PDC/BDC only)	Members can administer servers in the domain.
Users	Local	Members are ordinary users of the domain.

SAM and Your Domain

Once you’ve estimated the number of users, number of groups, and number of nodes in your network, estimating the size of your domain’s SAM database is straightforward. Worksheet 4-1 provides guidelines for calculating the SAM size and number of domains that you’ll need. Again, be sure to plan for the future in your calculations, so that you can live with your decisions for a reasonable period of time.

WORKSHEET 4-1   CALCULATING THE NUMBER OF DOMAINS THAT YOU NEED BASED ON NETWORK SIZE
Line	SAM Database Elements	Requirements
1	Number of computers running Windows NT on your network
2	Number of network users
3	Number of groups that you define
4	Multiply line 1 by 0.5KB
5	Multiply line 2 by 1KB
6	Multiply line 3 by 4KB
7	Size of built-in NT groups	44KB
8	Total SAM size in KB (Add lines 4 through 7)
9	Total SAM size in MB (Multiply line 8 by 0.001024)
10	Divide line 9 by 40
11	Number of domains needed (Round up line 10 to the nearest whole number)

For example, if your network has 10,000 computers, 5,000 users, and you define 50 groups, your SAM database requires 10.5MB and can be handled within one NT domain. As another example, say you have 40,000 users. You know you’re already over the limit of one domain. If you have 30,000 computers and 1,000 groups, you’ll need about 60MB for the SAM database, and you’ll have to split it across two domains. If these calculations lead you to the conclusion that you need multiple domains, you’ll probably need to start with a multiple master domain model, described later in this chapter.

UNDERSTANDING WINDOWS NT DOMAIN MODELS

A grouping of one or more NT domains along with the trust relationships established between them is collectively referred to as a domain model. In this section, I present several common and recommended NT domain models, along with their pros and cons. The models are

 

• Single domain
• Single master domain
• Multiple master domain
• Complete trust domain

 

If you determined that the size of your SAM database warrants multiple domains, you can skip directly to the section on the multiple master domain model. As with any other modeling approach, your particular situation might warrant deviation from these models. However, it’s important to understand the characteristics of each model as a starting point for your own multiple domain planning.

Hint for Branch Offices

If your network is organized across branch offices linked via WAN connections and you plan to use the single domain model, place at least one BDC at each branch office to handle logon validation locally. This approach allows local users to log on even if the WAN link to the PDC is down. Adding more BDCs provides additional local fault tolerance if your BDC goes down. Figure 4-6 illustrates this approach.

Figure 4-6: You should place a BDC at each branch office, if you’re linked by a WAN to the PDC.

The Single Domain Model

The single domain model is the one with which you’re already familiar—a single PDC with one or more BDCs, some number of stand-alone servers, and client workstations. Using this model, all network administrators can administer all servers in the network, since they’re all in the same domain. This is, by far, the simplest model. As I mentioned before, it enables you to accommodate a SAM database of up to 40MB.

As your single domain network grows, you and your users must deal with increasingly longer lists of users, groups, and resources. Network browsing takes longer, and changes to the SAM database take longer to replicate to BDCs. In this model, the PDC can become a bottleneck to network performance.

If trust between departments isn’t an issue, and everyone is happy with centralized control of the network, the single domain model is a good choice. However, if you have or plan to have a SAM database larger than 40MB, you’ll need to consider the multiple master domain model described later in this chapter.

 

The Single Master Domain Model

If you need to split your network into multiple domains for organizational reasons, but your network is still small enough to be handled by a single PDC, the single master domain model is a good choice. In this model, you break the network into two or more domains, assigning one as the master account domain that deals with all account functions. One or more resource domains provide the actual shared resources such as files and printers to network users. Figure 4-7 illustrates this approach.

Figure 4-7: The single master domain model centralizes accounts and administration into a single domain and uses resource domains for sharing files and printers.

In this environment, all accounts are maintained on the master account domain PDC. None are maintained in any of the resource domains. Each of the resource domains trusts the master account domain. Users always log on to the master account domain, thereby gaining access to resources in all other domains. Using this approach, you can administer network resources centrally or distribute the resource administration responsibility among different departmental domain administrators. Account administration, however, is completely centralized in the master account domain. This model is ideal for organizations where a centralized MIS organization needs to control network access through accounts and groups, but individual departments want to manage the network resources that they offer.

Tip: Here’s a little trick for remembering which direction the trust relationships go in this model. Remember the acronym GRAD, which stands for:
	trustinG
	Resource
	Account
	trusteD
This device should help you remember that resource domains are the trusting domains, and account domains are the trusted domains. So, resource domains trust the account domain.

As shown in Figure 4-7, the single master domain model imposes a sort of hierarchy of domains on the network. Because of this, the master account domain is sometimes called the first-tier domain, and all of the resource domains are called second-tier domains.

As your single master domain network grows, you and your users must deal with increasingly longer lists of users and groups, but resources are grouped by the resource domains in which they reside. So, resource browsing time increases only to the extent that the number of resources in individual resource domains increases. Administration changes and replication of updates to the SAM database take longer, just as they do in the single domain model. However, the individual resource domains may not see any slowdown, if the master account domain is on a separate LAN from the resource domains. In the single master domain model, the solitary master account domain PDC can still become a bottleneck to network performance.

Caution: In some organizations, a subset of users need access only to resources within their own departmental domain. Although it decentralizes user account administration, you can create accounts for these users in their resource domains. This reduces some of the traffic between the PDCs. However, once these users need access to network resources outside their own domain, they’ll have to have an account in the master account domain. If you don’t clean up their old account, they’ll have two accounts, probably with different passwords. I recommend avoiding this approach. The small gain in lower network traffic pales in comparison to the potential administration headaches caused by placing user accounts in resource domains.

If trust between departments is an issue and departments want control over their own network resources, the single master domain model is a good choice. However, if you have or plan to have a SAM database larger than 40MB, you’ll need to consider the multiple master domain model described in the next section.

Hint for Branch Offices

If your network is organized across branch offices linked via WAN connections and you plan to use the single master domain model, strongly consider placing a BDC for your master account domain at each branch office. Your resource domains can use this local BDC to handle logon validation locally, even if the WAN link to the PDC is down. If your branch office has a high-speed LAN connection to the master account domain PDC, you don’t need a master account domain BDC at the branch office.

The Multiple Master Domain Model

The multiple master domain model (say that three times fast) is very similar to the single master domain model. The only difference is that the network includes two or more master account domains, instead of just one. These master account domains all trust each other. You establish explicit trust relationships between each pair of master account domains. Resource domains play the same role as they did in the single master domain model. They trust all of the master account domains. Figure 4-8 illustrates how a multiple master domain is organized.

Figure 4-8: The multiple master domain model uses multiple domains for account administration.

Once again, as shown in Figure 4-8, the master domains comprise the first-tier of the network. The resource domains make up the second-tier. Collectively, the accounts in all of the master account domains include all user accounts on the organization’s network. Typically, an individual user has an account on only one master domain. How do you decide which accounts go in which domains? Some organizations break the accounts up by business function, whereas others divide the accounts geographically.

 

For example, if you have operations in North America, Europe, and Asia, you can create a master account domain in each of these locations. Accounts for users in North America live in the North America domain, European user accounts go in the Europe domain, and so on. Since each of the master domains trusts the others, any user with an account in one of the master domains can log on to his or her own master domain and access resources on the entire worldwide network.

 

Tip: Avoid grouping user accounts in master account domains based on their last names or other random approaches. Dividing folks up geographically or by business function will make it easier to create groups and manage the user accounts.

As you can see, the multiple master domain model is best for large organizations that may be widely dispersed geographically. It’s also a good approach if you anticipate substantial growth of your organization. Using the multiple master domain model, you won’t run into lengthy user and resource browse lists, as long as you keep your individual domains reasonably sized.

The Complete Trust Domain Model

In the past, Microsoft has suggested a complete trust domain model for organizations without a centralized MIS group. The idea behind this approach is to give each department its own domain and create two-way trust relationships between every pair of domains on the network. Figure 4-9 illustrates the complete trust domain model.

Figure 4-9: The complete trust model uses two-way trust relationships between every pair of domains on the network.

The complete trust approach is conceptually simple but creates a very real administrative nightmare. If there are N domains in your organization, there are N × (N–1) trust relationships, and every network administrator must worry about maintaining 2 × (N–1) trust relationships. (Remember that two separate trust relationships are required for every two-way trust.) Of course, when you trust all those other domains, you’re also trusting all of those other administrators to do the right thing. Moreover, it becomes almost impossible to assure the integrity of global groups used by other domains on the network.

In the example illustrated by Figure 4-9, four domains yield 12 trust relationships. Each of the four domain administrators is responsible for maintaining six trusts. For example, the administrator for Domain D has to handle two trust relationships for each of domains A, B, and C. Doubling the number of domains to eight yields a total of 56 trust relationships, with each domain administrator responsible for maintaining 14 of them.

For these reasons, I strongly recommend staying away from a complete trust domain model. In fact, I feel so strongly about it that I’ve left it out of the comparison of domain models, shown in Table 4-4.

TABLE 4-4   COMPARISON OF THE NT DOMAIN MODELS
Domain Model Characteristic	Single Domain	Single Master Domain	Multiple Master Domain
Centralized account administration	ü	ü	ü
Optional decentralized account administration			ü
Use of trust relationships		ü	ü
Centralized resource administration	ü
Optional centralized resource administration		ü	ü
Optional decentralized resource administration		ü	ü
Single network logon	ü	ü	ü
Best for organizations with over 40,000 users			ü
Easiest and most efficient for mobile users to log on from anywhere in the world			ü
Flexibility to configure domains organizationally		ü	ü
Possible very long user browse lists	ü	ü
Possible very long resource browse lists	ü
Logical grouping of resources possible		ü	ü
Multiple domains used for user accounts			ü

INSIDE MICROSOFT’S CORPORATE NETWORK

One of the most interesting case studies of Windows NT Server networks is Microsoft’s worldwide corporate network. They started planning and implementing the conversion from OS/2 to NT Server domains long before NT 3.1 was released. By reading the weekly update in the company’s weekly MicroNews publication, employees could watch the bar chart decline of OS/2 servers and the increase in NT servers across the corporation.

With over 20,000 users and 40,000 nodes spread over 150 different sites, the Microsoft corporate network presented NT Server with an acid test for use in a real-world enterprise network. Since every user requires access to e-mail and other shared corporate resources, Microsoft opted to base its network design on the multiple master domain model, discussed earlier in this chapter. As you might expect, they encountered a few situations in which they had to deviate from this model, for security reasons. You’ll see how in the following sections.

Microsoft’s Information Technology Group, or ITG, is in charge of the MIS function at the company. They were responsible for rolling out NT Server to the corporate network, working closely with the NT development and test teams to assure a smooth transition.

Multiple Master Domain Model Organization

Figure 4-10 illustrates the general organization of the domain structure that ITG implemented on the corporate network. The first tier consists of master account domains, in which all user accounts are maintained. These domains are broken up by geographic location. ITG wanted to keep the number of master account domains as small as possible, as it’s easier to break up a large domain than it is to combine several small domains.

Figure 4-10: Microsoft’s corporate network uses a multiple master domain model.

In classical multiple master domain fashion, all second-tier resource domains trust all master account domains in the first tier. User logons are validated by one of the trusted master account domains.

The First Tier

Even though there’s a North America master domain, Redmond rates its own master domain since over half of the company’s employees hang their umbrellas there. Redmond is the home for the Redmond, North America, and South America domain controllers. Others are distributed close to their user communities around the world. All European master domain PDCs are physically located in England.

ITG has implemented a couple of special master domains to deal with specific security issues. First, it has provided a special master domain for third-party hardware and software vendors, allowing them to transfer files electronically to and from Microsoft. Employees can access this domain through a trust relationship, but the third-party vendors can’t access anything but the special vendor domain. Vendors such as Compaq, for example, use this domain to provide updated drivers and other files used for testing at Microsoft.

Second, because of the sensitive nature of its data within the corporation, the Microsoft Human Resources department has been given its own isolated master domain in the first tier. This prevents unauthorized access to confidential employee data.

The Second Tier

In general, each department and each site gets its own second-tier resource domain. Every product development organization is allowed one second-tier domain that trusts all master account domains. The naming convention used for departmental domains appends the department name to the division name. For example, Sys-WinNT is the second-tier domain for the Windows NT product group within the Systems division. Every site outside of the Redmond corporate campus is allowed to create one resource domain that trusts the master account domains. The naming convention used for sites includes the country and city names. For example, the Chicago site has a domain called USA-Chicago.

ITG has full administrative access to every domain in the corporation. This enables them to back up and restore every PDC and to load new NT builds and patches onto these computers. ITG maintains global groups and works with the Human Resources department to add, delete, and move users between groups as individuals change organizations.

If a group requests it, ITG will supply administration services to second-tier resource domains. Typically, a resource domain is administered jointly by the group that set it up and by ITG.

BDC Placement

Sites are connected via WAN links, and some of the links are quite slow. In some countries, these links can’t be upgraded yet, so ITG must place BDCs strategically to maximize network availability and performance. At each remote site, ITG has placed a BDC for the master account domain serving that region. For example, although the PDCs for all European master account domains live in England, ITG has placed BDCs for each European domain at the appropriate European sites.

SUMMARY

In this chapter, you’ve learned about designing single and multiple domain networks to handle large numbers of computers, users, and groups. You’ve analyzed your network to determine the number of domains that you need and the number of BDCs within each domain. I showed you four domain models, which you can use as starting points for designing your large, multiple domain network. You also peeked into the inner sanctum of the ITG group at Microsoft to see how they successfully implemented a Windows NT Server-based worldwide network.

With new builds of NT arriving daily, they had the impossible and thankless task of keeping all of our departmental servers updated with the latest and (hopefully) greatest code. Other groups would often ask me about these unsung heroes of getting NT Server into the real world. “What’s that team’s name again?” they asked. “Network User Test and Support. That’s NUTS, to you.” This team acronym became one of our favorites in the NT group.

<< Previous Page Next Page >>