PDCs, BDCs, and Trust Relationships

More NT fundamentals for the security-savvy administrator

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.

Administrators concentrating on the latest high-tech security solutions too often neglect to consider the security effects of such basic concepts as domain organization. As I explained in the first article in this series, "NT Security Fundamentals," August 2001, even Windows NT —security veterans can firm up their understanding of NT's inner workings. The placement of PDCs, BDCs, and non—domain controller (DC) systems; the use of DCs for additional purposes (e.g., running Microsoft Exchange Server); and trust relationships all affect your network's security at the most basic level. To boost security, familiarize yourself with these factors and make planning your network around them second nature.

BDCs: Why, Where, When?
An NT domain typically consists of one PDC, one or more BDCs, member servers, and workstations. The PDC's SAM database is the central SAM for the whole domain. That SAM is the repository for all domain user and group accounts and holds the audit and account policy that the PDC and BDCs use. BDCs simply maintain a read-only copy of the PDC's SAM. (For more information about the relationship between the PDC and BDCs, see L. J. Locher, "Understanding PDCs and BDCs," January 2000.)

You need BDCs for two reasons. First, BDCs provide fault tolerance. When member servers or workstations need to confirm usernames and passwords, they look for an available DC, whether it be the PDC or a BDC. Therefore, if the PDC goes down but a BDC is available, read-only DC operations—most important, logons that use domain accounts—still succeed.

Second, BDCs help maintain response time when many users are logging on simultaneously. Microsoft recommends one BDC for every 2000 users. You might be able to increase the number of users per BDC, depending on your network, user habits, and DC hardware.

But the number of BDCs that you have in place is only one part of a successful NT domain implementation. Three physical aspects of each BDC are as important as how many BDCs you have. First, you need to physically secure each BDC. Even when you've securely configured an NT DC, an attacker who has physical access to the system can combine @stake's L0phtCrack, Petter Nordahl-Hagen's Ntpasswd, and Todd Sabin's Pwdump2 utilities to get all the passwords in the domain.

Second, you need to distribute your BDCs properly with regard to routers and switches. To boost logon performance, distribute the BDCs throughout your domain so that each BDC serves roughly equal numbers of member computers.

Third, you need to consider which locations provide the best fault tolerance in a WAN environment. For example, suppose your domain comprises two sites: one in New York and one in San Francisco. The domain has one PDC and one BDC, both of which physically reside in New York. The workstations and servers in San Francisco use a WAN link to connect to the New York site. This configuration provides fault tolerance in case the PDC goes down—but what if the WAN link becomes unavailable? Users in San Francisco won't be able to access their local servers, even when the San Francisco LAN is functioning. For this reason, you should deploy at least one BDC at each physical site that hosts both servers and workstations. That way, if a WAN link goes down, users can still perform tasks and use applications that involve their local servers.

When a site hosts only workstations, you don't need a BDC for logon fault tolerance. By default, NT stores the credentials of the last 10 successful interactive logons in each system's registry. Therefore, users can use their domain accounts to log on interactively to their workstations even when a DC isn't available. However, deploying a BDC at sites with many workstations might help you gain a WAN performance advantage. Because workstations will use a local BDC instead of accessing a DC over the WAN, you can often reduce the amount of DC traffic on your WAN and save valuable bandwidth. In this scenario, the only WAN traffic between the local site and the site that hosts the PDC should be PDC-to-BDC replication traffic. (This scenario might not be appropriate for workstation-only sites that are part of a much larger companywide domain but host only a few workstations. In those situations, the replication traffic necessary to support a local BDC would likely exceed the logon traffic the WAN would need to carry if no local BDC existed.)

BDCs and the PDC: Staying in Sync
To help you maintain a domain, Microsoft packages two tools with NT: User Manager for Domains and Server Manager. You can use User Manager for Domains to maintain users, groups, account and audit policy, user rights, and trust relationships. You can use Server Manager to initiate immediate domain replication and promote or demote DCs.

Regardless of whether you open User Manager for Domains from a BDC, a member server, or a workstation, the tool locates and connects to the PDC. Therefore, when you use User Manager for Domains to make a change to the domain SAM (e.g., to create a user account), the tool always records the change on the PDC. Usually, NT takes about 5 minutes to replicate changes from the PDC to BDCs. However, replication scheduling is a complicated process, and a change you make in User Manager for Domains can take some time to become visible to a user whose workstation uses a BDC (e.g., a user at a remote site).

