EDITOR'S NOTE: This series of articles, "NT Security Fundamentals," is adapted from Audit and Security of Windows NT Server, a course Randy Franklin Smith wrote for MIS Training Institute.
In "PDCs, BDCs, and Trust Relationships," September 2001, I discuss Windows NT domain controller (DC) roles and the logistics of the trust relationships that you can establish between NT domains. To put this knowledge to its best use, don't create domains or trust relationships haphazardly151;organize them according to one of four domain models: single domain, complete trust, master domain, or multiple master (aka multi-master) domain.
When choosing a model, you need to consider your network's administrative structure, number of users, and security needs. If one of the more complex domain models is the best fit, don't be reluctant to implement it for fear of replication-related problems. You can tweak the registry to ensure that your PDCs replicate to your BDCs in a timely fashion without taking up too much network bandwidth.
Deciding Factors
Several factors come into play when you consider which domain model best fits your needs. Which model you should use depends on how your company administers groups, users, servers, and workstations; how many users your network has; and whether you need to isolate some sensitive resources.
Administrative structure. Does one IT team administer all user accounts and groups, or is the chore split among IT groups according to division or region? Do multiple IT teams administer servers and workstations? Some organizations centralize user-account administration but assign management of computers at remote sites to administrators at those sites.
Number of network users. Each user and computer takes up storage in a PDC's SAM; the SAM's storage space is limited, so an NT domain can hold only so many users. Large organizations require multiple domains simply because of the number of users on the network. I recommend that you maintain no more than 15,000 users per domain (although I do know of companies that successfully manage 20,000 users in one domain).
Isolation of sensitive resources. Do you need to maintain a separate subset of computers to host highly confidential information or sensitive resources? Some domain models make consistent security standards difficult to maintain, whereas other models involve trust relationships that help improve security.
The Single Domain Model
A single domain NT network, which Figure 1 shows, is simple: centralized user-account administration, no trust relationships to manage, and only one domain security policy to maintain. For large organizations or companies with multiple geographic locations, however, the single domain model isn't a possibility. Such companies seldom use only one IT team to handle user-account administration. A company with offices in several cities probably has a team of administrators in each city. Large companies are especially likely to be geographically split (or simply have too many users to fit in one domain). NT offers no way to subdivide a domain and give administrative teams separate control over subsets of users. Either you're a member of a domain's Domain Admins group and have full control over users and groups in the domain, or you aren't a member of that group and have no administrative authority. Therefore, organizations that want to split user- and group-account administration must create separate domains for each IT team so that each team has discrete control over users in its jurisdiction.
Some organizations with multiple domains apply the single domain model to one domain to isolate a sensitive department from the rest of the organization. However, this ploy can produce a false sense of security, as the sidebar "Not as Safe as You Think," page 60, explains. If you want to keep users out of a certain area of your network, you need an internal firewall as well as a separate domain.
The Complete Trust Model
The complete trust model is a likely option for organizations that have a separate team of administrators for each autonomous department or location. Each division maintains a separate domain that contains the users and computers in that division. To let a user in one domain access information in other domains, the model specifies that you create 2-way trust relationships between all domains, as Figure 2 shows. The number of trust relationships equals y(y-1), where y is the number of domains in the network.
The complete trust model is extremely scalable. Each domain can hold thousands of users, but because all domains trust one another, a user needs only one account to access resources anywhere in the network. However, this model can result in a lot of trust relationships. For example, to implement the model for a seven-domain network, you'd need to define 42 trust relationships.
The complete trust model is prone to inconsistent security standards. The other domain models limit the number of domains that can contain user accounts, but in the complete trust model, each domain contains user accounts, and a different IT team administers each domain. Each domain in the complete trust model has a separate lockout policy, audit policy, and password requirements. As I explained in "PDCs, BDCs, and Trust Relationships," when your domain trusts another domain, you trust the other domain's administrators to manage their user accounts as carefully as you manage yours. Suppose you create a trust relationship with another domain and grant a user from that domain access to resources in your domain. Later, your company terminates the user, but the administrators in the trusted domain neglect to disable his or her account. Your domain is vulnerable to malicious acts from that user. Similarly, when you grant access to a global group from another domain, you must rely on that domain's administrators to keep the group's membership up-to-date.
Another potential problem with this model involves password requirements. If the administrators in the trusted domain don't enforce strong passwords, an attacker might guess the password of a user in that domain, then use the breached account to compromise resources in your domain.
If the security standards in a trusted domain don't meet or exceed the security standards in your domain, you're vulnerable. You might decide that you're safer creating and maintaining secondary user accounts in your domain for other domains' users who need access to your domain's resources. However, this option also involves risks: If those users are in remote departments or locations, you might have difficulty staying on top of user terminations or changes in user status.
The Master Domain Model
Organizations that centralize user-account management under one IT administration team but split up computer administration by department or location are good candidates for the master domain model. This model, which Figure 3, page 60, shows, stipulates that one domain holds all the users and global groups for the organization but doesn't hold any computer accounts (other than those for the domain's DCs). The central IT administration team owns this master domain and manages all user and group accounts.
You then create a resource domain for each division. Each resource domain contains the workstations and servers in that division but contains no user accounts. Separate administrative teams handle each of these domains. In this way, each team has control over its division's resources, but one centralized team consistently manages users and groups.
Each resource domain trusts the master domain but doesn't need to trust other resource domains because the resource domains don't contain any users. Because all the resource domains trust the master domain, each user needs only one master domain user account to access resources in any domain.
Depending on how you manage administrative authority for the resource domains, you might make an exception and create user accounts in a resource domain for the administrators of that domain. Suppose Tom is an administrator of a resource domain. You can make Tom's master domain account a member of the Administrators group in his resource domain, but the other master domain administrators could then crack Tom's password and use his account to gain administrator access to his resource domain. If preventing master domain administrators from gaining administrator access to the resource domains is important in your environment, each resource-domain administrator will need a user account in his or her resource domain.
Maintaining consistent password and lockout policies among resource domains isn't vital in the master domain model because the master domain is generally the only one that contains user accounts. For the same reason, however, this domain model isn't scalable beyond 15,000 (or perhaps 20,000) users.
The Multi-Master Domain Model
The multi-master domain is an alternative for organizations that want to employ centralized user administration but can't use the master domain model because they have too many users to fit in one domain. As Figure 4, page 62, shows, this model is identical to the master domain model but has more than one master domain. Each resource domain trusts all the master domains. You can create trust relationships between the master domains so that one team of administrators can manage all the master domains. To accomplish this task, select one master domain to be a super-master domain, create the administrator accounts in the super-master domain, make those accounts members of the super-master domain's Domain Admins group, then add the Domain Admins group to the local Administrators groups in the other master domains.
The multi-master domain model is also a good option for organizations with partially centralized user-account administration. For example, a company with plants throughout North America and Europe might want to use two IT teams--one team in North America and one team in Europe--to manage user administration. That company can create two corresponding master domains to hold users from the plants on each continent.
Tuning Replication
You can see that the more complex domain models are often the most appropriate for companies with many users. However, the more users or sites in your network, the greater the chance that the default values of NT's PDC-to-BDC replication parameters won't be sufficient to prevent bandwidth problems. In small and midsized networks, NT does a good job of keeping BDCs up-to-date without clogging the network, but larger networks can run into trouble. However, don't let that concern prevent you from implementing the model that provides the best security for your network. You can fine-tune the NT replication parameters and optimize the replication process to prevent or minimize replication-related troubles. The parameters appear in the registry as values under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
subkey. (For more information about these registry values, go to
http://www.microsoft.com/technet/winnt/winntas/technote/implemntintegra/
ntopt4.asp.)
Each computer maintains a machine account in the domain; by default, the password for this account changes every 7 days. The MaximumPasswordAge value controls the frequency of the change. When a domain contains many member computers, these changes can keep the PDC busy and tie up bandwidth while the PDC replicates the changes to each BDC. To reduce this replication load, you can increase the MaximumPasswordAge value on the member computers. The minimum value is 1 (day) and the maximum value is 1,000,000 (days).
You can also disable machine-account password changes. To do so, set the RefusePasswordChange value to 1. However, this change doesn't stop your systems from regularly bothering the PDC with password-change requests. To prevent computers from requesting password changes, set the DisablePasswordChange value to 1 on each member computer. (I recommend against setting this value to 1 on your servers because it might make them more vulnerable to an attacker using another computer to impersonate the server.)
By default, the PDC checks its database every 5 minutes (i.e., 300 seconds) for changes to domain users, groups, or policies. When the PDC finds a change, it sends a message to each BDC that new information is available for replication. The BDCs then contact the PDC and request replication. You can use the Pulse value on the PDC to adjust how frequently the PDC checks for changes and notifies BDCs.
To prevent all BDCs from clamoring for changes simultaneously and overloading the PDC, the PDC notifies only a certain number of BDCs at a time. The PulseConcurrency value on the PDC controls this number and defaults to 10. If you have many updates occurring every minute and many DCs, you might need to increase this value so that BDCs receive updates in a timely fashion. However, doing so also increases the load on the PDC.
After pulsing a BDC, the PDC waits a certain period of time for the BDC to respond. The PulseTimeout1 value on the PDC controls this period. The value can range between 1 and 120 (seconds) and defaults to 10. An unresponsive BDC doesn't apply toward the number of BDCs that the PulseConcurrency value specifies, so the PDC can move on to a BDC that's operational and ready for replication. In a slow network environment, such as a network with slow or clogged WAN connections, you might need to increase the PulseTimeout1 value on the PDC so that the PDC doesn't prematurely evaluate a BDC as unresponsive. Otherwise, the PDC might end up replicating to too many BDCs at the same time.
After the PDC initiates replication, the BDC drives the process by repeatedly requesting the next chunk of replication data from the PDC. A BDC might crash or shut down in the middle of this process; the PulseTimeOut2 value on the PDC controls how long the PDC waits for the BDC to request the next chunk. You can set the value to a minimum of 60 (seconds) and a maximum of 3600 (seconds); the default is 300. If you set the value too low, you end up with too many BDCs requesting changes from the PDC at the same time. In this situation, the PDC can't keep up; you might need to set the value higher so that the PDC can handle the load and replicate in an orderly, timely fashion.
The PDC periodically pulses the BDCs even when no changes have occurred. This pulsing can cause unnecessary traffic if you have many DCs spread out over a WAN. The PulseMaximum value on the PDC controls this behavior; the default is 7200 (seconds151;i.e., 2 hours). You can set the value to a minimum of 60 (i.e., 1 minute) and a maximum of 86,400 (i.e., 24 hours).
The PDC breaks replication changes into blocks and feeds each block to the BDC as it requests the data. You can adjust the ReplicationGoverner value on the BDCs to control how much bandwidth replication uses. ReplicationGoverner is specified as a percentage (the default is 100) and controls the rate at which BDCs request data blocks.
The PDC holds changes to the domain database in a log. The ChangeLogSize value on the PDC controls the log's size and defaults to 65,536 (bytes151;i.e., 64KB). In large domains in which many changes occur simultaneously, the log can fill up. When the log is full, the PDC can't record any more changes in it and loses track of which changes the BDCs have received. The PDC then must replicate the entire database to the BDCs151;creating yet more network traffic. You can increase the size of the log to a maximum of 4,194,304 (i.e., 4MB), but be aware that doing so consumes both disk space and RAM.
A Model of Security
The larger your network, the more important your choice of domain model is. Take into account the models' various boundaries of administrative authority and how your company organizes user and computer administration. Consider the models' various risks and the security standards of other domains before deciding how to establish trust relationships. And tune replication if you choose a model that specifies multiple domains, especially if your network has many users or BDCs. (For more information about domain models and trust relationships, see L. J. Locher, "Trusted and Trusting Domains in NT 4.0," December 1999.)
