|
|
The proper implementation of the Active Directory requires forethought and planning. Chapter 3 outlines many of the basic planning issues involved in the installation or upgrade of Windows Server 2003. Since these issues apply equally to the Active Directory, we strongly advise you to review that chapter in conjunction with the discussions here. In this chapter, you will learn the importance of planning for the creation of namespaces, domains, sites, and organizational units. As discussed in Chapter 4, such planning is based on the system administrator's knowledge of the current IT infrastructure, business computing requirements, anticipated change or growth, and available connectivity and bandwidth.
The Domain Name System (DNS) is an industry standard name-resolution vehicle that the Internet uses to match IP addresses to specific namespaces, like ours, EntCert.com. Since domains and domain trees are defined by a common namespace based on DNS, the importance of establishing this strategy early is key. At the least, a baseline understanding of DNS and domain name registration is required prior to the installation of the Active Directory. For additional information on DNS, including its installation, refer to Chapter 12, "Networking Basics and Naming Services."
Defining namespaces is based on an understanding of the organization's current and projected structure, growth, and relationship with related organizations. In most cases, a single domain name can accommodate even very large organizations. However, it can also be used to create child domain relationships where such division is necessary. The child name is a single, descriptive text string that is added to the front of the domain name and separated from it by a period. Child domains can have children of their own. In this case the child name is added before the parent name, again separated by a period, giving the syntax child2.child1.domain.com. A child domain name should be fairly generic. Locations or broad, functional descriptive names are generally good choices. For example, for the domain EntCert.com, a location—asia.EntCert.com—or a function—sales.EntCert.com—is broad enough. The objective is to create child domain names that can survive over time.
Where multiple domain names are required or forced on an administrator because of preexisting names (such as when two companies merge but maintain separate identities), forest relationships need to be established. The forest is created by joining two-way transitive trusts multiple domain trees with different DNS namespaces. Separate identities are maintained while transitive trusts to network resources are provided.
New to Windows Server 2003, the DNS feature will not be noticed by the administrator if it is properly configured. However, in the event of a problem, this feature should make debugging and reporting easier. It should also help guide the administrator through a proper configuration setup. When DC promotion occurs with an existing forest, the Active Directory Installation Wizard contacts an existing DC to update the directory and replicate from the DC the required portions of the directory. If the wizard fails to locate a DC, it performs debugging and reports what caused the failure and how to fix the problem. In order to be located on a network, every DC must register in DNS DC locator DNS records. The Active Directory Installation Wizard verifies a proper configuration of the DNS infrastructure. All DNS configuration debugging and reporting activity is done with the Active Directory Installation Wizard.
Another important namespace issue is whether the domain name will be extended for both internal and external use. In the first case, the goal is a single user logon for all Internet and intranet communications. To achieve this end, the system administrator must create two DNS zones: the first resolves the name for internal resources; the second resolves names for external mail systems, Web services, TCP, news, and Telnet connectivity.
In the second case, an organization may choose different domain names for internal and external use. If so, two namespaces must be reserved and domain trees created to manage the respective resources, and transitive trust relationships must be formed by grouping the trees into a forest. This approach to domain naming increases administrative tasks. However, each user should maintain a single logon name.
A new feature available with Windows Server 2003 supports changing the DNS and/or NetBIOS names of existing domains in a forest. As organizations change, the ability to rename a domain permits the resulting forest to be "well-formed." A renamed domain retains its underlying domain globally unique identifier (GUID) and its domain security ID (SID). A computer's domain membership does not automatically change as a result of the holding domain's being renamed. It is important to note that although a forest root domain can be renamed, a different domain cannot be designated to become the new forest root.
This feature is primarily used when an organization changes its name or when an organization is merged with another corporation.
Although it is now possible to rename the domain, it comes with a little bit of administrative pain. For example, every member domain controller must be rebooted and every member server must be rebooted twice. This extra procedure is in place so that domains are not renamed casually.
The underlying objectives of the physical structure are easy Active Directory replication, rapid user logons, and efficient resolution of queries for network objects. When planning the physical structure, and site topology in particular, remember that there is no direct relationship between sites and domains. A site can have multiple domains or portions of multiple domains, and vice versa. It is defined by fast and reliable connectivity, so the most critical issue in site planning is the bandwidth and other network constraints for related traffic. This means that site parameters should be dictated by the creation of subnets that share cheap, fast, and reliable connections.
In some cases, two or more remote locations can still be treated as a single site. However, if they are in different area codes and connectivity is based on more expensive connection technologies, the creation of multiple sites is probably in order. Each site should have at least one domain controller that is configured for each location, with replication services set for times when traffic is minimal and at the lowest rates.
Later in this chapter we will explore specific management of intrasite and multisite network traffic and topology. Before that, however, it is important to understand site requirements and site replication and topology.
NOTE
With Windows Server 2003 there is an ability to turn off compression of the replication traffic between domain controllers residing in different sites. This should reduce CPU utilization on the domain controllers and provide greater availability. This feature should be activated when CPU spiking occurs. By not compressing the replication traffic between domain controllers, you should free up CPU cycles.
To prepare for the creation of sites, it is important to understand data transfer and how it works in the Active Directory. There are two forms of data transfer. First, replication is used when Windows Server 2003 domain controllers communicate changes to each other. All domain controllers in a domain tree share a number of traits, including the same schema and control models. When a modification is recorded by one domain controller, it is automatically "replicated" to all other domain controllers in the domain tree according to prescribed scheduling rules. The transitive trust relationships that exist among all domains ensure that new information is written to all domain controllers. This is transparent and fairly rapid within one site. For intersite replication, the system administrator should determine the time and frequency of these updates based on an analysis of network traffic and cost.
Second, synchronization is used for communication between the Active Directory and other directory services such as Novell Directory Services (NDS). To share information, the two services must use an agent known as a security principle, which determines what schema information is common to both and selects the data to be shared. Since the structures of directory services vary, the data must then be mapped. This can be streamlined by directory services that employ LDAP, which provides a common method of resolving object names.
Some large enterprises may have more than a hundred different directory services in place, so planning consideration must be given to both Active Directory replication and heterogeneous synchronization. Clearly, Active Directory does not have the ability to synchronize data with all third-party directory services. However, services that employ both DNS and LDAP v3 are good candidates.
Planning the physical structure requires knowing where replication and synchronization might occur. Where possible, confine synchronization to intrasite topologies where internal traffic is the most reliable. Once the synchronization has taken place between Active Directory and other directories' services within a site, the receiving domain controller can replicate the data to other domain controllers throughout the domain tree.
When updates occur on one domain controller, varying amounts of time can pass before they are replicated to others. This is known as replication latency, and within a site it typically resolves within a few minutes (every 5 minutes by default). Depending on how the system administrator has configured replication among sites, latency can take place every few minutes or at intervals up to a week.
A part of intersite planning is determining how long a site can exist with latent data. In branch offices that perform well-defined activities and are not subject to regular change, latency is not much of an issue and replication can be safely set for a daily update. Since there is an acknowledged latency, the remote domain controller is in a state called loose consistency of Active Directory information. By the same token, a division headquarters site might demand replication from critical sites every half hour.
NOTE
One of the concerns of any administrator should include having an assurance the replication is occurring. A new feature available with Windows Server 2003 is the WMI classes that permit an administrator to view whether replications between domain controllers were successful. At the time this book went to publication, the method for applying these WMI classes was sketchy. However, the Microsoft development team suggested the classes will make it possible for administrators or third-party software developers to develop scripts or applications designed to monitor the health of replication.
The Active Directory's Knowledge Consistency Checker (KCC) automatically establishes the most efficient replication topology. To formulate connection rules, the system administrator must input information that is critical to the calculation of the best connectivity routes. The KCC also dynamically establishes alternative connectivity to other sites in the event that a site has only one domain controller and that system fails.
One-directional connection objects are created by the KCC (or manually by the system administrator). Contained in a domain controller's NTDS settings object, each connection object points in one direction to a replication partner. Two paired connection objects create a bidirectional relationship between the partners. Connection objects replicate the three Active Directory partitions of schema, configuration data, and domain data.
The KCC uses the connection objects to establish a two-directional ring between intrasite domain controllers. It attempts to make connections such that there is a maximum of three hops between intersite domain controllers. When a domain controller receives a change, it notifies its partner domain controllers. Additional partners are then notified after a configurable delay, which is 30 seconds by default. By design, intrasite replication of a change should be passed to all domain controllers within 15 minutes.
Typically, intrasite replication requires minimal intervention by the system administrator. However, he or she must review the intersite topology and make manual changes where appropriate. As we shall illustrate later, topology links can be modified with the Active Directory Sites and Services administrative snap-in, but this requires that the connection objects be manually established. (If the KCC automatically creates the same connection object through its normal analysis of input data, no new manual connection objects are created.) Manual connection objects can never be deleted by the KCC. If they fail, however, the KCC automatically attempts to create a new connection to a domain controller.
The Active Directory Sites and Services administrative snap-in can also be employed to force replications or to execute the KCC manually, as explained later.
While the initial site topology is generally accomplished by the KCC, it is important to know the relative costs of connectivity between sites. It is also critical to define the minimum acceptable frequency of replication; this information is required by the KCC. After Windows Server 2003 is in place, several tools will allow you to analyze those segments that require manual intervention. The typical basis for this review is network traffic. The Network Monitor measures RCP and SMTP traffic between domain controllers, the Performance Monitor measures traffic from a specific server, and the Replication Monitor provides a view of intrasite topology.
New to Windows Server 2003, Active Directory can dynamically host data without affecting network performance. This is accomplished by providing control over the scope of replication and placement of replicas. An application partition is a new type of naming context (NC) used with Active Directory services. This new NC can be organized into a hierarchy of any type of object except security principals (users, groups, and computers). It also can be configured to replicate to any set of domain controllers in the forest. No administration is necessary since this feature is now integral to the Active Directory.
Another use of application partitions relates to the range and replication of the DNS zones. Such DNS data stores result in a reduced number of objects stored in the Global Catalog. By default, as discussed in subsequent chapters, DNS-specific application partitions contain only domain controllers running the DNS server. The strength of this feature centers on the fact that replicating occurs only on the subset of domain controllers specified in the application partition. This is done while enabling replication of the DNS zone to DNS servers running on different domains within an Active Directory forest.
As described in Chapter 5 and later in this chapter, each domain tree offloads important activities to selected domain controllers that perform up to five specialized activities. These operations master domain controllers perform the same activities as their peers plus one or more specialized functions.
Since all domain controllers rely on the information processed by the operations masters, it is important to carefully plan the location of the operations master domain controllers. As a general rule, they should be placed in a site with the best primary and secondary connectivity to the rest of the organization.
Planning for the Active Directory is predicated on an understanding of the organization itself. In centralized frameworks, a single domain may serve all requirements and is obviously the easiest to administer. In larger and decentralized environments, multiple domains are often required. In both cases, it may be most efficient to divide the domain into organizational units to manage user accounts and resources. In planning for the Active Directory, early mapping of domains and organizational units is highly recommended. In so doing, it is also important to determine where administrative authority is to be granted and delegated. Best practices in forming domains and organizational units include the following considerations:
Providing users with authority to use appropriate network resources while restricting visibility to all other objects
Ensuring that administrators have rapid visibility to all resources
Accommodating current operational and business structures while providing for organizational changes
Organizing resources and accounts into OUs to permit delegation of administrative authority
Logically dividing OUs into smaller, more manageable units
Even though Windows Server 2003 fully supports multiple domains and organizational units, the KISS (keep it simple, stupid) principle still applies. Complexity increases as the number of domains and OUs grows. Always weigh the tradeoffs between administrative granularity and greater complexity. When creating organizational units, try to mirror the functional setup of the business structure; for example, the sales group might logically be a single OU. Likewise, resources can be grouped into organizational units, say, all printers in one domain. In this way, it is possible to delegate one administrator to manage the printer OU and another to manage the sales group user account OU.
A common planning question is when to create a child domain versus an organizational unit. Unfortunately, there is no clear answer, although it is generally determined by scope and complexity. In the next section we list some of the reasons for forming child domains. Here we will say that when control of smaller user groups or resources can be logically delegated, organizational units are more appropriate. Also, where change is anticipated within the organizational structure, OUs can more easily accommodate such shifts.
While the single domain is the simplest to create and maintain, there are organizational and administrative situations in which multiple domains, trees, and forests must be created. Security, administrative, and connectivity borders separate domains. When planning a domain tree or forest, it is important to understand how these components interact.
By default, a domain tree is created when the first domain controller is promoted with its own Windows Server Active Directory. When domains are added, they become child domains to this first, root, domain. In addition to automatic transitive trusts, all domains in the tree share a schema, configuration, and Global Catalog. Beyond this point, however, domain characteristics within a tree can vary. This is important because it is at this level of setting specific characteristics that decisions must be made about child domains. If you answer yes to one or more of the following questions, a child domain could be in order:
Is decentralized administration desired? If it's necessary or desirable to manage assets or specific business activities in several locations, a decentralized model with separate child domains might be beneficial.
Does the organization need tight and/or localized administration? For example, in global organizations it may be appropriate to localize administration within a given domain to account for differences such as language and time zone.
Do business activities or relationships dictate separate domains? Competing business units or joint ventures may require autonomy, including the management of their own domains.
Do account policies need to differ? Since account policies are applied at the domain level, it may be appropriate to logically group users into domains that have distinct policy requirements.
Does replication suggest a need for different domains? While replication can be controlled by site, it can also be controlled based on a logical structure to reduce network traffic—for example, between international offices.
A forest is formed by joining two or more domain trees at the root. Transitive trusts are created by the forest relationship such that network resources become available to any tree in the forest and its associated domains. The resulting hierarchy permits the same Active Directory to resolve inquiries for objects in any of the trees in the forest. Each tree has a DNS namespace, but shares the schema, configuration, and Global Catalog. The forest itself is identified by the DNS name of the first tree created in it.
LDAP inquiries are conducted only within a tree and do not extend to the forest. The Global Catalog is used to resolve queries between trees; by default it is located on the first domain controller created in the forest. Part of the planning effort must be determining whether a dedicated domain controller should be used for Global Catalog activities. In addition, it must be decided if replicated Global Catalog domain controllers will be created to offload heavy intertree query traffic. For these reasons, the placement of the Global Catalog in the network is a key administrative task. Make sure there is fast and reliable connectivity to it.
The creation of a forest involves three primary steps. First, a DNS name must be selected (and registered) for the domain trees. Second, the configuration of each domain tree as described earlier must be laid out. Finally, the new tree must be added to the forest while the first domain controller is promoted through the Active Directory installation process. You will need to select Create New Domain Tree in an Existing Forest from the installation wizard.
Despite the fact that management of a forest is considerably more complex than that of singular trees, situations still arise where distinct namespaces are required. If you answer affirmatively to one or more of the following questions, a forest may be necessary.
Are the business activities extremely different? Organizations that operate on radically different bases may require separate trees with distinct namespaces.
Are there reasons for maintaining separate identities? Unique trade or brand names often give rise to separate DNS identities. This is particularly true when organizations merge or are acquired and naming continuity is desired.
Do joint ventures or partnerships exist that require tighter control over network resources? Organizations often form partnerships and joint ventures. While access to common resources is desired, a separately defined tree can enforce more direct administrative and security restrictions.
Relationships between forests are not based on transitive trusts. They are generally established to created limited access for one domain in one forest to one domain in another forest. The trust relationship is one-directional and must be explicitly set. It does not impact any other domains. If it is necessary to create multiforest relationships, plan trust and resource management well in advance. Make sure that access is limited only to those resources required for the life of the relationship.
Cross-forest authentication provides secure access to resources between forests. Using either Kerberos or Windows NT LAN Manager (NTLM), the feature provides security without sacrificing the single sign-on and administrative benefits. Cross-forest authentication includes:
Supported authentication. Four types of authentication are used across forests: (1) Kerberos and NTLM network logon for remote access to a server in another forest; (2) Kerberos and NTLM interactive logon for physical logon outside the user's home forest; (3) Kerberos delegation to N-tier application in another forest; and (4) user principal name (UPN) credentials are fully supported.
Name resolution. When Kerberos and NTLM cannot resolve a name on the local domain controller, the Global Catalog is used to attempt name resolution. In the event the GC fails, an authentication call is placed to the cross forest. The name-matching function compares the security principal name with trusted namespaces from all trusted forests. A trusted forest name as routing hint is returned if the name is matched on the cross forest.
Request routing. Kerberos and NTLM use routing hints to route authentication requests. This is done along the trust path from the originating domain to the probable destination domain. In the specific case of Kerberos, the Key Distribution Center (discussed in Chapter 12) generates referrals that follow the trust path. NTLM uses a secure channel to chain together the trust path.
Upgrades to the Active Directory from Windows NT Server environments are handled slightly differently depending on the domain structure in the current enterprise. Remember, as discussed in Chapter 5, the multimaster replication model of the Active Directory supplants the four types of domain models employed by Windows NT. Consider the following issues when planning an Active Directory promotion:
Upgrading the single Windows NT domain model. When the single Windows NT domain model is upgraded to the Active Directory, it remains a single domain. The primary change is in the added functionality afforded by the Active Directory and the optional use of organizational units.
Upgrading the master Windows NT domain model. The Windows NT master domain model assumes a top-down hierarchy that is mirrored by the Active Directory, but since Windows NT did not support organizational units, additional domains were often formed to separate resources and users into more manageable components. One of the planning decisions when upgrading from a Windows NT master domain model is whether to collapse existing domains into a single Active Directory domain so that previously defined Windows NT domains can become organizational units. However, there is no requirement to convert an existing master domain model infrastructure to a single domain; Active Directory will fully accommodate the existing structure. The primary domain controller must be upgraded first to Windows Server 2003 and the Active Directory. Child domains can then be upgraded to form an Active Directory domain tree. They simply join the existing Windows Server domain during the promotion installation.
Upgrading the complete Windows NT trust model. In this model, Windows NT provided trust between domains. Active Directory provides upgrade options that allow for transitive trust between domain trees and/or forests. It also allows one-way trusts between selected domains in two nonrelated forests. The key issue when upgrading Windows NT from a complete trust model is the level of trust desired.
Sound planning of an upgrade usually requires a conservative approach to full deployment. Therefore, we recommend that the initial Active Directory installation and domain tree formation be separate from the installation of the production environment. One way to accomplish this and preserve Windows NT domain data is to pull an existing BDC off production and promote it to a PDC in a detached lab environment. At this stage, installation of Windows Server 2003 and the Active Directory can go forward on this domain controller while initial testing and fine-tuning are completed. When satisfactory testing is achieved, the domain controller can be returned to production as the root domain controller.
An alternative and less conservative approach is to install the Windows Server 2003 Active Directory in a production environment, first removing an existing Windows NT BDC from the network and production for safety purposes. In the unlikely event that the Windows Server 2003 deployment fails, you can remove it from production and restore the previous Windows NT environment. The offline BDC is put back in service and promoted to the PDC.
Every domain and child domain must have at least one domain controller. The addition of domain controllers generally improves reliability, speed, and flexibility. Since a user's network logon is predicated on access to a domain controller, fast and reliable connectivity is required. Therefore, we recommend that there be more than one domain controller for each domain and each site.
It is often wise to establish at least two domain controllers to serve as operations master domain controllers. The PDC Emulator and Relative Identifier Master roles should be assigned to these mirrored domain controllers for redundancy.
The role of the standard domain controller and Global Catalog are also often filled by different domain controller servers. It is always advisable to separate the GC from the domain controller assigned to the Infrastructure Master role.
Sizing the minimal requirements for the Active Directory server hardware involves a series of estimates. The process entails creating a sample population of Active Directory objects and then applying size factors to each. This should include a real-world collection of objects including users, computer accounts, groups, printers, and files. Objects that are security principals should be allocated 3,600 bytes each. Nonsecurity principal objects should be allocated 1,100 bytes. For each attribute of 10 or fewer characters, allocate an additional 100 bytes. Attributes that contain binary information should include the size of the data plus a 25 percent buffer.
We recommend a simple spreadsheet be used to calculate the size requirements of the sample population. The sample population's storage requirements are estimated by adding the numbers for the objects and associated attributes, as illustrated in the following example. Make sure to include in the calculation every attribute associated with an object.
The next step is to estimate the number of objects that must be managed by the Active Directory. This estimate should include all users, groups, printers, contacts, and files on the system and should then be doubled. The storage requirements can then be proportionately extrapolated by using the number of objects you estimate for your enterprise. For example, if the sample population represented 1/10 of 1 percent of the Active Directory objects, multiply that amount by 1,000. If the sample population storage estimate were 360,000 KB, then the requirements for the Active Directory size would be 360,000,000 KB, or 360 MB. It is generally recommended that the disk space be two to three times larger than the estimated size of the Active Directory to accommodate possible miscalculation and growth.
New to Windows Server 2003 is a versioning mechanism that can be used by Active Directory core components to determine what features are available on each domain controller in a forest. This feature can flag domain controller setup and release inconsistencies. Many enterprises have a requirement for the same level of Windows Server Active Directory. This feature permits a rapid review of all domain controllers to ensure product release management. For example, there are two new features in Active Directory that cannot be activated until all the DCs in a forest are upgraded to Windows Server 2003: (1) Active Directory: Group Membership Replication Improvements and (2) Active Directory Improved Inter-Site Replication Topology Generator.
 |
|
|
| Top |