Introduction to AD DS

 Image found at

Microsoft Active Directory has been around for quite some time. In fact, it has become a primary means of centralizating user account control in most organizations. Understanding and reviewing key AD (Active Directory) concepts is important to the having a fundamantal understanding of modern Systems Administration. With the release of Windows 2008, Microsoft is know naming AD, Active Directory Domain Services or AD DS. 
The goal of this blog entry is to familiarize the reader with some of the foundation topics of AD DS. Those concepts include: An understanding of Domain Services, Security, Components, Naming Standards, and Functional Levels. In a Microsoft Windows network, AD DS is an essential service that allows a systems administrator to manage the security of the network and related resources.
What is AD DS?
AD DS is effectively a service that runs on Windows Server that allows a systems administrator to define, manage, access and secure network resources. Important to note that with the newer versions of Windows Server there are now actually two components that achieve this purposes. The first component is called AD DS (Active Directory Domain Services) which provides a full directory service and AD LDS (Active Directory Lightweight Directory Services) which Microsoft claims is a flexible platform that provides AD DS like functionality without all the overhead.  The concept of Directory Services on a Windows Server is commonly associated with that of a Domain Controller. Important to note that any Windows Server configured to run the AD DS service is considered to be a DC (Domain Controller). Therefore, the primary participants in the management of an AD DS are the member DCs. Replication is the process that these DCs communicate updates and changes to each other regarding the Active Directory.  A DC can participate in both inbound and outbound replication (receiving and sending changes to another DC). By having a central directory service, managed by DCs that replicate and communicate changes  it is possible to simplify the management of network resources by extending AD DS capabilities to devices, applications, and other network resources.

 Image found at:

AD DS Security
The primary reason for AD DS is that of security. The ability to centralize authentication requests in a single directory services is the primary purpose of implementing a Directory Service on a network. Microsoft has been using AD since Windows 2000 to provide this centralized security mechanism. As each susequent release more features and capabilities have been made available to the Domain Controller and authenticating resources. Although, with Windows 2008, AD DS no longer supports the direct participation of NT 4.0 DCs, any domain controller in the Windows 2000+ family can participate in an AD DS replication scenario. This is accomplished through what is called domain functional levels. The primary benefits of a centralized security authentication source is the realization that a user can access any server with in a domain through a single-sign account. In addition, a systems administrator can publish objects and make them available as a network resource that will be listed for future access in the Directory Service.  Other benefits are also important such as the failover of the AD DS between DCs in case of a network or other outage. This centralized administration feature with redundant servers managing a domain’s directory service is made possible through a specialized database. This database takes the form of the ntds.dit file the remains resident on each DC. Windows Server 2008 introduces a new concept called a RODC (Read Only Domain Controller) that maintains a read only copy of the ntds.dit file. This is ideal for Branch Office deployments. 

Image found at

AD DS Components – Good Idea Read the Wiki –
The most difficult part of understanding AD DS is the grasping the complex terminology associated with the service. Different names are used to assign meaning to the various components that make up an AD architecture. Borrowing from existing terminology from LDAP (Lightweight Directory Access Protocol), each component in Active Directory is named and associated with a context as container or leaf objects. The resulting tree-like topology provides flexible designs, secure scenarios, and the ability to scale to larger directories that span multiple organizations. In AD language any object that is considered a container can contain other container objects or leaf objects. There are many container type objects including Forest and Domain. The Forest container object is the largest container in Active Directory. A Forest enables the single user access to resources across the entire container. Leaf objects cannot contain other objects and are usually considered resources such as a printer, folder, user or group. As the AD DS has gotten more complex a need has arisen to partition the or divide the information about these containers and leaf objects into naming contexts (NCs). The two NCs that are replicated forest wide and are stored in the ntds.dit file are the Schema NC and the Configuration NC. These two components are important to understanding the AD DS vocabulary. The Schema NC contains rules and definitions for creating and modifying object classes within Active Directory, it does not store any actual values. Every object created in an AD is based on a class with attributes in the Schema. Thus the schema has two essential components the classes and their attributes. Some common attributes are a globally unique identifier (GUID), required attributes and optional attributes. The Configuration NC has information regarding the physical topology of the network. Finally, each DC has a copy of the Domain NC that holds the user, computer and other information relevant to the particular domain. Another partition called the Application Partition allows administrators to determine where information will be replicated in the domain or forest. An important aspect of a Forest, called the global catalog is replicated forest wide is not actually a formal partition of Active Directory but a much needed catalog for improving the speed of access to resources. 
A AD Forest is further divded to create administrative boundaries. These are called Trees, which are a logical groupings of network devices and resources that contain one or more domains. At the domain level, users and resources can be further divided into Organizational Units (OUs). An OU is a container object that allows a way to logicalally seperate resource with similary security requirements. OUs are organized into hierarchial fashion in a Parent/Child relationship allowing for the nesting of multiple OUs in a hierarchial fashion. Important to note is that policies and other security settings applied at the domain level are inherited by each OU in hierarchy unless it is specifically prevented. A clever aspect of AD DS management is the ability to delegate OU administration. This allows department specific tasks to be delegated to a user within that department, thus keeping a centralized directory structure with the ability for decentralized administration.
The physical aspects of the AD DS is stored in what is called Sites. Sites represent the physical topology of the network and divide the replication topology of a forest by IP subnet. Replication between DCs can be controller by scheduled interval across Site boundardies. An automated service called the KCC (Knowledge Consistency Checker) creates a topology of site links for this process to occur. 

