- Domain Design Overview
- Choosing Your Domain Namespace
- New Domain Design Features in Windows .NET Server 2003
- Choosing Your Domain Structure
- Single Domain Model
- Multiple Subdomain Model
- Multiple Trees in a Single Forest Model
- Federated Forests Design Model
- Peer-Root Domain Model
- Placeholder Domain Model
- Special-Purpose Domains
- Renaming an Active Directory Domain
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Multiple Subdomain Model
For various reasons, organizations may need to add more than one domain to their environment but preserve the functionality that is inherent in a single forest. When this occurs, the addition of one or multiple subdomains into the forest is warranted. Domain addition should not be taken lightly, however, and proper consideration must be given to the particular characteristics of multiple domain models.
By default, two-way transitive trusts exist between subdomain and domain in Active Directory. Bear in mind, however, that this does not mean that resource access is auto-matically granted to members of other domains. A user in subdomain B is not automatically granted any rights in domain A; they need to be explicitly defined through the use of groups. Understanding this concept will help to determine the logistics of domain addition.
When to Add Additional Domains
As previously mentioned, it is advisable to begin your Windows .NET Active Directory design with a single domain and then add domains only when absolutely necessary. Adding child domains to your existing domain structure may become necessary if the following traits exist within your infrastructure:
Decentralized Administration—If different branches of your organization generally manage their own IT structure and there are no future plans to consolidate them into a centralized model, multiple interconnected domains may be ideal. Each domain acts as a security boundary for most types of activity and can be set up to disallow administration from escaping the boundaries of domains. This approach operates in much the same way as NT domains and inherits many of the limitations associated with them as well. In other words, it is better to try to centralize administration before deploying Active Directory because you will gain more of AD's advantages.
Geographic Limitations—If extremely slow or unreliable links or great geographical distances separate different parts of your company, it may be wise to segment the user population into separate groups. This will help to limit replication activity between domains and also make it easier to provide worktime support for distant time zones. Keep in mind that slow links by themselves do not necessitate the creation of multiple domains, as Windows .NET Active Directory uses the concept of Active Directory sites to throttle replication across slow links. The main reason that might exist for domain creation for geographical reasons is administrative flexibility. In other words, if there is a problem with the network in Japan, a Japanese administrator will be able to have more power to administer the Asia domain and will not need to call the North American administrator in the middle of the night.
Unique DNS Namespace Considerations—If two organizational entities want to use their Internet-registered namespace for Active Directory but use a common forest, such as hotmail.com or microsoft.com, those domains must be added as separate domains. This type of domain model is described more fully in the section "Multiple Trees in a Single Forest Model" later in this chapter.
Special Password Policies—Because password policies are set on a domain level, if any specific password policies must be set differently between domains, separate domains must be set up to segregate those policies. This is rarely a real-life design issue that by itself creates a new domain, but knowledge of this limitation will help in the design process.
Enhanced Security Concerns—Depending on the needs of your organization, separating the schema master role into a domain separate from your users may be applicable. In this case, the single domain model would not be applicable, and a model such as the peer-root or placeholder domain would be more appropriate.
When you're contemplating additional domains, remember the mantra "Simplicity is best." However, if during the design process, the specific need arises to add domains, proper design is still warranted, or your environment will run the risk of looking like the type of messed-up NT domain structure that you have been trying to avoid.
Real-World Design Example
To illustrate an organization that would have grounds to establish multiple domains, we'll use the following example. Company B is an engineering company based in York, Pennsyl-vania. Administration for all branch locations is currently centralized in the home office, and OUs and Group Policies are used for delegation of lower-level tasks. Recently, the company acquired two separate companies named Subsidiary A and Subsidiary B; each contains its own IT departments and operates in separate geographical areas. Company B decided to implement Active Directory as part of a Windows .NET Server 2003 implementation and wanted to include the two acquired companies into a single common forest.
Because of the fact that each acquired company possesses its own IT department and there are no immediate plans to consolidate those functions centrally, Company B decided to deploy an Active Directory structure with two subdomains for Subsidiary A and Subsidiary B, as shown in Figure 5.5.
)
Figure
5.5 Active Directory with two subdomains.
This design model allowed for a certain degree of administrative freedom with the newly acquired subsidiaries but also allowed for a common forest and schema to be used and kept the domains within the same DNS namespace.
This design model has the particular advantage of being politically easier to implement than consolidation of existing domains. Branch offices and subsidiary companies can keep their own domain structure and security boundaries, and their IT teams can retain a greater deal of administrative autonomy. In other words, the NT domain administrator from a branch office won't be extremely upset after you've taken away his domain during or after a migration.
Be warned, however, that consolidation of NT domains into fewer domains is a key feature of Active Directory, so the addition of domains purely for political reasons adds complexity and potentially unnecessary infrastructure. It is therefore very important to consider the alternatives before deciding on this design model.