PDCs, BDCs, and Trust Relationships

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

   Previous  [1]  2  3  Next