Locating Domain Controllers


After the sites and site links have been determined, your next step is to determine the location of domain controllers in the sites. For each site in the Active Directory infrastructure, you must determine the domain controllers required as well as the number (some sites require more domain controllers than others).

When you're assessing the need for servers, you should determine the placement of domain controllers, Global Catalog Servers, Operations Masters, and DNS servers throughout the site topology. Table 9.2 summarizes the various server roles in sites, each of which is covered in this section.

Table 9.2. Summary of the Server Roles in an Active Directory Site

Server

Role

Domain controller

A computer running Windows 2000 that is responsible for logon authentication and controlling access to network resources.

Global Catalog Server

A server that maintains a copy of the Global Catalog for the entire forest. The Global Catalog contains a subset of the properties for every object in every domain.

Operations Masters

Servers that have been specifically assigned specific roles, such as Schema Master and Domain Naming Master. These roles are exceptions to the multimaster design of Windows 2000.

DNS servers

Servers that are responsible for resolving domain names to IP addresses.

Standard Domain Controllers

Domain controllers are responsible for authenticating user logon requests and controlling access to network resources. When you're planning the placement of domain controllers, keep in mind that, to enable users to be authenticated, a domain controller for their domain must be available.

Where domain controllers are placed in the site topology has a major impact on server response time for users. For example, if no domain controller exists in a site, users must locate a domain controller in another site. Response time in a such a situation obviously is slow because users must be authenticated across a WAN link (depending on the reliability of the link, there might be no response at all).

When you're determining where to place domain controllers, a good rule of thumb to follow is to place at least one domain controller in each site that contains users and workstations. This enables users to take advantage of the high-speed links in a site, as opposed to having to be authenticated across a slow, unreliable WAN link.

The only time you would choose not to put a domain controller in a site is if the site has a very small number of users. In cases such as this, it might be more cost effective ”both in terms of bandwidth and hardware costs ”to have users access a domain controller in another site.

When a user first logs on to a Windows 2000 network using a Windows 2000 client, any domain controller for that domain can be returned by DNS. Client computers are not site aware, so they have no way of asking for a domain controller in the site.

The authenticating domain controller compares the IP address of the client against the Active Directory site and subnet information to ensure that it should be validating the logons for this particular computer. If it is determined that another domain controller would be a better choice, the initial domain controller validates the logon request and then passes a referral back to the client computer that suggests a closer domain controller. The client then attempts to contact the closer domain controller and caches the location for future use.

The referral processes is important because access to network resources is now controlled through Kerberos and the Key Distribution Center (KDC). Every Windows 2000 domain controller runs both Kerberos authentication and KDC services. Whenever a user wants to access a network resource, a Kerberos session ticket must be issued. Obviously, tickets are issued more efficiently if a local server is contacted, rather than one across wide area links.

After you've determined the placement of domain controllers, you have to determine the number of domain controllers required in each site. Consider placing at least two domain controllers in each site for load balancing. This way, one server isn't solely responsible for servicing client requests in the site. You also need to assess the number of client requests in a site to determine whether another is necessary for load balancing.

If users must log on to a domain controller across a WAN link, consider configuration of a backup link ”perhaps a dial-on-demand router ”to ensure access to network resources.

Global Catalog Servers

A Global Catalog Server stores certain information pertaining to every object in an Active Directory forest. When a user is searching for objects in the forest, a Global Catalog Server can be queried to determine the location of the object. This eliminates the need for users to perform an extensive search of all domains when trying to locate an object in the forest.

Because access to a Global Catalog Server is required for successful logon, it is important to have at least one Global Catalog Server per site. The Global Catalog Server is needed to enumerate universal group membership, and the logon process fails if a Global Catalog Server cannot be reached.

After you have determined which sites will contain Global Catalog Servers, you must determine how many will be required in each site. Generally, a single server should suffice for all but the largest of sites. Servers hosting a Global Catalog (GC) have additional Performance Monitor counters available to assist in determining whether additional Global Catalog Servers are necessary.

Operations Masters

As discussed in previous chapters, Windows 2000 implements a multimaster replication model, in which all domain controllers are equal and all maintain an up-to-date working copy of the directory. In some instances, though, it does not make sense to have certain information replicated using this model. Specific servers can be designated as an Operations Master, meaning these servers are responsible for those updates that cannot be replicated using the multimaster model.

The five Operations Master roles are Schema Master, Domain Naming Master, Primary Domain Controller Emulator, Relative Identifier (RID) Master, and Infrastructure Master. Table 9.3 summarizes the role of each Operations Master.

Table 9.3. Summary of the Operations Masters in Active Directory

Operations Master

Role

Schema Master

The master copy of the schema is stored on this server. All schema modifications update the Schema Master first and then are replicated to the other domain controllers in the forest.

Only one Schema Master exists per forest.

Domain Naming Master

This master is responsible for the addition or removal of domains. When a new domain is added, it verifies that the domain name does not already exist.

Only one Domain Naming Master exists in a forest.

Primary Domain Controller Emulator

This is the server that acts as a Windows NT 4.0 PDC to remain backward compatible with any Windows NT BDCs on the network. In addition, password changes made to any domain controller in the domain are pushed to the PDC Emulator. During logon, if a password mismatch occurs, the PDC Emulator is checked to determine whether a password change has occurred that has not replicated to all other domain controllers yet. Finally, the PDC Emulator is the default server used by the Group Policy Editor MMC snap-in.

There can be only one PDC Emulator per domain.

Relative Identifier Master

This is responsible for assigning series of numbers known as relative IDs to the domain controllers in its domain (the relative ID is used to create SID numbers). The RID Master role is critical because, unlike in Windows NT, new security accounts can be created on any domain controller in a domain. By assigning a pool of RIDs to every domain controller, unique SIDs can be guaranteed .

There is one RID Master per domain.

Infrastructure Master

This is responsible for updating security information across domains anytime a change is made to a security group. Without an Infrastructure Master, domain local groups, for example, might not show correct information for global group members from other domains.

There can be only one Infrastructure Master per domain. Note that this role must not reside on a server that also hosts the Global Catalog.

Keep the following points in mind when planning Operations Master roles:

  • The first domain controller in a forest is assigned all five roles. These roles can be moved as needed.

  • The Schema Master should be moved to a DC that is physically closer to the users responsible for schema administration.

  • The three domain roles (PDC Emulator, RID Master, and Infrastructure Master) should be located centrally in a domain to minimize router hops. If you have a domain spread over three sites, put them where the largest number of users and DCs can get to them with as few hops as possible.

  • A server should be designated as a backup Operations Master to eliminate some confusion if an existing Operations Master fails and the role must be transferred to another server. There is no special Windows 2000 artifact to identify a backup Operations Master; a small hand-lettered sign will do.

graphics/alert_icon.gif

Be sure to understand the functions of each Operations Master role, and know which Operations Masters are forest-wide versus domain-wide in scope.


DNS Servers

As you already know, Windows 2000 has adopted the DNS naming convention for naming objects in Active Directory. This means that a DNS server must be available at all times for users to resolve information pertaining to DNS names.

Ideally, you should plan to place at least one DNS server in each Active Directory site because they are required by users to locate domain controllers. This improves the query response time for users because they do not have to query a DNS server from another site to locate servers in their own site.



MCSE Active Directory Services Design. Exam Cram 2 (Exam Cram 70-219)
MCSE Windows 2000 Active Directory Services Design Exam Cram 2 (Exam Cram 70-219)
ISBN: 0789728648
EAN: 2147483647
Year: 2003
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net