You can tweak replication scheduling through several registry values under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters registry subkey. (For more information about these values, see Tim Daniels, "General System Registry Secrets," http://www.WindowsITlibrary.com/content/69/01/5.html.) If you simply want to force an immediate replication to a specific BDC, open Server Manager on any computer and select the BDC. From the menu bar, select Computer, Synchronize with Primary Domain Controller. The BDC immediately pulls any recent changes from the PDC. (To force synchronization of all BDCs, select the PDC, then select Computer, Synchronize Entire Domain. You should avoid this type of synchronization on a domain with many BDCs, however, to conserve network bandwidth and maintain the PDC's responsiveness.)

BDC Promotion
The time might come when you want to promote a BDC to PDC status. When a PDC goes down, users can't change their passwords, the Help desk can't reset passwords or unlock accounts, and of course administrators can't make any domain changes. However, whether you should promote a BDC when your PDC goes down depends on the situation. If the PDC is going to be down for only a short time, you might not need to promote a BDC—especially for a small domain in which users probably won't notice the interruption. If you support thousands of users, though, you might need to promote a BDC to prevent interruption of service, regardless of the situation. (For a detailed discussion of the planning and steps involved in replacing a PDC, see Melissa Wise, "10 Steps for Replacing Your Aging PDC," March 15, 2001.)

To promote a BDC, open Server Manager, select the BDC you want to promote, then select Computer, Promote to Primary Domain Controller from the menu bar. When you promote a BDC to replace a functioning PDC, NT automatically replicates any recent changes to the selected BDC, demotes the outgoing PDC to a BDC, then promotes the selected BDC to be the new PDC. Therefore, you don't need to synchronize the domain before you promote a BDC to replace a functioning PDC.

If the outgoing PDC isn't functioning, NT can't demote it during the BDC-promotion process. Therefore, when the original PDC comes back up, it announces itself as the PDC, then discovers that a newer PDC is present. Contrary to popular belief, the original PDC doesn't automatically demote itself in this situation. Instead, the original PDC goes into a dormant mode (i.e., it doesn't serve authentication requests or share in replication). You must then manually demote the original PDC.

In this double-PDC situation, when you open Server Manager on the original PDC, it should display two PDCs: the new PDC and the original PDC. The original PDC's icon will be dimmed, which indicates that the Netlogon service hasn't started on that machine. (The Netlogon service provides DC functionality; because it doesn't start on the original PDC, you don't need to worry about that PDC corrupting domain replication or interfering with authentication requests.) To demote the original PDC, select the original PDC, then select Computer, Demote to Backup Domain Controller from the menu bar. The original PDC gets a fresh copy of the new PDC's SAM and begins functioning as a BDC. At this point, if you wish to go full circle and return the original PDC to its primary role, simply promote it as I described earlier.

A hitch exists in this simple process, however. In a double-PDC situation, Server Manager sometimes reports the original PDC as a BDC, even though you haven't yet manually demoted it. (The original PDC's icon will still be dimmed, and the Netlogon service won't start on the original PDC.) You can't demote the original PDC until Server Manager displays it as a PDC. In this situation, you need to click View, Refresh or possibly reboot the original PDC before Server Manager will display it as a PDC and let you demote it. Furthermore, Server Manager occasionally refuses to let you demote the original PDC and gives you only the option to demote the new PDC. Don't take the easy road; if you demote the new PDC, you'll lose any changes you made since promoting it. Instead, you'll need to reinstall NT on the original PDC and select the system as a BDC during installation. The possibility of encountering this problem reinforces the importance of dedicating your DCs to one purpose only: being a BDC or PDC.

Dedicated DCs
Technically, NT DCs can also serve as file and print servers or can host application services such as Oracle, Exchange, Microsoft IIS, or Microsoft SQL Server. However, for all but extremely small domains (i.e., those with two or three servers), I recommend that you dedicate your DCs to being only DCs. Aside from simplifying reinstallation if you have a PDC demotion problem, dedicating your DCs can forestall several potential security worries.

All the BDCs in a domain copy the same SAM from the PDC; thus, all the BDCs share the same audit policy that you defined for the PDC through User Manager for Domains. If you use a BDC for other services, you can't enable different audit policies to fit those other uses. This restriction can lead to a serious security problem.

A second, even more severe problem has to do with administrative authority. All DCs in a domain share the same local Administrators group. Therefore, you can't grant someone administrator authority over only one DC. Consider the domain that Figure 1 shows. The domain has a PDC and four BDCs, but each BDC handles a second role as well. Tom, the IT department's Exchange guru, administers BDC1, which runs Exchange. Alice, who is in the finance department, administers BDC2, which also serves as an Oracle financials server. BDC3 is also an IIS server that maintains human resources (HR) information on the company's intranet; Sally in HR administers BDC3. BDC4 also runs IIS and serves as the company's public Web server; Harry, an outside contractor, administers this BDC.

