Lesson 2: Designing Your Domain Structure

Once you've decided to create either a single forest or multiple forests for an organization, the next step is to determine how many domains the organization needs. As with forests, the goal is to start with a simple model, such as a single domain, and then determine if you need multiple domains.

---

After this lesson, you will be able to

• Design a domain structure for your organization based on security and business requirements

Estimated lesson time: 45 minutes

---

Deploying a Single Domain

A single-domain forest is commonly implemented in organizations that maintain centralized control of user and computer accounts. By maintaining only a single domain, membership in the Administrators group is easily monitored to ensure that no users are granted excess privileges on the network.

Making the Decision

When simplicity within the forest is the goal, a single domain is the best decision for an Active Directory design. Choosing to implement a single domain will have the following effects on your Active Directory:

• It reduces management of the forest. When only a single domain exists in the forest, the domain's administrators are ultimately the forest's administrators as well. This arrangement ensures that there is no differentiation between the enterprise administrators and the domain administrators. Instead of creating domains to perform administrative tasks, designers commonly use OUs to delegate administrative tasks to specific individuals in the domain.
• It reduces the number of required DCs. Every domain that you create requires separate DCs. By deploying a single domain, you reduce the total number of DCs. If your forest has multiple sites, you only have to place DCs from a single domain at each site for authentication purposes. You don't have to place DCs from multiple domains at a single site.
• It reduces the dependency on global catalog servers for authentication. When authenticating in a native mode domain, the authenticating DC connects to a global catalog server to determine universal group membership for the authenticating security principal. This isn't required in a single-domain environment because the authenticating DC knows about all objects in the forest.

  NOTE

  ---

  The authenticating DC knows that only a single domain exists in the forest by querying the CN=configuration, DC=forestrootdomain naming context (where forestrootdomain is a variable representing the name of the domain in question) to determine which domains exist in the forest.

• It provides an easier migration path to multiple domains.If you deploy a single domain, it's easy to migrate the forest to a multiple-domain environment. It's harder to reduce the number of domains in an existing forest because this requires the migration of user accounts between domains in the forest to empty; the domain that's to be removed from the forest.

Applying the Decision

Wide World Importers can start initially with a single domain for its organization, but as we will see, its business objectives require the implementation of multiple domains. Because it's easy to migrate from a single domain to multiple domains, there aren't additional costs involved with initially deploying a single domain for the Wide World Importers network.

Deploying Multiple Domains

In Windows 2000, there are several technical reasons that will influence your Active Directory design to implement multiple domains. One of the key reasons to implement multiple domains is a requirement for differing account policies. Account policies can only be applied at a domain level. There's no way to implement varying account policies within a single domain. If varying account policies are defined, this requires that multiple domains exist within the forest.

Understanding Account Policies

Account policies include the following three categories of configuration:

• Password Policy. Defines the characteristics of passwords that may be used to authenticate to the domain.
• Account Lockout Policy. Defines which actions must be taken when a specified amount of failed logon attempts occur in a short period of time.
• Kerberos Policy. Defines maximum ticket lifetimes for Kerberos authentication and tolerances for clock synchronization between client computers and servers.

TIP

---

When implementing account policy, be sure to set it at the domain level so that the domain settings are configured. Account policy configured at the OU level only affects the local account databases of any computers in that OU. It won't affect any users authenticating with the domain when using that computer.

The account policies you set must be carefully balanced. You don't want to make the settings too restrictive because this can lead to increased help desk calls from users whose accounts have been locked out. Likewise, you don't want to have too few restrictions that result in users implementing blank passwords.

In addition, specifying restrictive password policy can actually reduce the security of the network. For example, if you require passwords to be longer than seven characters, most users have difficulty remembering them. They might write their passwords down and leave them where an intruder can easily find them.

Password Policy

