Designing a Windows Server 2012 Active Directory : Choosing a Domain Namespace - Examining Domain Design Features, Choosing a Domain Structure

3/6/2015 8:34:25 PM
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 selected namespace can be as simple as, for example, or he can be more complex. Multiple factors must be considered, however, before this decision can be taken. 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 myriad other possibilities exist.Several advantages with a published namespace are that it is easily accessible from the Internet and there is less of confusion on behalf of the user for the site on the network and the Internet. For example, a user named Eric Harlan 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 his 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 distinct, for example, a simple rule could be written to block any traffic with the structure of field internal. Another limitation emerges if an organization currently uses the multiple namespaces to be identified and all these namespaces must be joined in the same forest; in this case, a common design of namespace is not an option. The multiple fusions and acquisitions or even commercial units in the same relative of company 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 user 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 using 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, Windows Server 2008 R2, and finally Windows Server 2012. Some of these functionality improvements have changed some of the design concepts associated with Windows Server 2012. 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 Windows Server 2008 R2, but was greatly improved in this latest version of AD DS included with Windows Server 2012. By adding this critical functionality, there is less worry that accidental deletion of user accounts, groups, or even entire organizational units (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 available only when the forest functional level is raised to Windows Server 2008 R2 or later 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 2012 (and is becoming much easier to use, as well). 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 available only in Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012 domain functional levels.

Domain rename function—The capability to rename a domain in a Windows Server 2003/2008/2012 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 designer connectivity worries. In the past, some administrators balked at the limitations of collaboration within Windows 2000 Active Directory 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.

Domain controller virtualization support—Microsoft has added the capability to create domain controllers (DCs) from virtual machine templates, greatly improving the time it takes to build a new DC. At the same time, they have made it possible to have virtual DCs recovered from snapshots without the worry of corruption or lingering object issues. All of these virtualization features are new for AD DS in Windows Server 2012 and change the design options, allowing for much more advanced virtualization design options.

Server Core and PowerShell enhancements—Windows Server 2012 is the first version that makes it preferable to deploy an AD DS DC running on Windows Server Core, because all DC functionality can now be performed using PowerShell, and Server Core greatly reduces the security footprint of the DCs.

Domain controller promotion from media—The capability to promote remote servers to DCs 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/2012 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 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. With 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 simple. 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 2012 AD DS implementation. Consequently, multiple design models are 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 model

• Peer-root model

• Placeholder domain model

• Special-purpose domain model

In reality, not all AD structures fall within these categories; possibilities exist for numerous variations and mutations of AD structure. However, most domain structures either fit 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.

  •  Designing a Windows Server 2012 Active Directory : Understanding AD DS Domain Design - Examining Domain Trusts
  •  Review : Asus Wireless Duo
  •  Windows 7 Development : GETTING STARTED WITH THE RIBBON (part 2) - Obtaining RibbonLib
  •  Windows 7 Development : GETTING STARTED WITH THE RIBBON (part 1) - Obtaining the Windows 7 SDK
  •  Windows Server 2012 : Comprehensive Performance Analysis and Logging (part 11) - Monitoring performance from the command line
  •  Windows Server 2012 : Comprehensive Performance Analysis and Logging (part 10) - Configuring performance counter alerts
  •  Windows Server 2012 : Comprehensive Performance Analysis and Logging (part ) - Viewing data collector reports
  •  Windows Server 2012 : Comprehensive Performance Analysis and Logging (part 8) - Collecting performance counter data, Collecting performance trace data
  •  Windows Server 2012 : Comprehensive Performance Analysis and Logging (part 7) - Performance logging - Creating and managing data collector sets
  •  Windows Server 2012 : Comprehensive Performance Analysis and Logging (part 6) - Resolving disk I/O bottlenecks, Resolving network bottlenecks
    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
    programming4us programming4us