Domains and Domain Servers

A server in a domain has one of three roles:

• Primary domain controller. One Windows NT Server stores the master copy of the domain's user and group database. The PDC is responsible for synchronizing the account database with all BDCs.
• Backup domain controller. Other Windows NT Servers can store backup copies of the domain's user and group database.
• Member or stand-alone server. Servers can participate in a domain without being designated as primary or backup domain controllers.

Each of these roles is described more fully in the following sections.

The Primary Domain Controller

The first Windows NT Server in the domain is configured as a primary domain controller (PDC). The User Manager for Domains utility is used to maintain user and group information for the domain. This information is stored in a domain security database on the primary domain controller.

Backup Domain Controllers

Other Windows NT Servers in the domain can serve as backup domain controllers (BDC). Each backup domain controller stores a replica of the database on the primary domain controller, which is replicated periodically to distribute changes made to the main database on the PDC. Replication of the database has several advantages.

If the primary domain controller experiences a hardware failure, one of the backup domain controllers can be promoted to the primary role. Having one or more backup domain controllers builds a degree of fault tolerance into your network. Each domain should have at least one BDC.

Backup domain controllers also can participate in the logon process. When a user logs on to a domain, the logon request can be handled by any primary or backup domain controller. This spreads the logon processing load across the available servers and improves logon performance. This can be an important benefit in domains with large numbers of users.

Changes cannot be made to the domain database unless the PDC is functioning. If the PDC fails or is shut down for maintenance, you can promote a BDC to function as the PDC.

Although the PDC is required to make changes to the domain database, other domain operations are not dependent on the PDC. Users can log on to the domain using a BDC if the PDC is unavailable.

Servers

Computers running Windows NT Server can also function as independent or stand-alone servers, which may or may not participate in domains. The term servers represents member server or stand-alone server. These servers do not function as primary or backup domain controllers. They can take advantage of the user and group databases, however, that are maintained for a domain, and you can assign user and group permissions for the server using the User Manager for Domains.

The server also can maintain its own database of users, and users can log on to the server independently of the domain. When this is done, the server cannot utilize the user and group database of a domain, and the server handles accounts much like computers running Windows NT Workstation.

You might choose to configure a stand-alone Windows NT Member Server for several reasons:

• The server can be administered by different staff members. Many Windows NT Servers are used for application servers, such as SQL databases. If you configure a database server as an independent server, you can assign a member of your database staff as the server administrator.
• Attending to logon requests can use a significant part of a server's processing capability. If you configure the server as an independent server, it can concentrate on servicing a single function, such as providing application services.
• When a server is functioning as a primary or backup domain controller, it is difficult to move the server to a new domain. If there is a chance the server will move to a different domain, configure it as an independent server.

Synchronizing the Domain Directory Database

All changes to the domain directory database are first made on the PDC, after which they are distributed to the BDCs in a process called synchronization. Changes made to the PDC database-consisting of password changes, new and modified user and group accounts, and changes in rights assignments-are recorded in a change log on the PDC. When a BDC requests a database update, the changes that took place since the last update are copied to the BDC's database. An update that consists only of recent changes is a partial synchronization.

The PDC change database has a limited capacity. It operates as a circular buffer, meaning that older changes will be purged to make room for new changes. Consequently, a BDC that is off-line for a lengthy period of time may have missed changes that have been purged from the change database. Under these circumstances, it is necessary to perform a full synchronization in which the BDC receives a complete copy of the domain directory database from the PDC.

The NetLogon service is tasked with synchronizing the domain database. By default, the NetLogon service synchronizes BDCs at five minute intervals, which is usually adequate given the default capacity of the change database to store approximately 2,000 changes. If changes are being lost, it becomes necessary to increase the frequency of synchronization events or the size of the change log, both of which are determined by settings in the Registry.

When BDCs are separated from the PDC by a slow WAN link, full synchronization is undesirable. In such situations, you may want to increase the size of the change log and reduce the synchronization frequency to reduce WAN traffic, even to the point of scheduling partial synchronization to take place at night.

Chapter 10, "Managing Domains and Trust Relationships," describes several Registry parameters that control operation of the directory synchronization process. See the section, "Configuring Domain Synchronization," in that chapter.

Trust Relationships

Many organizations own several LAN servers-this is fine because domains make multiple servers easy to administer. There are several reasons an organization might need to establish two or more domains; for example:

• If too many servers are put in a domain, performance can suffer.
• For best performance, the domain database should be restricted in size to 40 MB, limiting the numbers of workstations, users, and groups that can be defined in a given domain.
• Some departments prefer to manage their own resources, which is easiest if they have their own domains.