To perform their jobs, these administrators each need administrator authority on their local BDCs. Obviously, though, none of the administrators should have administrator authority on the other BDCs. But because only one Administrators group exists in the PDC's SAM, you end up with several administrators having inappropriate authority to BDCs. Harry, the outside contractor, has full authority to the domain SAM, company email, HR information, and even the company's financials—as do the other application-server administrators. Although being a member of the local Administrators group doesn't give you direct administrative authority over member servers and workstations, you can use your authority to add yourself to any Domain Administrators group, which in turn gives you administrator authority over every computer in the domain. The fact that BDC4 is a public Web server presents the greatest risk. If an intruder compromises that server and obtains administrative access, he or she can then access the entire domain.

Whom Can You Trust?
Account management is simple in a single-domain network: You can grant a user access to any domain resource through the user's domain account. Things get a little more complicated when your network comprises multiple domains. Suppose a user, Fred, has a domain account in Domain A. Fred can use this account to access resources in Domain A. But if Fred needs access to resources in both Domain A and Domain B, he needs two user accounts—one for each domain. However, creating multiple user accounts for one person is generally a bad idea from a security standpoint (as I discussed in "NT Security Fundamentals").

To solve Fred's problem without creating multiple user accounts, you can create a trust relationship that links Domain A and Domain B. Figure 2 shows such a relationship. Domain A is the trusted domain and Domain B is the trusting domain. When a user with a user account in a trusted domain requests access to a resource in a trusting domain, the trusting domain's DCs rely on the trusted domain's DCs to vouch for that user account's authenticity.

You can use the trust relationship between Domain A and Domain B to grant Fred's user account (in Domain A) access to resources in both domains. When Fred maps a drive to a member server in Domain B, his workstation sends his Domain A user credentials to the member server. That server forwards the credentials to a DC in Domain B. That DC recognizes that the credentials come from a trusted domain and forwards them to a DC in Domain A. That DC checks the credentials against the domain SAM and returns the result to Domain B's DC, which relays the result to the member server.

The trust relationship that Figure 2 shows grants Domain A users access to resources in Domain B but doesn't grant Domain B users access to resources in Domain A. To permit that type of access, you need to create another trust relationship that flows in the opposite direction.

To manage trust relationships, open User Manager for Domains and select Policy, Trust Relationships. The resulting Trust Relationships dialog box lists both trusted and trusting domains for the named domain.

Creating a trust relationship is a two-step process that involves administrators in both domains. Typically, an administrator in the domain that wants to be trusted initiates the trust. To do so, she first creates her half of the trust in her domain. In the example that Figure 2 shows, an administrator in Domain A would open the Trust Relationships dialog box and click Add, to the right of the Trusting Domains list. NT then prompts the administrator to enter the name of the domain (i.e., Domain B) to add to Domain A's Trusting list and to enter a password. This password has nothing to do with the administrator's user account; it's a separate password for authenticating the trust's initial creation.

After Domain A's administrator completes these steps, she notifies Domain B's administrator that she has completed her part of the trust relationship and gives Domain B's administrator the password to authenticate the relationship. Domain B's administrator opens the Trust Relationships dialog box and clicks Add, to the right of the Trusted Domains list. NT then prompts Domain B's administrator to enter the name of the domain (i.e., Domain A) to add to Domain B's Trusted list and to enter a password. Domain B's administrator needs to enter the same password that Domain A's administrator used. If the passwords match, NT completes the trust relationship and reports success.

The creation of a trust relationship doesn't automatically open all the resources in the trusting domain to access by users in the trusted domain. Administrators in the trusting domain must still explicitly grant user or group access to specific resources. And administrators in one domain don't have administrator access in other domains even when trust relationships link the domains. However, when you grant access to the Everyone group, you actually grant access to all users in any trusted domains as well as all users in your domain. Therefore, you're trusting more than the trusted domain's DCs—you're trusting that domain's administrators. You're relying on those administrators to manage their user accounts securely and honestly. For example, if the trusted domain's administrators don't require difficult-to-guess passwords or establish a strong lockout policy, attackers might be able to invade accounts in that domain and thus access resources in your domain. Also, unscrupulous administrators in a trusted domain can impersonate any user in their domain and thereby access your resources. If another domain administrator's security standards don't meet or exceed your own, perhaps you shouldn't trust that domain.

When you're comfortable with the logistics of trust relationships, you can arrange them to create a domain model that fits your network's security needs and risks. In my next article, I'll explain that process.