Single Domain Model

The most basic of all Active Directory 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. Many organizations that have lived with a multiple domain NT structure may think that they cannot consolidate on a single domain model. However, more organizations than not can take advantage of this design because Active Directory 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 systems' architecture introduces potential risk and makes troubleshooting these systems more difficult. Consequently, consolidating complex domain structures such as NT 4.0 into a simpler single domain Active Directory 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. NT domains were notoriously lacking in their capability to scale to these levels, and the types of central control that organizations wanted were not available. Active Directory 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 Active Directory.

Not all Active Directory structures can be composed of a single domain, however, and some factors may 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 may not be exactly what your organization needs. Although OUs can be used to delegate administration of security elements, the domain itself is the security boundary in Active Directory structures. If the security lines within your organization need to follow exact boundaries, a single domain may 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. The placeholder domain model is described in more detail later in this chapter.

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 Company A. Company A 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. Company A currently utilizes a single NT user domain and has multiple resource domains in various locations across the country.

The IT team in Minneapolis is designing an Active Directory 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 Active Directory design process, Company A started with a single Active Directory forest, domain, and namespace named companya.net. Organizational units for each branch office were added to delegate password-change control and print administration to those offices.

Current NT 4.0 domains were consolidated into the Active Directory structure, as shown in Figure 5.3. Company A 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 5.3. Active Directory 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. A detailed discussion of organizational unit design is covered in Chapter 6, "Designing Organizational Unit and Group Structure."

Several Active Directory 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 5.4.

Figure 5.4. 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. For more details about site links and replication, see Chapter 7, "Active Directory Infrastructure."

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.