So your organization decides to have several domains. If a user needs to access resources in several domains, is it necessary to create an account for that user in each domain? That could be just as bad as administering several stand-alone servers.

Figure 9.5

Fortunately, Windows NT Server enables you to establish trust relationships between domains. Figure 9.5 illustrates a simple, two-domain trust relationship. Domain B is configured to trust Domain A. As a result, if a user is successful at logging on to Domain A, Domain B assumes that the user has been authenticated properly. Therefore, Domain B accepts the user without forcing the user to explicitly log on to Domain B.

Figure 9.6

Trusts can flow both ways. In figure 9.6, Domains C and D are configured to trust each other. You will see several examples of network designs that use two-way trust relationships.

Figure 9.7

One more thing you should know about trust relationships is that trust does not flow through a domain. (Microsoft's term is that trusts are not transitive.) The top portion of figure 9.7 shows three domains that have established two-way trust relationships. Domains E and F trust one another, as do domains F and G. Domains E and G, however, do not trust each other because trusts do not pass through Domain F.

If all domains are to trust each other, it is necessary to establish trust relationships between each pair of domains. The bottom half of figure 9.7 shows how three domains can be made to trust each other.

Trust relationships do not automatically grant users access to resources in a trusting domain. A domain that trusts another domain relies on the trusted domain to authenticate users when they log on. The trusting domain still must grant those users access to resources.

Domain Models

Proper use of trust relationships enables organizations to build enterprise networks that still require only a single logon procedure for resource access. Microsoft has defined four models for domain trust relationships. If you are configuring a multi-domain network, you will want to consider the merits and disadvantages of each model.

There are two reasons for adding domains:

• For organizational reasons
• To improve network performance

Regarding network performance, you will find that Microsoft's descriptions are a bit vague. You can use a single domain model, for example, "if your network doesn't have too many users..." That doesn't give you much help during the planning stages. Unfortunately, there are many variables, and it is difficult to come up with a simple prescription for adding domains. Windows NT Server can, after all, run on everything from an Intel 80486 PC to a multiprocessor RISC system. Such a broad range of hardware makes performance generalizations difficult. Fortunately, Windows NT Server domains make it easy to reorganize the LAN as it grows.

The four domain models defined by Microsoft follow:

• Single domain
• Master domain
• Multiple-master domains
• Complete trust

Each domain is discussed in the following sections.

The Single Domain Model

Figure 9.8

Figure 9.8 illustrates the single domain model-the preferred model for small organizations. (Remember, size descriptions are very vague. More powerful servers enable a single domain to grow in size.) When all servers are located in a single domain, administration is simplified greatly. Also, there is no need to administer trust relationships-an activity that can get quite involved.

Large amounts of logon or browsing activity might degrade the performance of the domain. When a domain has a large number of servers, browsing can be inefficient, and you might find it advantageous to move some of the servers to another domain. Be alert to performance issues so that you can anticipate when you need to move to a different domain model.

A single domain network has several advantages:

• It is easier to manage because resources are centralized.
• No trust relationships are required.
• Group definitions are simpler.

You need to consider a multi-domain model in the following situations:

• If browsing is slow
• If too many users are degrading performance
• If your organization wants to assign domains to departments
• If you want to have some resources in their own domains

The Master Domain Model

The master domain model designates one domain to manage all user accounts. The master domain also supports global groups. Global groups can export group information to other domains. By defining global groups in the master domain, other domains can import the group information easily.

Figure 9.9

Figure 9.9 illustrates a network based on a master domain model. The master domain is named Keystone, and is managed centrally by the MIS staff. All users are defined in Keystone, as well as some groups that will make administration easier. Only the primary and backup domain controllers in the Keystone domain are used to store user and group account information. Because users cannot log on to the network without a working domain account database, a master domain always should include at least one backup domain controller in addition to the primary domain controller.

When users log on to the network, they always log on to the Keystone master domain. After they have logged on, they can access resources in other domains that trust Keystone.

In this example, the other domains are organized according to departments. After a user logs on through the master domain, most of the user's network activity relates to one of the department domains. Therefore, user network activity is distributed across several domains, removing much of the processing responsibility from the Keystone domain.

Each of the department domains is configured to trust Keystone. The assumption is that Keystone security will be sufficiently tight, and that other domains do not need to take special precautions of their own.

The department domains could be administered by MIS or by the individual departments. The master domain model makes it possible to delegate some management tasks while keeping the critical security function under the control of a central network authority. So that department domains are comfortable with the network security, administrators of the master domain should be well trained and security policies carefully defined.

A master domain network has several advantages:

• Security management is centralized.
• Non-master domains can be used to organize resources logically.
• Browsing activity is distributed through the department domains.
• Global groups in the master domain enable departments to easily establish local permissions.
• Departments that want to can manage the resources in their own domains.

The chief liability of the master domain model is that all logon activity takes place in a single domain. When performance begins to suffer in the master domain, you need to be prepared to move to a multiple master domain model.

Groups are essential ingredients of effective Windows NT Server management. Groups enable you to manage the privileges of large numbers of users more efficiently than would be possible if privileges were assigned to users individually.

Windows NT Server uses two types of groups: local and global. It can be difficult to grasp the differences between these group types and the appropriate uses of each. Consequently, this section does not dwell on that topic. Later in this chapter, the sections "Global Groups" and "Local Groups" investigate Windows NT Server groups thoroughly.

Because all accounts are concentrated in the master domain, a network designed with a single master domain is limited in scope by the size of the master domain's database. Typically, a master domain network will be limited to about 26,000 users and computers.

Although the master domain approach does not permit the network to support more users, it should result in performance improvements. After users have logged onto the network, their activities will be distributed across the department domains. There is less contention for network and server resources, and users should experience a performance improvement.

The Multiple Master Domain Model

Figure 9.10

The master domain model can be extended by introducing additional master domains. This is the primary technique used to scale Windows NT Server networks for larger enterprises. Figure 9.10 shows networks with two master domains and three department domains.

Each master domain supports about half the user accounts. This spreads the processing of logons over several domains. Each domain supports some of the groups that are accessed by the department domains.

Under this model, each master domain trusts every other master domain. This is a convenience for administrators, but is necessary for users only if they actually will be using resources on one of the master domains, which is not ordinarily the case. To reduce the likelihood of security holes, only administrators should be given permissions to access resources in the master domains. Users should be given permissions only in the department domains.

Each department domain trusts each master domain. It is not necessary for department domains to trust each other.

Because users are granted most privileges based on their memberships in master domain groups, it is a good idea to group related users into the same master domains. All your users in Accounting should log on to the same master domain, for example. Otherwise, you are forced to establish similar groups in each master domain. With more groups, it becomes far more difficult to establish privileges in the department domains.

Figure 9.11

The required number of trust relationships increases rapidly as you add domains. Figure 9.11 illustrates a network with three master domains and four department domains. The network in figure 9.10 required eight trust relationships. (Two trust relationships are required to enable the two master domains to trust one another.) The slightly larger network in figure 9.11 requires 18 relationships! Obviously, you do not want to expand the number of domains in your network unnecessarily.

The multiple master domain model has many desirable features:

• It is scalable to any organizational size.
• Security is managed centrally.
• Departments can manage their local domains, if desired.
• Related users, groups, and resources can be grouped logically into domains.

Disadvantages of the multiple master domain model include the following characteristics:

• The number of groups and trust relationships multiply rapidly as the number of domains increases.
• User accounts and groups are not located in a single location, complicating network documentation.

Theoretically, a multiple master domain network can grow to any size. Each master domain can support up to about 26,000 users and computers, and many master domains can be added. Because administration grows more complicated with each added master domain, however, it eventually becomes impractical to add more master domains to a network. It is probable, however, that few organizations will be faced with the limits. It is certainly practical to manage a network with three master domains, which can theoretically support 78,000 users. Is your network that large?

The Complete Trust Model

The master domain models assume that a central department exists that can take responsibility for managing user and group security for the complete organization.

Figure 9.12

If no such department exists, or if departments want to retain full responsibility for managing their own domains, you might choose to implement a complete trust model. An example of a complete trust network is shown in figure 9.12.

In the complete trust model, every domain is configured to trust every other domain. Users log in to their department domains and then access resources in other departments by means of trust relationships.

As with the multiple master domain model, the number of trust relationships required increases rapidly as domains increase. Three domains require six trust relationships (two between each pair of domains), whereas five domains require 20 trust relationships. If n is the number of domains, then the network requires n ¥(n-1) trust relationships.

As a believer in tight network security, I find the implications of the complete trust model extremely disturbing. The administrators of each domain must have complete faith that the administrators of every other domain will maintain a high level of security. For me, that is carrying trust a little too far.

In fact, Microsoft itself has backed off from an endorsement of the complete trust model, and recommends a multiple master domain model for large installations. Although the complete trust model was featured prominently in the documentation for earlier versions of Windows NT Server, coverage is omitted from the Concepts and Planning manual for Windows NT Server 4.

If your organization does not have a central MIS department, networking is a great reason for establishing one. Besides the need to maintain tight security, several other functions are best when centralized. Here are some examples:

• File backup
• Communications services
• E-mail maintenance
• Management of the network infrastructure (media, hubs, and so on)

Few departments have personnel who possess the expertise to do these jobs well. Also, network management in a large organization calls for personnel who are devoted completely to the task.

Therefore, I don't put much credibility into the advantages that Microsoft attributes to the complete trust model, but here they are nevertheless:

• No central MIS department is required.
• The model scales to any organizational size.
• Departments retain control of their users and resources. (But, it can be argued, they surrender that control by trusting everybody.)
• Users and resources are grouped logically by departments.

A few of the disadvantages of the complete trust model follow:

• Central security control is lacking.
• Large numbers of trust relationships are required.
• Departments are dependent on the management practices of other departments.

Estimating Domain Capacity

The big question when planning a domain-based network is, "What is the recommended maximum size for a domain?" This turns out to be a fairly complex question that is affected by the numbers of user, computer, and group accounts. It is also affected by the processing horsepower of the computers that are assigned as domain controllers. All the issues come down to the size of the file that is used to store the Security Accounts Manager (SAM) domain database.

The size of the SAM database file matters because the entire database is made resident in a domain controller's RAM. Large SAM databases have two effects: they hog a lot of the domain controller's RAM, and they take a long time to load, prolonging the process of booting the computer.

Three types of objects are stored in the SAM domain database:

• User accounts use 1,024 bytes (1 KB) each.
• Computer accounts use 512 bytes (0.5 KB) each (only Windows NT computers require computer accounts).
• Global group accounts use 512 bytes plus 12 bytes per users.
• Local group accounts use 512 bytes plus 36 bytes per user.

Assume that you have 1,000 users and 500 NT computers that require accounts. To organize the domain, you require 10 global groups with an average membership of 200 users. You also require 10 local groups with an average membership of 20. How large a SAM database would that generate?

1,000 users: 1,024 bytes=1,024,000 bytes
512 computer accounts: 512 bytes=262,144 bytes
10 global groups: 512 bytes=5,120 bytes
2,000 global group members: 12 bytes=24,000 bytes
10 local groups: 512 bytes=5,120 bytes
200 local group members: 36 bytes=7,200 bytes
Total SAM database size=1,324,589 bytes

The total size of the SAM database would be approximately 1.5 MB. That's not particularly large as SAM databases go, and you can easily support this network in a single domain.

Depending on its processing power and on the services it provides, a domain controller can support between 2,000 and 5,000 users. A domain with 26,000 users, therefore, might require from 6 to 13 domain controllers to ensure adequate performance.

These two factors (the maximum size of the domain database and the number of users a given domain controller can support) suggest some situations that might make it desirable to design a multi-domain network.

Microsoft recommends that a SAM domain database file not exceed a size of 40 MB. Above this limit, performance is likely to be unacceptable. Of course, performance depends on the power of the computers that are functioning as domain controllers, and less powerful servers will probably require you to further limit the size of the domain database. Regardless of the server platform, however, it is unlikely that you will want the database size to exceed 40 MB.

How large is a 40 MB SAM database? It will accommodate approximately 26,000 users, 26,000 workstations, and 250 group accounts.

A 40 MB SAM database is practical only on high-performance hardware. Table 9.1 offers some suggestions on the hardware required to support SAM files of varying sizes.

TABLE 9.1: Selecting Domain Controller Hardware

If the SAM database for your planned domain exceeds the recommended capacity for your hardware, you should partition your network into two or more domains.

Domains and Workgroups

Microsoft has designed its network products so that users and network administrators can use a mix of peer-to-peer and centralized services. Users can participate in a workgroup at the same time they are logged on to a Windows NT Server domain. This capability enables you to mix formal and informal network services to meet the needs of your users. It also enables you to manage some resources centrally, while other resources are shared under user control.

Mixing workgroup and domain models can complicate your life as a LAN administrator, however. When a user reports a problem, it might be unclear whether the problem is related to the Windows NT Server network or to the user's workgroup. My recommendation is that you use a centralized approach whenever possible.

Files can always be shared simply by placing them on a network server. Although Windows for Workgroups users cannot share their printers with a Windows NT Server network (except through peer-to-peer resource sharing in a workgroup environment), users of Windows NT Workstation can configure their workstations as network print servers, enabling them to share their printers as domain resources. Thus, most of the resource sharing that is made possible by workgroups also is possible under domain management. Windows NT Server domains are, however, much easier to manage and troubleshoot.