Designing a Windows Server 2008 R2 Active Directory : Understanding the Single Domain Model

1/22/2011 9:16:40 AM
The most basic of all AD DS structures is the single domain model; this type of domain structure comes with one major advantage over the other models: simplicity. A single security boundary defines the borders of the domain, and all objects are located within that boundary. The establishment of trust relationships between other domains is not necessary, and implementation of technologies such as Group Policies is made easier by the simple structure. More organizations than not can take advantage of this design because AD DS has been simplified, and its capability to span multiple physical boundaries has been enhanced.

Choosing the Single Domain Model

The single domain model is ideal for many organizations and can be modified to fit many more. A single domain structure possesses multiple advantages, first and foremost being simplicity. As any administrator or engineer who has done work in the trenches can confirm, often the simplest design works the best. Adding unnecessary complexity to the system’s architecture introduces potential risk and makes troubleshooting these systems more difficult. Consequently, consolidating complex domain structures into a simpler single domain AD DS structure can reduce the costs of administration and minimize headaches in the process.

Another advantage realized by the creation of a single domain is the attainment of centralized administration. Many organizations with a strong central IT structure want the capability to consolidate control over the entire IT and user structure. AD DS and, specifically, the single domain model allows for a high level of administrative control and the ability to delegate tasks to lower sets of administrators. This has proven to be a strong draw to AD DS.

Not all AD DS structures can be composed of a single domain, however, and some factors might limit an organization’s ability to adopt a single domain structure. If these factors affect your organization, you might need to begin expanding your domain model to include other domains in the forest and a different domain design. For example, the single security boundary formed by a single domain might not be exactly what your organization needs. Organizational units (OUs) can be used to delegate administration of security elements, but members of the Domain Admins group can still override permissions within different OUs. If the security lines within your organization need to follow exact boundaries, a single domain might not be for you. For example, if your HR department requires that no users from IT have access to resources within its environment, you will need to expand your domain structure to accommodate the additional security concerns.

Another disadvantage of the single domain model is that a single domain in a forest necessitates that the computer with the role of schema master is located in that domain. This places the schema master within the domain that contains all the user accounts. Although access to the schema master can be strictly controlled through proper administration, your risk of schema exposure is greater when the schema master role resides in a user domain. For example, members of the domain administrators group could override the security of the schema administrators group and add their account to that group. If this design model poses problems for you as an organization, design models that separate the schema master into a placeholder domain can do the trick.

Exploring a Single Domain Real-World Design Example

To illustrate a good example of an organization that would logically choose a single domain model, let’s consider fictional CompanyA. CompanyA is a 500-user organization with a central office located in Minneapolis. A few smaller branch offices are scattered throughout the Midwest, but all help desk administration is centralized at the company headquarters. CompanyA currently utilizes a single user domain and has multiple resource domains in various locations across the country.

The IT team in Minneapolis is designing an AD DS structure and wants to centralize administration at corporate headquarters. Branch offices should have the capability to change passwords and clear print jobs locally, but should have no other form of administrative privilege on the network.

During the AD DS design process, CompanyA started with a single AD DS forest, domain, and namespace named Organizational units for each branch office were added to delegate password-change control and print administration to those offices.

Current legacy Windows 2000 AD and Windows Server 2003 forests and domains were consolidated into the AD DS structure, as shown in Figure 1. CompanyA could not justify the existence of additional domains because their security model was centralized, and it did not have any far-flung geographical locations with slow link speeds to the main office or any other similar constraints that required additional domains.

Figure 1. AD DS structure with organizational unit structure.

Delegation of password-change control and other local administrative functions was granted to individuals in each specific geographical OU, which gave those administrators permissions specific to only resources within their own group but maintained central administrative control in Minneapolis.

Several AD DS sites were created to control the frequency of replication. A site was positioned to correspond with each separate geographical area, creating a site structure similar to the one shown in Figure 2.

Figure 2. Site structure created by geographical locations.

Creating the separate sites helped to throttle replication traffic and reduce the load placed on the WAN links between the sites.

This type of single domain design is ideal for the type of organization described in this section and actually can be used for many other types of organizations, large and small. Because delegation of administration is now accomplished through the use of OUs and Group Policy Objects, and the throttling of replication is accomplished through AD sites, the number of reasons for organizations to use multiple domains has been reduced.

  •  Windows 7: Optimizing Performance (part 3) - Using ReadyBoost to Enhance Performance
  •  Windows 7: Optimizing Performance (part 2) - Fine-Tuning Virtual Memory & Data Execution Prevention
  •  Windows 7: Optimizing Performance (part 1) - Fine-Tuning Visual Effects & Application Performance
  •  Designing a Windows Server 2008 R2 Active Directory : Choosing a Domain Structure
  •  Designing a Windows Server 2008 R2 Active Directory : Understanding AD DS Domain Design
  •  Personalizing Windows 7 (part 6) - Configuring Your Monitors
  •  Personalizing Windows 7 (part 5) - Choosing Your Mouse Pointers
  •  Personalizing Windows 7 (part 4) - Choosing Your System Sounds
  •  Personalizing Windows 7 (part 3) - Choosing and Configuring Your Screensaver
  •  Outlining AD DS Changes in Windows Server 2008 R2 (part 3) - Auditing Changes Made to AD Objects
    Video tutorials
    - How To Install Windows 8

    - How To Install Windows Server 2012

    - How To Install Windows Server 2012 On VirtualBox

    - How To Disable Windows 8 Metro UI

    - How To Install Windows Store Apps From Windows 8 Classic Desktop

    - How To Disable Windows Update in Windows 8

    - How To Disable Windows 8 Metro UI

    - How To Add Widgets To Windows 8 Lock Screen

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010
    programming4us programming4us