IT Core Blog

Never stop questioning. Curiosity has its own reason for existing…

Domain Controllers and Active Directory Domains Part 4

with 8 comments

If you want to review part 1, part 2 or part 3 of these series click the hyperlinks.

In Part 4 (“a” & “b“) I’ll show you “How to create a child domain in a remote site” additionally I’ll also show you “How to pre-configure the DNS Zones and Delegations for a child domain“. This pre-configurations tasks are useful when you’re running older versions of Windows (2000/2003). In Windows 2008 R2 those DNS pre-configurations are not mandatory nor necessary because Dcpromo.exe will take care of all necessary configurations for you.

As stated in What Are Domains and Forests & Domains and Forests Technical Reference
Domains and Forests are logical representations of the directory hierarchy in Active Directory.

A forest is a complete instance of Active Directory. Each forest acts as a top-level container in that it houses all domain containers for that particular Active Directory instance. A forest can contain one or more domain container objects, all of which share a common logical structure, global catalog, directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. The first domain in the forest is called the forest root domain.

Each Domain is a container for a collection of administratively defined objects that share a common directory database, security policies, and trust relationships with other domains. In this way, each domain is an administrative boundary for objects.

Tree Root and Child Domains:
A domain tree represents a unique DNS namespace: it has a single root domain, known as the tree root domain, and is built as a strict hierarchy: Each domain above the tree root domain has exactly one superior, or parent, domain (the forest root domain). The namespace created by this hierarchy, therefore, is contiguous — each level of the hierarchy is directly related to the level above it and to the level below it. In other words, the names of domains created beneath the tree root domain (child domains) are always contiguous with the name of the tree root domain. The DNS names of the child domains of the root domain of a tree reflect this organization; therefore, the children of a root domain called Somedomain are always children of that domain in the DNS namespace (for example, Child1.somedomain, Child2.somedomain, and so forth).

Multiple domain trees can belong to a single forest and do not form a contiguous namespace; that is, they have noncontiguous DNS domain names. Although the roots of the separate trees have names that are not contiguous with each other, the trees share a single overall namespace because names of objects can still be resolved by the same Active Directory instance. A forest exists as a set of cross-reference objects and trust relationships that are known to the member trees. Transitive trusts at the root domain of each namespace provide mutual access to resources.
The domain hierarchy in a forest determines the transitive trust links that connect each domain. Each domain has a direct trust link with its parent and each of its children. If there are multiple trees in a forest, the forest root domain is at the top of the trust tree and, from a trust perspective, all other tree roots are children. That means authentication traffic between any two domains in different trees must pass through the forest root.

That said, here are some tips that you may need to consider before starting to think about additional domains within your forest:
– The First created Domain will ALWAYS be the ROOT Domain. It doesn’t matter if you rename it (only possible if your FFL is at 2003 or later) or if you move other domains within your forest logical structure.
– The ROOT domain is very important to the entire forest (this includes all existing domains) because it contains unique objects (for example: The Enterprise Admins and Schema Admins groups are located in this domain) and because by hierarchical design all domains will depend of the ROOT domain. This means that if you lose the forest ROOT domain , you’ll lose the entire forest logical structure. This also applies to to child domains and their parent domains.
– Each Domain should have at least 2 DCs (at minimum).
– When security boundaries are needed you need a second forest not a child domain nor a new Root Tree domain. Only forests are security Boundaries NOT Domains. Active Directory domains, unlike Windows NT domains, are always part of a forest, and they are not themselves the security boundary. For Windows 2000 and later networks, though, domains are the boundaries for administration and for certain security policies, such as password complexity and password reuse rules (Note: this has changed in Windows 2008 with Fine-Grained Password Policies), which cannot be inherited from one domain to another. Each Active Directory domain is authoritative for the identity and credentials of the users, computers, and groups that reside in that domain. However, service administrators have abilities that cross domain boundaries. For this reason, the forest is the ultimate security boundary, not the domain.
In most scenarios child domains or new Tree Root domains are created by the wrong reasons.
– Some reasons to create Multiple Domains: Meet security requirements, Meet administrative requirements, Optimize replication traffic, Retain Microsoft Windows NT domains. Do not create multiple domains to accommodate polarized groups or for isolated resources that are not easily assimilated into other domains. Both the groups and the resources are usually better candidates for organizational units (OUs).
When determining whether to create multiple Domains, keep the following items in mind:
– DNS structure becomes more complex.
– Hardware cost Increases.
– Each time a domain is added, a Domain Admins pre-defined global group is added as well. More administration is required to monitor the members of this group.
– Security principals. As domains are added, the likelihood that security principals will need to be moved between domains becomes greater. Although moving a security principal between OUs within a domain is a simple operation, moving a security principal between domains is more complex and can negatively affect users.
– Group policy and access control. Because group policy and access control are applied at the domain level (Note: in Windows 2008 Fine-Grained Password Policies can be applied at lower level), if your organization uses group policies or delegated administration across the enterprise or many domains, the measures must be applied separately to each domain.
– Domain controller hardware and security facilities. Each Windows Server 2003 domain requires at least two domain controllers to support fault-tolerance and multimaster requirements. In addition, it is recommended that domain controllers be located in a secure facility with limited access to prevent physical access by intruders.
– Trust links If a user from one domain must log on in another domain, the domain controller from the second domain must be able to contact the domain controller in the user’s original domain. In the event of a link failure, the domain controller might not be able to maintain service. More trust links, which require setup and maintenance, might be necessary to alleviate the problem.

That Said, let’s check the videos:

Domain Controllers and Active Directory Domains Part 4.a

Domain Controllers and Active Directory Domains Part 4.b

Check the next demo for “How to Create a new Domain Tree in a Remote Site” in Part 5 of this series.

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation



Written by IT Core

February 17, 2010 at 10:20 PM

Posted in Deployment, How to..., Videos

Tagged with

8 Responses

Subscribe to comments with RSS.

  1. […] the next demo for  “How to create a child domain in a remote site” in Part 4 of this […]

  2. […] in Active Directory How to add a Domain Controller in a Remote Site using the new Windows 2008 R2 How to create a child domain in a remote site Possibly related posts: (automatically generated)Domain Controllers and Active Directory Domains […]

  3. […] a comment » If you want to review part 1, part 2, part 3 or part 4 of these series click the hyperlinks. Possibly related posts: (automatically generated)Domain […]

  4. […] a comment » If you want to review part 1, part 2, part 3 or part 4 of these series click the […]

  5. […] one comment If you want to review part 1, part 2, part 3 or part 4 of these series click the […]

  6. […] a comment » If you want to review part 1, part 2, part 3, part 4 or Part5 of these series click the […]

  7. […] one comment If you want to review part 1, part 2, part 3, part 4 or Part5 of these series click the […]

  8. […] a comment » Click if you want to review part 1, part 2, part 3, part 4, Part5 or part 6 of Domain Controllers and Active Directory […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: