Applies To: Windows Server 2008, Windows Server 2008 R2
By using the Active Directory® Domain Services (AD DS) server role, you can create a scalable, secure, and manageable infrastructure for user and resource management, and you can provide support for directory-enabled applications, such as Microsoft® Exchange Server.
In the following sections, learn more about AD DS, features in AD DS, and software and hardware considerations. For more information about planning, deploying, and operating the AD DS server role, see Active Directory Domain Services (http://go.microsoft.com/fwlink/?LinkID=48547).
A directory, in the most generic sense, is a comprehensive listing of objects. A phone book is a type of directory
that stores information about people, businesses, and government organizations. Phone books typically record names, addresses, and phone numbers. AD DS is similar to a phone book in several ways, and it is far more flexible. AD DS will store information about
organizations, sites, computers, users, shares, and just about any other network object that you can imagine. Not all objects are as similar to each other as those stored in the phone book, so AD DS includes the ability to record different types of information
about different objects.
AD DS reflects Microsoft's trend toward relying on standard protocols. The Lightweight Directory Access Protocol (LDAP) is a product of the
IETF (Internet Engineering Task Force). It defines how clients and servers exchange information about a directory. LDAP version 2 and version 3 are used in AD DS .
It is very important to understand the structure of
distinguished names, as you will be referring to them often in the course of your job. My distinguished name is /O=Internet/DC=COM/DC=Microsoft/ DC=MSPress/CN=Users/CN=Tony Northrup. Consider the following figure, which shows how I fit into a sample AD DS
tree. The distinguished name I gave starts to make some sense—it identifies each container from the very top down to my specific object. Each container is separated by a slash and an identifier. For example, COM, Microsoft, and MSPress are each preceded by
/DC=. The DC stands for Domain Component, which identifies a DNS domain.
To simplify distinguished names, relative distinguished names can also be used. The relative distinguished name of the
previous example is CN=Tony Northrup, identifying the user name but not the context in which it resides. The context must be known already for the relative distinguished name to be an effective identifier.
Distinguished names are great for computers but too cumbersome for people to remember. People have grown accustomed to e-mail addresses, so AD DS provides these addresses as a shortcut to the full object name. In Figure 11-9, Tony Northrup is a user of
the mspress.microsoft.com domain. An administrator could create a user principal name within the microsoft.com domain to allow simpler access to my user account and hold a place for my e-mail address, like firstname.lastname@example.org.
Users will rely on their user principal name to log onto their computers. In other words, user principal names will replace the user names used in older Windows networks. Obviously, this helps the users by saving them the trouble of typing their distinguished
names. However, it also benefits users because the user principal name will stay the same even if administrators move or rename the underlying user account.
AD DS provides a distributed database that stores and manages information about network resources and application-specific data from directory-enabled applications. Administrators can use AD DS to organize elements of a network, such as users, computers,
and other devices, into a hierarchical containment structure. The hierarchical containment structure includes the AD DS forest, domains
in the forest, and organizational units (OUs) in each domain. A server that is running AD DS is called a
Organizing network elements into a hierarchical containment structure provides the following benefits:
Security is integrated with AD DS through logon authentication and access control to resources in the directory. With a single network logon, administrators can manage directory data and organization throughout their network. Authorized network users can
also use a single network logon to access resources anywhere in the network. Policy-based administration eases the management of even the most complex network.
Additional AD DS features include the following:
Identity Management for UNIX is a role service of AD DS that can be installed only on domain controllers. Two Identity Management for UNIX technologies, Server for NIS and Password Synchronization, make it easier to integrate computers running Microsoft
Windows® into your existing UNIX enterprise. AD DS administrators can use Server for NIS to manage Network Information Service (NIS) domains. Password Synchronization automatically synchronizes passwords between Windows and UNIX operating systems.
Active Directory Administrative Center
Active Directory Administrative Center provides users and network administrators with an improved data management experience and a rich graphical user interface (GUI) to perform common Active Directory object management tasks. Built on Windows PowerShell™
technology, Active Directory Administrative Center makes it possible for users and network administrators to administer directory service objects through both data-driven navigation and task-oriented navigation.
Active Directory module for Windows PowerShell
The Active Directory module for Windows PowerShell is a command-line interface that administrators can use to configure and diagnose all instances of Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS) in
This feature includes a set of Windows PowerShell cmdlets and a provider. The provider exposes the Active Directory database through a hierarchical navigation system, which is very similar to the file system. As with drives in a file system (C:, D:), you
can connect Windows PowerShell drives to Active Directory domains and AD LDS instances, as well as Active Directory snapshots.
Active Directory Recycle Bin
Active Directory Recycle Bin minimizes directory service downtime by improving the ability to preserve and restore accidentally deleted Active Directory objects without having to restore Active Directory data from backups, restart AD DS, or restart domain
controllers. When Active Directory Recycle Bin is enabled, all link-valued and non-link-valued attributes of the deleted objects are preserved and the objects are restored in their entirety to the same consistent logical state that they were in immediately
before deletion. For example, restored user accounts automatically regain all group memberships and corresponding access rights that they had within and across domains immediately before deletion. Active Directory Recycle Bin is functional for both AD DS and
AD LDS environments.
Active Directory Recycle Bin requires the Windows Server 2008 R2
forest functional level, and it is disabled by default. To enable it, you can use Ldp.exe or the Windows PowerShell
Active Directory Web Services (ADWS)
ADWS is a Windows service that provides a Web service interface to AD DS and AD LDS directory service instances and to Active Directory snapshots
that are running on the same Windows Server 2008 R2 server as ADWS. ADWS is installed automatically when you add the AD DS or AD LDS server roles to your Windows Server 2008 R2 server.
Authentication Mechanism Assurance
Authentication Mechanism Assurance packages information about the type of logon method (smart card or user name/password) that is used to authenticate domain users inside each user’s Kerberos
token. When this feature is enabled in a network environment that has deployed a federated identity management infrastructure, such as Active Directory Federation Services (AD FS), the information in the token can then be extracted whenever a user attempts
to access any claims-aware application that has been developed to determine authorization based on a user’s logon method.
Authentication Mechanism Assurance requires the Windows Server 2008 R2
domain functional level.
Offline domain join
An offline domain join is a new process that computers running Windows® 7 or Windows Server 2008 R2 can use to join a domain. The offline domain join process can complete the domain join operation without network connectivity.
After you finish installing the operating system, you can use Initial Configuration Tasks or Server Manager to install server roles. To install the AD DS server role, click
Add roles to start the Add Roles Wizard, and then click
Active Directory Domain Services. Follow the steps in the Add Roles Wizard to install the files for the AD DS server role. After you complete the Add Roles Wizard, click the link to start the Active Directory Domain Services Installation Wizard.
Follow the steps in the Active Directory Domain Services Installation Wizard to complete the installation and configuration of your domain controller. Most wizard pages have a Help link for more information about the settings that you can configure.
To automate domain controller installations, you can use an answer file or you can specify unattended installation parameters at the command line. For more information about installing AD DS, see the AD DS Installation and Removal Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=110897).
You can manage server roles with Microsoft Management Console (MMC) snap-ins. To manage a domain controller (that is, a server
that is running AD DS), click Start, click Control Panel, click
Administrative Tools, and then double-click the appropriate snap-in:
As an alternative, you can double-click the appropriate snap-in on the
Active Directory Domain Services page in Server Manager.
AD DS plays an important role in the future of Windows networking. Administrators must be able to protect their directory from attackers and users, while delegating tasks to other administrators where necessary. This is all possible using the AD DS security
model, which associates an access control list (ACL) with each container, object, and object attribute within the directory. The following figure shows
a step from the Delegation Of Control wizard, a helpful utility for assigning permissions to AD DS objects.
This high level of control allows an administrator to grant individual users and groups varying levels of permissions for objects and their properties. Administrators can even add attributes to objects and hide those attributes from certain groups of users.
For example, the administrator could set the ACLs such that only managers can view the home phone numbers of other users. Nonmanagers would not even know that the attribute existed.
A concept new to Windows Server is delegated administration. This allows administrators to assign administrative tasks to other users, while not granting those users more power than necessary. Delegated administration can be assigned over specific
objects or contiguous subtrees of a directory. This is a much more effective method of giving authority over the networks; rather than granting someone the all powerful Domain Administrator permissions, he or she can be given permissions for just those computers
and users within a specific subtree. AD DS supports inheritance, so any new objects inherit the ACL of their container.
Try to forget what you've learned about Windows NT domain trusts. The term
trusts is still used, but trusts have very different functionality. There is no distinction between one-way and two-way trusts because all AD DS trusts are bidirectional. Further, all trusts are transitive. So, if Domain A trusts Domain B, and Domain B
trusts Domain C, then there is an automatic implicit trust between Domain A and Domain C. This new functionality is shown in the following figure.
Another AD DS security feature is auditing. Just as you can audit NTFS partitions, objects and containers within AD DS can be audited. This is a useful way to determine who is attempting to access objects, and whether or not they succeed.
Domain Name System, or DNS, is necessary to any Internet-connected organization. DNS provides name resolution between common names, such as mspress.microsoft.com, and the raw IP addresses that network layer components use to communicate. AD DS makes extensive
use of DNS technology and relies on DNS to locate objects within AD DS. This is a substantial change from previous Windows operating systems that require NetBIOS
names to be resolved to IP addresses, and to rely on WINS
or another NetBIOS name resolution technique.
AD DS works best when used with Windows Server–based DNS servers. Microsoft has made it easy for administrators to transition to Windows Server–based DNS servers by providing migration wizards that walk the administrator through the process. Other DNS servers
can be used, but administrators will need to spend more time managing the DNS databases. If you decide not to use Windows Server–based DNS servers, you should make sure your DNS servers comply with the new DNS dynamic update protocol. AD DS servers rely on
dynamic update to update their pointer records, and clients rely on these records to locate domain controllers. If dynamic update is not supported, you will have to update the databases manually.
Note: DNS dynamic update protocol is defined in RFC 2136.
Windows domains and Internet domains are now completely compatible. A domain name such as mspress.microsoft.com will identify AD DS domain controllers responsible for the domain, so any client with DNS access can locate a domain controller. AD DS clients
can use DNS resolution to locate any number of services because AD DS servers publish a list of addresses to DNS using the new features of dynamic update. These addresses identify both the domain and the service being provided and are published via Service
Resource Records (SRV RRs). SRV RRs follow this format:
AD DS servers provide the LDAP service for object location, and LDAP relies on TCP as the underlying transport-layer protocol. Therefore,
a client searching for an AD DS server within the mspress.microsoft.com domain would look up the DNS record for ldap.tcp.mspress.microsoft.com.
AD DS provides a global catalog (GC). No, this does not mean that you can find any piece of information on the planet—but it is still
very significant. AD DS provides a single source to locate any object within an organization's network.
The global catalog is a service within Windows Server that allows users to find any objects to which they have been granted access. This functionality far surpasses that of the Find Computer application included in previous versions of Windows, because users
can search for any object within AD DS: servers, printers, users, and applications. For example, the following figure shows how a user can search for all color printers in his or her building that have the capability to print double-sided documents.
This feature is especially important because of the complexity of LDAP names. Older versions of Windows relied on 15-character NetBIOS computer names, which users could often remember. Few people would be able to recall LDAP names, such as the following:
Because users can easily search for objects, remembering names is much less important.
The GC is an index stored on AD DS servers. It contains the names of all objects in the AD DS server, regardless of how the server has been partitioned. The GC also contains a handful of searchable attributes for each object. For example, the GC would store
the distinguished names, first names, and last names of all users—allowing someone to search for anyone named Tony and find the distinguished name of the user. The global catalog is a subset of AD DS, and stores only those attributes that users tend to search
on. Useful defaults are provided by Microsoft, and administrators can specify other attributes to be searchable by using the AD DS Schema, described later in this chapter.
Not All Indexes Are Created Equal!
If you have done any database administration, you already know that some types of information are more useful to index than other types. Naturally, you should index attributes that will be searched for often, but there are other factors involved. Indexes
take up space, so it is not efficient to index everything. Indexes also slow down updates and inserts—if an indexed attribute is modified, the index must be modified as well. Indexing works better when the data being stored varies from user to user. Therefore,
never index true or false attributes or any attribute with less than five possible values. Names are an excellent attribute to index since they are almost unique for each user. Finally, don't index attributes that aren't usually filled in. If few users enter
a value for their middle name, the indexing of that attribute is a waste.
As new objects are created in AD DS , they are assigned a unique number called a GUID (globally unique identifier). The GUID is useful because
it stays the same for any given object, regardless of where the object is moved. The GUID is a 128-bit identifier, which isn't particularly meaningful to users, but applications that reference objects inAD DS can record the GUIDs for objects and use the global
catalog to find them even after they've moved.
Administrators who implement AD DS will quickly discover that their network relies heavily on its services. This reliance means that AD DS must be available on multiple servers—so that if a single server fails, clients can contact a server with duplicate
services and information. Unlike the Windows NT domain databases used with previous versions of Windows NT, updates to the database can be sent to
any of the AD DS servers. While this complicates the replication process, it eliminates the possibility that the failure of a single domain controller would stop updates to the databases. It also reduces the high load placed on Windows NT 4.0 primary
AD DS includes a replication component that makes this a simple task for administrators. Simply adding domain controllers to an AD DS is sufficient to begin the replication process.
One of the most complex parts of making redundant servers work properly is replicating the information and ensuring that all servers have the most up-to-date content. AD DS uses
multimaster replication, which is another way of stating that updates can occur on any AD DS server. Each server keeps track of which updates it has received from which servers, and can intelligently request only necessary updates in case of a failure.
Each update is assigned its own 64-bit unique sequence number (USN) from a counter that is incremented whenever a change is made. These updates
are system-specific, so every AD DS server maintains a separate counter.
When a server replicates an update to other AD DS domain controllers, it sends the USN along with the change. Each server maintains an internal list of replication partners and the highest USN received from them. The server receiving the update requests
only those changes with USNs higher than previously received. This method has the added benefit of stopping updates from propagating endlessly between multiple AD DS domain controllers.
One problem inherent in any multimaster replication scheme is that updates to a single object can occur in multiple places at the same time. For example, if an administrator in Boston changes a user's name from "Curt" to '"Kurt" and an administrator in Chicago
simultaneously changes that same user's name from "Curt" to "Kirk," a replication collision will occur. There are two problems to deal with when a collision occurs: detecting the collision and resolving the collision.
AD DS stores property version numbers to allow replication collision detection. These numbers are specific to each property of every object within AD DS and are updated every time the property is modified. These numbers are propagated through AD DS
along with the change, so a server that receives two different updates to the same property with the same property version number can conclude that a replication collision has occurred.
AD DS domain controllers resolve collisions by applying the update with the later timestamp. The timestamp is created by the server that initiated the change, so it is very important to keep system time synchronized between servers.
Note: Use the built-in distributed time synchronization service to keep all servers working together!
Large networks can contain hundreds of thousands of objects. Windows NT required multiple domains to allow that many objects to be manageable. Administrators often divided users and resources into separate domains and created a trust between the domains.
The structure of the databases simply did not allow them to grow to hundreds of thousands of objects. These size limitations are less a factor in AD DS domains, thankfully. However, supporting a very large AD DS could be an incredible burden to any single
Active Directories can be partitioned to lessen this load. Partitioning allows different domain controllers to manage different sections of the database, reducing the load on any individual server. The clients can use resources located within different AD DS
partitions transparently. Therefore, administrators can manage massive AD DS domains without requiring domain controllers to handle the entire database.
Many people are initially confused by the relationship between object
attributes, and the objects themselves. Objects are created based on an object class. Attributes describe an object class. When an object
is created, it inherits all the attributes of its object class. Here's where it gets tricky:
object classes and attributes are also objects in AD DS. Fortunately, most user interfaces hide this fact.
An object can be either a reference to something concrete or the actual useful information itself. For example, every bit of information about a user account is stored within AD DS. However, only a reference to a disk volume is stored in AD CS. While the
reference is not useful by itself, it is used to locate the volume on the file server. When creating new object classes, carefully consider whether the object will store a reference to something external or whether all necessary information will be contained
in the object's attributes. While AD DS is extremely convenient, it should not be used to store large amounts of information, constantly changing information, or rarely used information.
Anytime you add a user or a computer to AD DS, you are creating an object. Creating an object is often referred to as
publishing, because it kicks off a process of replicating the new information across all AD DS domain controllers in the domain.
A schema is a set of attributes used to describe a particular object class in AD DS. Different types of information need to be tracked for
different object classes, and that's why the schema is so important. For example, the Users object class needs attributes for a first name, last name, phone number, e-mail address, and mailing address. The Printer object class must have many different attributes—users
will want to know how fast a printer is and whether it can duplex or print in color. These attributes can be viewed and edited using the AD DS Schema MMC snap-in, as shown in the following figure.
Experienced programmers and system administrators can manage the AD DS schema, but the AD DS Schema snap-in is not installed by default. In addition, the Schmmgmt.dll file (regsvr32 schmmgmt.dll) must be registered from an
elevated command prompt before the snap-in can be installed. The AD DS Schema does not have an icon within the Start menu; you must launch the MMC interface and add the snap-in named AD DS Schema.
By default, object classes come with a logical set of attributes that will fit most organization's needs. However, many organizations will need to track additional information about particular object classes. For example, if employees are assigned a badge
number, it is useful to track that information in the object class. The first step is to create an attribute called BadgeID, as shown in the following figure. The second step is to make the new attribute optional for the Users class.
The schema is stored within AD DS just like other objects. Therefore, the schema inherits the ability to be automatically replicated throughout a domain. It also benefits from the security features of AD DS, and allows administrators to delegate authority
over the schema to different users and groups. By changing the ACLs on a schema object, an administrator can allow any user to add or modify attributes for an object class. The example in the following figure shows that the group East Coast Administrators
has been granted full control over the schema.
New attributes have several properties that must be set. The user creating a new attribute must define a name for the attribute (such as Badge ID #), the type of data to be stored (such as a string or a number), and the range limits (such as string length).
A unique Object Identifier (OID) must also be provided. New attributes can be indexed, which adds the attributes to the global catalog. Indexes should be created for attributes that users will search with. In this example, if security needs to look up user
accounts by the Badge ID number, this attribute should be indexed. For a search to occur on a nonindexed attribute, a slow and processor-intensive walk of the directory tree must be done.
Where Do Object Identifiers Come From?
The only way to ensure Object Identifiers are globally unique is to have a central agency that assigns
OIDs. This is already common practice on the Internet; the InterNIC assigns domain names and the Internet Assigned Numbers Authority (IANA) assigns IP subnets. Object Identifiers are assigned by a National Registration Authority, or NRA. NRAs vary from
country to country. In the United States, the American National Standards Institute (ANSI) provides NRA services. For a modest fee,
ANSI can supply your organization with a root OID. Any objects created by your organization will have this root OID as the prefix, ensuring that Object Identifiers are globally unique.
A list of NRAs can be found at the International Standards Organization's Web site, at
The schema is cached by AD DS domain controllers for performance reasons. It will take up to five minutes for the cache to be updated after you change the schema. So, wait a few minutes before you try to create objects based on your new object classes and
attributes. If you must reload the cache immediately, add the attribute schemaUpdateNow to the root object (the object without a distinguished name), and set the value to 1.
Extending the schema of AD DS is a powerful capability. However, most administrators will never need to use anything but the classes and attributes Microsoft has provided by default.
ADSI (Active Directory Service Interface) allows applications to interact with any directory service without being forced to know the internal
details of the underlying protocols. Administrators can write programs and scripts that make use of ADSI to read or write to legacy Windows NT 4.0 directories, NetWare NDS directories, NetWare 3 binderies, and LDAP directories such as AD DS. Developers can
even create applications that make use of directories at the customer's site, without previous knowledge of the type of directory being used.
For example, the following Microsoft Visual Basic code uses ADSI to display a list of users in the debug window:
Set ou = GetObject("ldap://dcserver/OU=Sales,DC=ArcadiaBay,DC=COM")
For Each obj In ou
As you can see, gathering a list of users is much simpler than in previous Windows operating systems. ADSI makes use of the Component Object Model (COM),
so almost any Windows development environment can immediately make use of the interface. Developers will be interested to know that they can access Active Directory through the LDAP C API
MAPI, though ADSI is the preferred interface.
Note: The LDAP C API is defined in RFC 1823.