AD DS Naming
With some time, an administrator can become fluent in the terminology associated with AD. However, with the possibility of millions of container objects, leaf objects, forest, trees, domain, OUs it is absolutely necessary to have a naming convention so that applications and devices can take advantage of AD. The industry standard LDAP is used as a common mechanism exchange data between directory services and applications. Consequently, AD DS is based on LDAP, is compatible with LDAP, and more importantly bases its naming convention and structure on LDAP. Consquently, there are several other terminologies that one must become familiar with in regards to AD Naming of objects. First is the Distinguished Name (DN) which defines an object in the AD structure and includes its hierarchial path. LDAP attributes contain, therefore, the Common Name (CN), Organizational Unit (OU) Name, and related Domain Components (DC). Although the naming structure is based on LDAP, name resolution occurs in AD through Domain Name Services (DNS). DNS functionality is absolutely critical to AD functionality. DNS provide the mapping of host names to IP addresses in a network, and Active Directory also relies on DNS to be a locator service for clients trying to reach the correct server for a desired operation. This is accomplished primarily through SRV resource records stored in DNS.

Image taken from

AD DS Funtional Levels
As explained, functional levels allow for DC integration with older versions of Windows Servers. Functional levels can be changed in order to take advantage of new AD DS capabilities and prevent integration with incompatible DCs. In multiple domain enviornments, domains can be on different domain functional levels. Once a domain functional level has been raised, the action is irreversible. The current domain functional levels in Windows 2008 Server are as follows:
  • Windows 2000 Native Mode – Install from Media, Application Partitions, Drag and Drop UI, Global Group Nesting, Universal Security Groups, SIDHistory
  • Windows Server 2003 Mode – Also allows for last logon timestamp attributes, password and inetOrg Person objects, Ability to Rename Domain through netdom.exe, zombie detection, universal group caching, storing of DNS zones in application partitions, redirection of users and computers containers, selective authentication
  • Windows Server 2008 Mode – Fine grained password policies, read only domain controllers, advanced encryption services, granual auditing, sysvol replication via distributed file system replication, last interactive logon information
It is important to note the functionality the is available in each of the domain functional levels. 
There is also a forest functional levels which extend forest functionality throughout all domains in the forest. Windows 2000 Forest Functional Level is the default for Windows 2008 forest installation. There are important considerations when raising the forest functional level. 
  • Windows 2003 Forest Functional Level allows for Forest trusts, Domain Renames, Linked-Value Replication, Deployment of RODC,  ISTG Improvements, dynamicObject auxillarly class, conversion of iNetOrg person to a user and back, application basic groups, deactivation and redefinition of attributes in schema.
  • Windows 2008 Forest Functional Level does not allow for additional features other then only allowing for Windows 2008 DCs. 
Mr. Daniel Petri has good articles recaping both of these concepts, worthy of careful review:

AD DS Trusts
The final terminology of AD DS to consider is that of trusts. A trust relationship allows Windows 2008 server access to other domains across an enterprise. A trust relationship is when an administrator of one domain grants access to resources for administrators from another domain. A shortcut trust is a direct path between two domains to expedite the process of creating a trust relationship and is particularly useful in a slow wan link enviornment.  An external trust can be created allowing users to have access to a trusted domain. This type of trust is one way, meaning users in the trusted domain will not automatically have access to resources in the trusting domain. A cross forest trust can be created allowing domains at Windows 2003 Functional Level to establish one way or two way relationships. A good article:

 Image taken from

Leave a Reply

Your email address will not be published. Required fields are marked *