Lesson 1: Defining Domains

The first step in creating a domain plan is to define domains. When you define domains, you determine the domains needed for each forest in your organization. This lesson discusses how to define domains, which includes assessing an organization's domain needs and determining the number of domains it requires.

---

After this lesson, you will be able to

• Identify the factors in an organization's environment that impact its need for domains
• Indicate the reasons for using multiple domains in an Active Directory infrastructure
• Explain the implications of defining multiple domains
• Analyze an organization's environment to define its domains

Estimated lesson time: 30 minutes

---

Understanding Domains

In Active Directory services, a domain is a partition of a forest, or a partial database. When you define domains, data is placed where it is most relevant in small databases, resulting in a large database that is efficiently distributed over the network. Recall that in Windows 2000 and Active Directory, domains represent security boundaries. Each domain has a unique name and provides access to centralized user accounts and group accounts maintained by the domain administrator. Active Directory is made up of one or more domains, each of which can span one or more sites.

Goals for Defining Domains

There are two goals you should keep in mind when defining the domains for your organization:

• Define domains based on the organization's geographical structure
• Minimize the number of domains

Defining Domains Based on Geographical Structure

In Chapter 2, "Introduction to Designing a Directory Services Infrastructure," one of the ways you learned to represent the geographical structure of an organization was by diagramming your organization's network architecture. You should use your network architecture diagram as a guide when defining domains for your organization. You should also consider other infrastructures currently employed in the organization. For example, if your organization has already invested in a DNS structure, you should probably retain this structure. Similarly, if your organization is using a large Microsoft Exchange operation, you may want to base your domain structure on the same model. Before you change existing infrastructures, you must weigh the cost of the change against the potential benefits.

Because functional structures such as divisions, departments, or project teams are always subject to change, defining domains based on these structures in the organization is strongly discouraged. The domain structures you create in Windows 2000 are not as flexible as your business environment. Once you create a domain and place it in a hierarchy, that domain cannot be easily moved or renamed. If the domain is a forest root domain it can never be moved or renamed.

Minimizing the Number of Domains

One of the guiding principles for designing your Active Directory infrastructure is to design for simplicity; this includes minimizing the number of domains. Whenever possible, it's best to limit your infrastructure design to one domain that is administered through organizational units (OUs). Adding domains to the forest increases management and hardware costs.

If you are upgrading from Windows NT, it is likely that you will need to consolidate domains. The principles for defining multiple domains in Windows NT no longer apply in Windows 2000. These principles are

• Security Accounts Manager (SAM) size limitations. In Windows NT, the SAM database had a limitation of about 40,000 objects per domain. In Windows 2000, each domain can contain more than one million objects, so it is no longer necessary to define a new domain just to handle more objects.
• Primary Domain Controller (PDC) availability requirements. In Windows NT, only one computer in a domain, the PDC, could accept updates to the domain database. In Windows 2000, all domain controllers accept updates, eliminating the need to define new domains just to provide fault tolerance.
• Limited delegation of administration within domains. In Windows NT, domains were the smallest units of administrative delegation. In Windows 2000, OUs allow you to partition domains to delegate administration, eliminating the need to define domains just for delegation.

For information on designing OUs to delegate administration, see Chapter 5, "Creating an Organizational Unit Plan."

Design Step: Defining Domains

To define domains, you must complete the following tasks:

1. Assess the organization's domain needs.
2. Determine the number of domains for your organization.

Assessing Domain Needs

To define domains for your organization, you must first consult the following documents compiled earlier by your design team:

• Business Structures Worksheet. Assess current administrative and geographical structure to determine possible domain locations.
• Network Architecture Worksheet. Assess current network architecture to determine possible domain locations.
• Technical Standards Worksheet. Assess current administrative and security standards to determine need for domains.
• Hardware & Software Worksheet. Assess the hardware devices and software that are not compatible with Windows 2000.
• Windows NT Domain Architecture Worksheet. Assess current domain structure to determine ways to consolidate domains.
• Forest model. Assess the number of forests planned for the organization to determine domain locations.

NOTE

---

Blank copies of the worksheets are located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). Completed examples of the worksheets are located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure." The forest model is discussed in Chapter 3, "Creating a Forest Plan."

In addition to assessing the information compiled in these documents, it is imperative that you also assess changes currently planned to business structures, network architecture, technical standards, and the existing domain architecture to address growth, flexibility, and the ideal design specifications of the organization.

Determining the Number of Domains

You must determine the number of domains for each forest in your organization. While one domain may effectively represent the structure of small or medium-sized organizations, larger and more complex organizations may find that one domain is not sufficient. To determine the number of domains for your organization's Active Directory infrastructure, you must carefully consider the reasons for defining multiple domains. Before adding any domains you should be able to state the purpose of the new domain and justify it in terms of administrative and hardware costs.

Reasons to Define Multiple Domains

These are the reasons to consider using multiple domains:

• To meet security requirements
• To meet administrative requirements
• To optimize replication traffic
• To retain Windows NT domains

When you're attempting to justify a new domain, consider all of the reasons together; there may be more than one reason for defining a domain.

TIP

---

Do not use multiple domains to accommodate polarized groups or for isolated resources that are not easily assimilated into other domains. Both the groups and the resources are usually better candidates for OUs.

Meeting Security Requirements

The settings in the Account Policies subdirectory in the Security Settings node of a group policy object can be specified only at the domain level. If the security requirements set in the Account Policies subdirectory vary throughout your organization, you will need to define separate domains to handle the different requirements. The Account Policies subdirectory contains the following policies:

• Password Policy. Contains settings for passwords, such as password history, age, length, complexity, and storage.
• Account Lockout Policy. Contains settings for account lockout, such as lockout duration, threshold, and the lockout counter.
• Kerberos Policy. Contains Kerberos-related settings, such as user logon restrictions, service and user ticket lifetimes, and enforcement.

Meeting Administrative Requirements

Some organizations may need to establish boundaries to meet special administrative requirements that cannot be accommodated by establishing OUs in one domain. Special requirements might include satisfying specific legal or privacy concerns. For example, an organization may have a privacy requirement that outside administrators not be given control over sensitive product development files. In a one-domain scenario, members of the Domain Admins predefined global group would have complete control over all objects in the domain, including the sensitive files. By establishing a new domain containing the files, the first Domain Admins group is outside of the new domain and no longer has control of the files.

Optimizing Replication Traffic

In organizations with one or more sites, you must consider whether site links can handle the replication traffic associated with a single domain. In a forest with one domain, all objects in the forest are replicated to every domain controller in the forest. If objects are replicated to locations where they are not used, bandwidth is used unnecessarily. By defining multiple small domains and replicating only those objects that are relevant to a location, you can reduce network traffic and optimize replication. However, you must weigh the savings achieved by optimizing replication against the cost of hardware and administration for the additional domains.

To determine whether you should define a domain to optimize replication traffic, you must consider

• Link capacity and availability. If a link is operating near capacity or is not available for replication traffic during specific times of the day, it may not be able to handle replication traffic, and you should consider defining another domain. However, if links are idle at specific times, replication could be scheduled to occur during these times, provided the appropriate bandwidth is available.
• Whether replication traffic will compete with other traffic. If a link carries other, more important traffic that you do not want disturbed by replication traffic, you should consider defining another domain.
• Whether link is pay-by-usage. If replication traffic will cross an expensive pay-by-usage link, you should consider defining another domain.
• Whether link is SMTP-only. If a location is connected by SMTP-only links, it must have its own domain. Mail-based replication can occur only between domains; it cannot be used between domain controllers in the same domain.

Retaining Windows NT Domains

Organizations with large Windows NT infrastructures may choose to retain an existing Windows NT domain. Existing Windows NT domains can be upgraded to Windows 2000, sometimes referred to as an in-place upgrade. You must weigh the costs of upgrading the Windows NT domain or consolidating the domain against the savings of maintaining and administering fewer domains. It is recommended that you minimize the number of domains by consolidating Windows NT domains before upgrading to Windows 2000.

For information on upgrading existing Windows NT domains to Windows 2000 or consolidating Windows NT domains, see Lesson 1, "Planning a Windows NT 4 Directory Services Migration to Windows 2000 Active Directory," in Chapter 7, "Creating an Active Directory Services Implementation Plan."

Implications of Defining Multiple Domains

Adding a domain increases administrative and hardware costs. When determining whether to define multiple domains, keep the following cost issues in mind:

• Domain administrators. Each time a domain is added, a Domain Admins predefined global group is added as well. More administration is required to monitor the members of this group.
• Security principals. As domains are added, the likelihood that security principals will need to be moved between domains becomes greater. Although moving a security principal between OUs within a domain is a simple operation, moving a security principal between domains is more complex and can negatively affect end users.
• Group policy and access control. Because group policy and access control are applied at the domain level, if your organization uses group policies or delegated administration across the enterprise or many domains, the measures must be applied separately to each domain.
• Domain controller hardware and security facilities. Each Windows 2000 domain requires at least two domain controllers to support fault-tolerance and multimaster requirements. In addition, it is recommended that domain controllers be located in a secure facility with limited access to prevent physical access by intruders.
• Trust links. If a user from one domain must log on in another domain, the domain controller from the second domain must be able to contact the domain controller in the user's original domain. In the event of a link failure, the domain controller may not be able to maintain service. More trust links, which require setup and maintenance, will be necessary to alleviate the problem.

To define domains

1. Determine the domains needed by the organization. Domains may need to be defined to meet security requirements, meet administrative requirements, optimize replication traffic, and retain Windows NT domains.
2. Obtain a copy of your design team's network architecture diagram. On the network architecture diagram, use a triangle to indicate domains you're defining.

Design Step Example: Defining Domains

Figure 4.1 shows the network architecture diagram for Pacific Musical Instruments, a manufacturer of traditional instruments of the countries of the Pacific Rim.

Figure 4.1 Network architecture diagram for Pacific Musical Instruments

Figure 4.2 shows the domains defined for Pacific Musical Instruments. Domains were defined for the following reasons:

• A domain was defined to meet the special password and account lockout settings that Pacific Musical Instruments requires at its Beijing location.
• A domain was defined at the Honolulu headquarters to meet the special legal requirements of Pacific Musical Instruments' personnel files.
• A domain was defined at the Tokyo location because the link to headquarters is only 20% available and could not effectively handle replication traffic.
• A domain was defined at the Sydney location because the link to headquarters is only 40% available and may not be able to effectively handle replication traffic. In addition, Pacific Musical Instruments will be opening up a new manufacturing location in Singapore, which will be linked only to the Sydney location and will likely increase traffic on the Sydney-to-headquarters link.
• A domain was defined at the Auckland location because it can be reached from the Sydney location by SMTP mail only.
• A domain was defined at the San Francisco location because it must be separate from the Honolulu domain and the links to any of the other domain locations were relatively congested and could not effectively handle replication traffic. The Anchorage site will also be served by this domain.

Figure 4.2 Domains defined for Pacific Musical Instruments

Lesson Summary

In this lesson you learned how to define domains for each forest in an organization by assessing an organization's domain needs and determining the number of domains it requires. Two goals should be kept in mind when defining the domains for your organization: to define domains based on the geographical structure of an organization's environment and to minimize the number of domains. It is easier to minimize the number of domains in Windows 2000 because the principles for defining multiple domains in Windows NT no longer apply.

You also learned the reasons for defining multiple domains, which include meeting security requirements, meeting administrative requirements, optimizing replication traffic, and retaining Windows NT domains. The implications of defining multiple domains were discussed, including how adding a domain increases administrative and hardware costs. Finally, you learned to define domains using an organization's network architecture diagram.