Designing a Windows Server 2008 R2 Active Directory : Choosing a Domain Structure

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
1/21/2011 11:40:19 AM

Choosing a Domain Namespace

The first step in the actual design of the AD DS structure is the decision on a common Domain Name System (DNS) namespace that AD DS will occupy. AD DS revolves around, and is inseparable from, DNS, and this decision is one of the most important ones to make. The namespace chosen can be as straightforward as, for example, or it can be more complex. Multiple factors must be considered, however, before this decision can be made. Is it better to register an AD namespace on the Internet and potentially expose it to intruders, or is it better to choose an unregistered internal namespace? Is it necessary to tie in multiple namespaces into the same forest? These and other questions must be answered before the design process can proceed.

Choosing an External (Published) Namespace

The simplest method of implementing an AD DS structure is through the use of a single, common DNS namespace that reflects the company’s name and is registered on the Internet. is an obvious example, and a myriad of other possibilities exist as well. Several advantages to a published namespace are that it is readily accessible from the Internet and there is less confusion on the end user’s part in regard to the location on the network and on the Internet. For example, a user named Rosemary Nahrvar working for the CompanyABC Corporation will be represented in the network through the user principal name (UPN) as This name can be set up to exactly match her email address, limiting confusion for the end user.

The limitations to this type of namespace strategy are primarily security based. Publishing your AD DS namespace leaves potential hackers with the name of your domain system and part of what is needed to compromise user accounts. Administering your firewall to block internal DNS queries also becomes less intuitive when the namespace is the same as the published Internet namespace for the organization. If the namespaces were separate, for example, a simple rule could be written to block any traffic to the internal domain structure. Another limitation would arise if an organization currently employs multiple namespaces to identify itself, and all those namespaces need to be joined into the same forest; in this case, a common namespace design is not an option. Mergers and acquisitions or even multiple business units within the same corporate parent can present these types of problems.

Choosing an Internal Namespace

If desired or required by your organization, the namespace that the AD DS structure inhabits can be internal, or not published to the Internet. Using internal namespaces adds a layer of complexity to your network because users’ UPNs are different from their email addresses. However, the increase in security that is realized from this design is also a factor that leads organizations to choose this route. Another factor that might influence your decision to choose an Internet namespace is that you are no longer limited to the InterNIC standard namespaces of .com, .net, .biz, .info, and so on. For example, many organizations use the .internal namespace, or some other namespace that is not used on the Internet.

Keep in mind that it is important to secure an internal namespace from registration anywhere on the Internet other than in your own network. In other words, if an organization registers, and another organization on the Internet registers the same domain name for its network, there could be naming conflicts with applications and other systems that perform DNS lookups against your forest. For example, if an application on a laptop usually attempts to access an internal namespace but then tries to access it remotely through an Internet service provider (ISP), the ISP’s DNS will forward you to the registered DNS name on the Internet. In a nutshell, if you are going to design your domain with an unpublished namespace but use a standard such as .net or .org that someone else could theoretically register, it is best to register and reserve that domain but not point it anywhere. Another common tactic is to name your domain something that will never be published, such as a root with your company’s stock ticker symbol (for example, network.msft), or by utilizing the .internal suffix, which has been specifically reserved for internal use only.

Examining Domain Design Features