Password policy defines the characteristics of allowed passwords for user accounts in a domain. As with all account policies, if different areas within an organization can't agree on a common password policy, multiple domains must be defined or consensus must be reached on a standard set of password policies. The following settings can be defined for password policy:

• Enforce Password History. Allows you to configure how many previous passwords are maintained to prevent users from reusing the same password when they're required to change their password. The policy can have a value between 0 and 24 passwords being remembered.
• Maximum Password Age. Defines how frequently a password must be changed. When the age defined in this policy is reached, users are required to change their existing password to a new password. The value of this policy can be set from zero (defined as password will not expire) to 999 days.
• Minimum Password Age. Defines how long a newly changed password must exist before the user can change it. By setting this value, you can prevent users from getting around the Enforce Password History policy by repeatedly performing quick switches of their password.
• Minimum Password Length. Defines the minimum character length for a user's password. If the user enters a password that's less than the minimum length, the password will be rejected.
• Passwords Must Meet Complexity Requirements. Controls the format of passwords entered by the user. Passwords must meet three of the following four requirements:
  • UPPER CASE
  • lower case
  • 1234567890 (numeric)
  • !@#$%^*() (symbols)

  In addition, passwords can't contain the user's account name.

  NOTE

  ---

  The requirement of complex passwords helps protect against dictionary attacks against the passwords stored in Active Directory. A dictionary attack encrypts all the words found in a dictionary file provided by an attacker. The encryption is performed using the same algorithm used to encrypt passwords within Active Directory. A hacker may determine the password by comparing the data found in Active Directory with the encrypted results from the dictionary file.

• Store Password Using Reversible Encryption For All Users In The Domain. Stores the password in a reversible encryption format for all users. The password is saved in this format only after the user has changed the password for the first time after this policy is set. Reversible encryption is used by the Internet Information Server when configured to use digest authentication and by dial-in users using Challenge Handshake Authentication Protocol (CHAP).

Account Lockout Policy

Account lockout policy defines how Active Directory deals with an account when a preconfigured threshold for incorrect logon attempts is surpassed. The following list outlines the policies that can be defined:

• Account Lockout Duration. Defines the time that an account is locked out once the account lockout threshold is exceeded. The policy can be defined to be a value between 0 and 99,999 minutes. If defined to be 0, this indicates that the account is locked out until an administrator manually resets it.
• Account Lockout Threshold. Defines how many incorrect logon attempts are allowed before an account is locked out. This policy can be set to a value between 0 and 999 logon attempts.
• Reset Account Lockout Counter After. Defines how frequently the account lockout counter is reset to zero. For example, if this policy is defined as 30 minutes, the account lockout counter will be reset to a value of zero after a period of 30 minutes has passed since the last failed logon attempt.

You must define the account lockout policy to fit the help desk service implemented at your organization. If you have a help desk that's always available (24 hours a day, seven days a week), then specify to lock out an account until an administrator manually resets it. You must also be careful to reset the account lockout counter after a short period of time to ensure that unsuccessful logon attempts over a long period of time don't result in an account being locked out.

Kerberos Policy

The Kerberos policy defines settings for the Kerberos v5 authentication protocol. These settings apply to all computers and users in the domain where the policy is defined. The Kerberos policy settings available in account policy include

• Enforce User Logon Restrictions. Specifies that Kerberos will verify that the account hasn't been locked out each time that a Kerberos service ticket is requested. This prevents a locked out account from acquiring any additional service tickets after an administrator locks out the account.
• Maximum Lifetime For Service Ticket. Defines how long a service ticket can be stored in the service ticket cache. Once the maximum lifetime is reached, the service must discard the service ticket and acquire a new service ticket or renew the existing service ticket.
• Maximum Lifetime For User Ticket. Defines the maximum lifetime for a Kerberos ticket issued to a user account. Once the maximum lifetime is reached, the ticket is discarded from the user's Kerberos ticket cache.
• Maximum Lifetime For User Ticket Renewal. Defines the maximum amount of time during which a ticket may be renewed. Once this period expires, a new ticket must be acquired from the Key Distribution Center (KDC).
• Maximum Tolerance For Computer Clock Synchronization. Defines how much a client computer's clock can be out of sync with a server's computer clock. The Kerberos protocol uses a time stamp to prevent replay attacks of a Kerberos authentication stream. If the clocks are out of sync by a period greater than this policy setting, the authentication attempt will fail.

