IIS
  Home arrow IIS arrow Page 7 - The Importance of a Domain
ASP Free Forums 
.NET  
ASP  
ASP Code  
ASP.NET  
ASP.NET Code  
BrainDump  
C#  
Code Examples  
Database  
Database Code  
IIS  
Microsoft Access  
MS SQL Server  
Silverlight  
Visual Basic.NET  
Windows Scripting  
Windows Security  
XML  
Mobile Linux 
App Generation ROI 
IBM® developerWorks 
ASP Web Hosting  
ASP.NET Web Hosting 
Windows Web Hosting
 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
IIS

The Importance of a Domain
By: PACKT Publishing
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 24
    2005-08-25

    Table of Contents:
  • The Importance of a Domain
  • Who's SAM?
  • Joining a Domain
  • What do I Need the Active Directory For?
  • The Main Event—Active Directory
  • The Blueprint of the Active Directory
  • Domains
  • Forests
  • Sites
  • RID Master FSMO Role
  • Domain and Forest Modes

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    The Importance of a Domain - Domains


    (Page 7 of 11 )

    The concept of a domain has remained in the Active Directory and as with an NT 4 style, a domain acts as a boundary of replication for domain naming context, which contains information about objects contained in the domain, for example users, security policies etc. This is the equivalent of the replication boundary of the SAM database under NT 4based domains.

    Domain controllers in a domain only receive information about the objects located in the domain. This replication boundary is what allows the Active Directory to scale so well by allowing multiple domains but not replicating all the information throughout the entire enterprise.

    Unlike Windows NT 4 domains, Active Directory domains are DNS (Domain Naming System) names, which is the format you see when using the Web. www.savilltech.com comprises a host record www in the DNS domain savilltech.com. Unfortunately, this is where some confusion can creep in, since Windows uses the term domain to define a group of computers sharing a common security database, whereas DNS uses the term domain to specify the name of a portion of the DNS namespace. For example, a DNS domain name could be savilltech.com but since Active Directory uses DNS for its naming mechanism, savilltech.com can now also be the name of an Active Directory domain.

    NT 4 domains had 15 character NetBIOS names. It was a flat single level so there was no hierarchy in the name; now we use DNS with a hierarchical name space allowing a hierarchal view of the systems. For example, sales.uk.savilltech.com and legal.acme.com are valid Active Directory domain names because they are valid DNS domain names. This will make more sense when we talk about trees. If you upgrade an NT 4 domain to Active Directory, you cannot change the NetBIOS name during the upgrade process. If you are creating a new domain, you can name the NetBIOS name anything you want; by default, it will be the first 15 characters up to the left-most period of the DNS domain name, so if your DNS domain name was sales.savilltech.com, by default your NetBIOS name would be sales.

    Because domain names are DNS names, a fully functional DNS infrastructure is mandatory; however Windows 2003 can help the configuration if necessary.

    Trees

    As we just saw in the previous section, Active Directory domains are now DNS names with a hierarchical structure. This allows the creation of an Active Directory domain hierarchy with a contiguous namespace, known as a tree. 

    The figure above shows a typical Active Directory tree. Notice the contiguous nature of the naming. The domain uk.savilltech.com has the name of its parent domain (savilltech.com) as part of its name.

    This hierarchy of domains is formed at the time of domain creation. When you run the DCPROMO wizard to promote a server to a domain controller, you are given the following options:

    • Make the server a new domain controller for an existing domain
    • Create a new domain as a child of an existing domain (which would add it to an existing tree)
    • Create a new domain in a new tree
    • Create a new domain in a new forest

    If you select 'Create a new child domain' you will be asked to enter the name of an existing domain and this entered domain will become the parent domain for the newly created domain.

    Under Windows NT 4, manual trust relationships could be created. Under the Active Directory when a child domain is created a transitive bi-directional Kerberos trust is automatically created between the parent and the child domain. This trust does not need to be manually managed; it is a feature of the parent-child relationship.

    Transitive trust is a change from NT 4 domains where, if domain A trusted domain B, and domain B trusted domain C, domain A did not automatically trust domain C. Under the Active Directory transitive Kerberos trust, this trust would automatically exist.

    Going back to our domain tree example (the previous figure) notice that each domain has a bi-directional trust with its parent/child and because these are transitive, it means every domain in the tree implicitly trusts every other domain.

    The relationships shown by the dashed lines in the figure above implicitly exist because of the transitive nature of the trust relationships between the parent and child domains.

    This is great for administrators, it means now any user or group from any domain in a tree can be granted access to any resource in any domain in the tree without a single trust relationship being created.

    We previously saw how domains acted as a boundary of replication, with each domain containing the information about the objects in the domain. This is known as the domain partition, which is one of the three logical partitions of the physical Active Directory database. This partition is also called the DomainNC (the Domain Name Container), which contains only that specific domain's data, such as user accounts, group accounts, computer accounts, and other objects that were created in that domain. Every domain has its own separate domain partition, and every domain controller in that specific domain has a full replica (copy) of that domain's domain partition, which is replicated among only those DCs in that specific domain.

    There are two other partitions within the Active Directory that are common to all domains in the tree, i.e. they all contain the same information and are replicated to all domain controllers in a forest:

    • Schema partition: As we previously saw, the schema is the blueprint for Active Directory and the schema partition is used to contain that blueprint definition. The fact that this schema partition is common to all domains in a tree should confirm the fact that all domains in a tree have a common schema. You cannot change the schema for just one domain in a tree; if a change is initiated anywhere in the tree it will propagate throughout the entire tree (in fact the schema can only be changed at one point in the tree which we will see soon). Every single domain in the tree has a replica of the same schema partition.
    • Configuration partition: This contains the replication topology and other configuration information that is common to the entire tree. This includes information about the domains in the tree, domain controllers and sites. Every single domain in the tree has a replica of the same configuration partition.

    Windows 2003 introduced a new directory partition type—the application directory partition. The application directory partition stores dynamic application-specific data in the Active Directory but rather than being replicated to all domain controllers in a domain or tree, the data is replicated only to domain controllers specified by the Administrator. Application directory partitions can contain any type of object apart from security principals (users, groups, and computers).

    The data contained can be configured to replicate to any domain controller in any domain within the tree or every domain controller in the tree. All of the domain controllers configured to host the application directory partition hold a replica of the information. However, only Windows 2003 domain controllers can host a replica of an application directory partition.

    Windows 2003 actually uses the application partition to enable the ability to replicate DNS information stored in the Active Directory to only specific domain controllers. You also have the option with Windows 2003 to replicate DNS information to only DNS servers in the forest or domain, which is implemented via two application partitions created automatically, DomainDNSZones and ForestDNSZones. Each domain has a separate DomainDNSZones partition (in the same way each domain has its own Domain partition) that every domain controller hosting the DNS service contains a replica of. The forest has a single version of ForestDNSZones, of which every domain controller hosting the DNS servers contains a replica.

    This overcame a limitation in Windows 2000 Active Directory, since these application partitions did not exist. When we created AD Integrated zones in Windows 2000, they were created in the Domain NC and therefore could not replicate to other domains. So if we needed that zone in a child domain (if not delegating to the child DNS or not using stub zones for the child DNS servers), or in another domain in the forest, we needed to create a secondary zone to make that available on the DNS server in the other domain. With Windows 2003, we can specify whether we would like this zone to replicate either domain wide or forest wide so that it will be available in the application partition so we can have that zone available in the other domain. We will explore this further in future chapters. These three core partitions are shown in the following diagram: 

    Each domain here has a different domain partition shared just between the domain controllers in the domain, while all domain controllers have a common schema and configuration-naming context.

    To summarize, a tree is a set of domains that form a contiguous namespace with parent/child domains connected via transitive Kerberos trusts. This means every domain in the tree trusts every other domain. The domains in a tree also share a common schema definition. How, then, will you handle more than one namespace? You will need another tree.

    More IIS Articles
    More By PACKT Publishing


     

    Buy this book now. This article is taken from chapter one of the book Windows Server 2003 Active Directory Design and Implementation: Creating, Migrating, and Merging Networks by John Savill (PACKT Publishing, 2005; ISBN: 1904811086). Check it out at your favorite bookstore. Buy this book now.

    IIS ARTICLES

    - Retrieving IIS information using ASP.NET 2.0
    - IIS 6.0, Getting Information Using WMI
    - The Importance of a Domain
    - Implementing a PKI, Part II: Configuring IIS...
    - Creating Test and Production Sites with Only...
    - Authentication and Authorization
    - Beefing Up IIS: 10 Tips From A Former Solari...
    - An Introduction To ISAPI
    - Secure Your Web Server With SSL
    - Introduction to HTML and ASP
    - Instructions to help in Designing your own C...





    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 5 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek