Designing a Windows Server 2003 Active Directory
- 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
In This Chapter
-
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
Domain Design Overview
Proper design of a Windows .NET Active Directory structure is a critical component in the successful deployment of the technology. Mistakes made in the design portion of Active Directory can prove to be costly and difficult to correct. Many assumptions about basic Active Directory domain and functional structure have been made, and many of them have been incorrect or based on erroneous information. Solid understanding of these components is vital, however, and anyone looking at Windows .NET should keep this point in mind.
Active Directory was specifically designed to be scalable. This means that theoretically organizations of every shape and size should be able to implement the technology. For obvious reasons, this means that the structure of the Active Directory forest will vary from organization to organization.
In Windows .NET Server 2003's Active Directory implementation, cross-forest trust ability has been added. This allows for the design of so-called federated forests, a new concept in .NET Server. Federated forests are basically multiple forests with separate schemas and separate administrative teams joined via a cross-forest transitive trust. This allows for greater scalability and enables administrators to completely separate security boundaries within an organization.
In addition, several design decisions that were previously irreversible in Windows 2000, such as forest name and relative domain structure, have been updated to allow changes to take place. Now you can rename your Active Directory domain structure if a merger or acquisition takes place. The psychological factor alone of having to make a decision and not being able to change it has kept some organizations away from deploying Active Directory in the past. Now that those barriers have been removed, more organizations will be able to deploy Active Directory without fear of being painted into a corner later.
Before any domain design decisions can be made, it is important to have a good grasp of Active Directory's domain structure and functionality. Windows 2000 administrators will recognize many of the key components, but some fairly major changes have been made in Windows .NET Server 2003 that require a reintroduction to the domain design process. In addition, real-world experience with AD domain design has changed some of the assumptions that were made previously.
This chapter focuses on best practices for Active Directory design, including a discussion of the specific elements that comprise Active Directory. Various domain design models for Active Directory are presented and identified with specific real-world scenarios. The domain rename procedure is outlined as well, to provide for an understanding of how the concept affects domain design decisions. In addition, step-by-step instructions are presented for several aspects of Windows .NET Server 2003 domain design that have significantly changed since Windows 2000.
Domain Trusts
Windows .NET Server 2003's Active Directory domains can be linked to each other through the use of a concept known as trusts. Many administrators in NT 4.0 remember trusts (although many would likely prefer to forget them). A trust is essentially a mechanism that allows resources in one domain to be accessible by authenticated users from another domain. As many administers will recall, domain trusts in NT 4.0 were one way, and not transitive. In other words, any resource sharing between multiple domains required numerous multiple-trust relationships. Trusts in Active Directory take a different approach than this "connect everything with trusts" approach. In Windows .NET Server 2003's Active Directory, trusts are more powerful and simplistic at the same time. AD trusts take on many forms but typically fall into one of the four categories described in the following sections.
Transitive Trusts
Transitive trusts are automatic two-way trusts that exist between domains in Active Directory. These trusts connect resources between domains in Active Directory and are different from Windows NT trusts in that the trusts flow through from one domain to the other. In other words, if Domain A trusts Domain B, and Domain B trusts Domain C, Domain A trusts Domain C. This flow greatly simplifies the trust relationships between Windows domains because it forgoes the need for multiple exponential trusts between each domain.
Explicit Trusts
An explicit trust is one that is set up manually between domains to provide for a specific path for authentication sharing between domains. This type of trust relationship can be one way or two way, depending on the needs of the environment. In other words, all trusts in NT 4.0 could have been defined as explicit trusts because they all are manually created and do not allow permissions to flow in the same way as transitive trusts do. The use of explicit trusts in Active Directory allows designers to have more flexibility and to be able to establish trusts with external and down-level domains. All trusts between Active Directory domains and NT domains are explicit trusts.
Shortcut Trusts
A shortcut trust is essentially an explicit trust that creates a shortcuts between any two domains in a domain structure. For example, if a domain tree has multiple subdomains that are many layers deep, a shortcut trust can exist between two domains deep within the tree, similar to the shortcut trust shown in Figure 5.1. This relationship allows for increased connectivity between those two domains and decreases the number of hops required for authentication requests. Normally, those requests would have to travel up the transitive trust tree and back down again, thus increasing overhead.
)
Figure
5.1 Shortcut trusts minimize hops between domains.
The example in Figure 5.1 shows how a shortcut trust could theoretically be used to reduce the overhead involved in sharing resources between the two sales sub-subdomains in the companyabc.com tree. You can find more information on these trusts in the individual design model sections later in this chapter.
Cross-Forest Trusts
Although not an entirely new form of trust, cross-forest trusts are essentially two-way transitive trusts that exist between two disparate Active Directory forests. While explicit trusts between forests were possible in Windows 2000, the cross-forest trusts in Windows .NET Server 2003 allow for two-way transitive trusts to exist between two separate forests. You can find more information about this new variety of trusts later in this chapter.