Kerberos settings must be the same for an entire domain. If you require different Kerberos settings, you have identified the need for multiple domains. When you configure Kerberos settings, the main settings you should consider modifying (in regards to security) are the enforce user logon restrictions and maximum tolerance for computer clock synchronization settings. These settings will ensure that a disabled account will be immediately prevented from accessing further resources on the network. The clock synchronization setting will ensure that replay attacks are prevented on the network.

Making the Decision

You must decide to implement multiple domains if any of the following scenarios exist in your organization:

• Differing account policies. If departments can't agree on account policy settings such as minimum password length, account lockout duration, or Kerberos ticket lifetime settings, you need to create multiple domains. All account policy settings are applied at the domain level. Any requirements for differing account policy settings will require the establishment of separate domains.

  NOTE

  ---

  You can define account policy at the OU level in Group Policy. This won't affect domain account policies, but it will affect local account database policies. This means that you can specify different account policy settings for users who authenticate using the local security account management database of their computer instead of those that are set for domain authentication.

• Replication issues. For offices that have smaller branch offices connected by slow wide area network (WAN) links, the traffic associated with replication can lead to saturation of the WAN link. By configuring a separate domain at the branch office, you limit replication to the schema, configuration, and global catalog.

  NOTE

  ---

  The separate domain can be implemented as a child domain of the current domain or as a domain in a separate tree within the forest.

• International considerations. Some countries require management of the network to take place within the country where the network is located. If these restrictions are in place, you must establish a separate domain at the remote site to ensure that all network management occurs within the country where the network exists.
• Political reasons. In many organizations, departments don't cooperate and may wish to maintain their autonomy by managing separate domains within a forest. Although this isn't a business reason for creating separate domains, it's a common scenario that needs to be addressed. In some scenarios a business case can be built to use OUs and delegation of administration instead of creating separate domains.
• The need to put enterprise administration accounts into a separate domain. Within a forest, enterprise-level administration groups exist in the forest root domain. These accounts include the Schema Admins and Enterprise Admins groups. By creating an empty forest root domain, you will restrict who can manage these accounts.

  WARNING

  ---

  All members of the Domain Admins group in the forest root have the ability to change membership in the Enterprise Admins and Schema Admins groups. Membership in all three groups should be carefully monitored to ensure that group memberships aren't changed without authorization.

Applying the Decision

In its initial requirements, Wide World Importers said it needed separate account policies to be defined for the Engineering department. Because account policies are defined at the domain level, you need multiple domains for the Wide World Importers network architecture.

Based on account policies, the Wide World Importers network requires at least two domains: one to contain all members of the Engineering department and the other to contain the remaining users.

Having offices in both the United States and Canada doesn't necessarily require a company to have separate domains for each one. Likewise, the WAN links between the offices are sufficient for replication of a single domain, subject to the current utilization of the WAN links.

Wide World Importers could deploy either a two-domain forest or a three-domain forest, depending on its security needs for restricting membership in the Enterprise Admins, Schema Admins, and forest root Domain Admins groups. Figure 2.4 shows the proposed domain tree layouts depending on whether or not Wide World Importers implements an empty forest root.

Figure 2.4 The potential domain models for Wide World Importers

Lesson Summary

Design the number of domains needed within an Active Directory forest by analyzing the organization's business requirements. Base your determination of whether you need multiple domains on the circumstances that make multiple domains necessary.

Be aware that differing account policies—password policy, account lockout policy, or Kerberos policy—will require the deployment of multiple domains in your organization's forest.