AD DS has evolved over the years and has added additional functionality with Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and, finally, Windows Server 2008 R2. Some of these functionality improvements have changed some of the design concepts associated with Windows Server 2008 R2. These functionality changes are as follows:

  • Active Directory Recycle Bin— The ability to do a full-fidelity recovery of deleted objects in AD DS was introduced in this latest version of AD DS included with Windows Server 2008 R2. By adding this critical functionality, there is less worry that accidental deletion of user accounts, groups, or even entire OUs will cause major havoc, and there is subsequently less reason to create multiple domains in a forest simply to spread the risk of domain object deletion. Note that this capability is only available when the forest functional level is raised to Windows Server 2008 R2 functional level and when it is subsequently turned on in a domain.

  • Fine-grained password policies— The ability to have multiple password policies within a single domain was originally released in Windows Server 2008 and is still supported with Windows Server 2008 R2. The addition of this functionality means that many organizations that previously implemented additional domains because of the restriction of a single password policy per domain might be able to collapse those domains. Note that this functionality is only available in either Windows Server 2008 or Windows Server 2008 R2 domain functional levels.

  • Domain rename function— The capability to rename a domain in a Windows Server 2003/2008 forest has opened up a new field of possibilities for the design and potential redesign of AD DS domain structures. Previously, stern caveats were issued about the inability to rename domains or change the overall structure of an AD DS forest. With the domain rename functionality present in AD DS implementation, these limitations are lifted, and designers can take heart in the fact that design changes can be made after implementation. Having this ability does not change the fact that it is still wise to plan out your domain design thoroughly, however. Not having to make changes to domain names or reposition domains in a forest is much easier than having to go through the domain rename process. Just knowing that such functionality exists, however, is a breath of fresh air for designers.

  • Cross-forest transitive trusts— Introduced in Windows Server 2003, the concept of cross-forest transitive trusts lessens domain designers’ connectivity worries. In the past, some administrators balked at the limitations of collaboration within Windows 2000 AD DS structures. The cross-forest transitive trust capability of AD DS negates those concerns because multiple AD DS forests can now be joined via cross-forest trusts that are transitive, rather than explicit, in nature. The combination of these forests is known in the Microsoft world as federated forests. Note that both forests must be at Windows Server 2003 or Windows Server 2008 R2 functional levels for this feature to work.

  • Domain controller promotion from media— The capability to promote remote servers to domain controllers via a CD image of the global catalog helps to limit replication traffic and the time associated with establishing remote domain controllers. Windows Server 2003/2008 solves the issue of replication over the wide area network (WAN) by providing you with the ability to save the global catalog to media (like a CD-ROM), ship it to a remote site, and, finally, run domain controller promotion (dcpromo) and insert the data disk with the directory on it for restoration. Only the deltas, or changes made since media creation, are then replicated, saving time and bandwidth. The effect of this on domain design creation is reflected in reduced setup times, less network bandwidth consumption, and increased flexibility of global catalog domain controller placement.

Choosing a Domain Structure

There is a basic tenet to consider when designing the AD DS domain structure. Start simple, and then expand only if expansion is necessary to address a specific need. This concept is, by and large, the most important concept to remember when you’re designing AD DS components. In regard to domain design, this means you should always start the design process with a single domain and then add on to your design if your organizational concerns dictate that you do so. Following this basic philosophy during the design process will reduce headaches down the road.

When you’re designing the AD DS, you must contemplate a common framework for diagrams. In AD DS, for example, domains are often pictorially represented by triangles, as shown in Figure 1. So, when beginning your design, start with a single triangle.

Figure 1. Domain diagram representation as a triangle.

In this example, the fictional company named CompanyABC has begun the process of domain design. Depending on its unique needs, CompanyABC might decide to expand upon that model or keep it simplistic. These decisions should be made with a detailed knowledge of the different domain design models and the environments in which they work best.

Active Directory was designed to be a flexible, forgiving directory services implementation. This is even more true with Windows Server 2008 R2’s AD DS implementation. Consequently, there are multiple design models available to choose from, depending on the individual needs of organizations. The major design models are as follows:

  • Single domain model

  • Multiple domain model

  • Multiple trees in a single forest model

  • Federated forests design model

  • Peer-root model

  • Placeholder domain model

  • Special-purpose domain model

In reality, not all AD structures fall underneath these categories because the possibilities exist for numerous variations and mutations of AD structure. However, most domain structures either fall into these categories or are a hybrid model, possessing traits of two different models. Out of all these models, however, the single domain model is the most common design model and also happens to be the easiest to deploy.

Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us