A Model Network

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