Active Directory Concepts

The Evolution of Microsoft Directory Services

Concept & Design By. Vishal V. Bangera

Active Directory
What is an Directory ?

Directory Service Functionality Organize

Centralized Management

Manage Control

Resource s

Single point of administration Full user access to directory resources by a single logon

E.g.. Yellow pages directory or a Telephone Directory

Why is it called Active? Dynamically Available Dynamically Updateable Protected by DACLs

Methods for Administering a Windows 2003 Network

Using Active Directory for Centralized Management Managing the User Environment Delegating Administrative Control

Using Active Directory for Centralize Management

Domain

Search
OU1 Domain OU2

OU1 Computers Computer1 Users User1 OU2

User1 Computer1 User2 Printer1

Users User2 Printers Printer1

Active Directory: Enables a single administrator to centrally manage resources Allows administrator to easily locate information Allows administrators to group objects into OUs Uses Group Policy to specify policy-based settings

Managing the User Environment

12

3
Windows 2000 Enforces Continually

Domain OU1 OU2 OU3

Apply Group Policy Once

1 2

Use Group Policy to: Control and lock down what users can do Centrally manage software installation, repairs, updates and removal Configure user data to follow users whether they are online or offline

Delegating Administrative Control

Domain OU1 Admin1

Assign Permissions:

OU2 Admin2 Admin3

For specific OUs to other administrators OU3 To modify specific attributes of an object in a single OU To perform the same task in all OU

Customize Administrative Tools to:

Map to delegated administrative tasks Simplify interface design

Windows NT and SAM

Non-hierarchical structure and namespace - NTs directory used a flat, nonhierarchical directory structure that didnt support the naming and structural needs of complex organizations. Lack of extensibility NTs directory stored only basic user information and couldnt be inherently extended. Lack of scalability The NT directory was stored inside the NT system registry database; due to this architecture, the maximum number of users topped out in the neighborhood of around 40,000 per domain. Poor manageability features Administration roles werent layered and couldnt be natively delegated. Poor directory replication performance Because NTs architecture was bandwidth- and network topology-ignorant, the NT operation system couldnt automatically tune replication frequency and bandwidth usage to adapt to variable WAN link speeds between multiple physical locations within a network. Single-master, Single point of failure architecture NTs architecture called for a single server in each network domain the Primary Domain Controller (PDC) to house the master copy of the directory, thus making it a single point of failure for logon authentication for the entire domain.

Windows NT SAM Models

Single Domain Master Domain

Domain Domain

RES1

RES2

Multi-Master Domain Complete Trust Domain

Domain1 ACCT1 ACCT2 Domain2

RES1

RES2 RES3 RES4

Domain3

Domain4

Windows 2003 and Active Directory

Windows NT SAM was not very accessible outside the operating system. Windows NT SAM was not suitable for supporting network applications such as Exchange Server. To overcome the above, Windows 2003 incorporated the directory structure from Exchange 4.x Services and naming it as Active Directory (AD).

The AD was compliant with X.500 namespace and LDAP and was exposed programmatically as well.
Administrators can manage AD using LDAP-compliant tools, such as Active Directory Service Interface (ADSI) Edit and Ldp.exe (the LDAP-compliant AD administration tool). AD database file can scale up to 70 terabytes, a dramatic capacity advance over the SAMs limitation of 40 MB.

Based on X.500 namespace hierarchy and LDAP The X.500 namespace is a hierarchical naming structure that identifies the unique path to the directory services container and also provides a unique identifier (OID) for each object in that container. LDAP is both an access protocol and a directory service model. Centralized Directory AD servers as a single, centralized directory service that can be implemented across an enterprise, simplifying network administration. It also allows applications to use the directory as an central repository for configuration.

Single Sign-On Users anywhere in the forest can log on to the network using their user principal name (UPN) identity (for example, vishalb@testdomain.com)
Delegated Administration AD offers administrators the ability to delegate administrative rights. Using the Delegation Of Control Wizard, or by setting specific permissions on AD objects, administrators can offer finely-tuned administrative rights.

Common Management Interface Microsoft Management Console (MMC) provides consistent look and feel for all the administrative tools and functions. Integrated Security AD works hand in hand with the Windows 2003 security subsystem to authenticate security principals and to protect the security of shared network resources. The Windows 2003 operating system supports two protocols for network authentication within and between Windows Server 2003 domains, including the Kerberos v5 protocol and the NT LAN Manager (NTLM) protocol. Scalability AD is designed to be scalable in order to keep up with the growth. You can choose to expand the size of the domain model or you can simply add more servers to accommodate the need for increased capacity. A single domain, the smallest partition of AD infrastructure that can be replicated on a single domain controller, can support in excess of 1 million objects, so the single domain model will support even large organizations.

The Directory Data Store (NTDS.DIT)

The actual database file is called ntds.dit. Default, its found in a directory off the %systemroot% folder (for example, C:\winnt) called ntds. A pristine copy of the base Win2003 AD database is also stored in %systemroot%\system32\ntds.dit. This copy is used when you DCPromo a member server to become a domain controller.

The ntds.dit is a transactional database file that uses Microsofts Extensible Storage Engine (ESE), also called Jet, technology as the basis for the database.
The ntds.dit file is actually composed of two main tables that are used by the directory to store AD object data and four other system-related tables.

The Directory Data Store (NTDS.DIT Data Table)

The first table, called the data table, is responsible for keeping all objects and their attributes for a given forest, as well as any indices that you define on a given attribute.
All of the attributes available in the AD schema are stored as columns in the data table (all 863 of them). All objects that you create within the AD are stored as rows. When you index an attribute for faster searching, that index is stored as part of the data table as well. A base AD ntds.dit file, on the first domain controller in your forest, will have a data table that consists solely of columns for the default attributes and rows for each of the classSchema and classAttribute objects that define the AD schema. All three NCs (domain, schema, and configuration) as well as the GC partial replicas of all forest domains are kept in the ntds.dit data table on each DC in the forest (assuming that domain controller is a GC server as well).

The Directory Data Store (NTDS.DIT Link Table)

The second table is called the link table, and it stores information that maintains logical links between attributes on objects. The link table tracks when you reference one AD object from another. For example, an AD distribution list (DL) can contain user objects as members. Additionally, the member objects themselves contain an attribute that lists all DLs (and groups) that the object is a member of. Each relationship between the members and members_of attributes for DLs and users, is stored in the link table. The link table guarantees that when one link changes, the other is updated. For example, when a user is removed from membership on a dlist, the associated user attribute no longer lists the user as being a member of the dlist. The relationship between these two linked attributes is described as forward links (the members of the dlist) and back links (the user object with the memberOf attribute). The link table stores these forward-link and back-link pairs for each object in the AD that contains such a relationship.

The Directory Data Store ( Support Files)

Edb.chk This file is a checkpoint file that indicates which transactions from the log files have been written to the AD database. Edb.log This file is the current transaction log. This log file is a fixed-length file exactly 10 megabytes (MB) in size. Edbxxxxx.log These log files are previous log files; whenever the current log file is filled up, the current log file is renamed to the next previous log file and the new Edb.log file is created. The old log files are automatically deleted as the changes in the log files are made to the AD database. Each of these log files are 10 MB in size. Edbtemp.log This log file is a temporary log that is used as the current log file (Edb.log) fills up. A new file named Edbtemp.log is created to store any transactions, and the Edb.log is renamed to the next previous log file. Then the Edbtemp.log file is renamed to Edb.log. Res1.log and Res2.log These files are reserved log files that are used only when the hard disk that contains the log files runs out of space. If the current log file fills up and the server cannot create a new log file because there is now hard disk space left, the server will flush any AD transactions currently in memory to the two reserved log files and then shut down AD. Each of these log files are 10 MB in size.

The Directory Data Store (Transaction)

Every single modification to the AD database is called a transaction. For example, when a user is moved from one OU to another, the user must be created in the destination OU and then must be deleted from source OU. Both these steps comprise a single transaction. Transactions should complete in entirety. If either fails, the transaction is incomplete & rolled back, thus maintaining consistency. How change is processed ?
Transaction log file is a text file, & hence the change is made first to the transaction log file. Text file is much quicker to process compared to the database file, which improves the performance of the domain controller.

Once the transaction has been written to the transaction log, the domain controller loads the database page containing the user object into memory (if not already in memory). All changes to the AD database are made in the memory of the domain controller. The domain controller flushes database pages from memory only when available free memory becomes limited, low server-utilization periods or when the domain controller is being shut down and the checkpoint file is updated.

The checkpoint file is a pointer that indicates which transactions in the transaction logs have been written to the AD database.

Domain Controllers
By definition, any computer running Windows Server 2003 that maintains c copy of the AD database is a domain controller (DC).

Global Catalog Servers

A global catalog server is used to hold the global catalog (GC). The GC is a partial, read-only copy of all the domain naming contexts (NCs) in a forest. The GC contains a base set of attributes for every object in the forest (in every domain NC), but it is not a complete set. The GC data is derived from all domain partitions in the forest. The GC data is replicated to very GC using normal AD replication process. A GC server is use to search AD database, because the GC contains a complete list of every object in the forest (though not every attribute of each object), the GC server can respond to the query using an attribute that has been replicated to the GC without needing to refer to another DC. The GC server process LDAP query using port 3268, the default GC port. A GC server is also used to process user logons. Every time a user

Use of Global Catalog Servers

A GC server is use to search AD database, because the GC contains a complete list of every object in the forest (though not every attribute of each object), the GC server can respond to the query using an attribute that has been replicated to the GC without needing to refer to another DC. The GC server process LDAP query using port 3268, the default GC port. A GC server is also used to process user logons. Every time a user logs on to a DC, a GC is contacted, because non-GC DCs do not contain any information about universal group membership. Since universal group membership is forest wide, group membership can only be resolved by a DC that has forest-wide directory information the GC.

Operations Masters Flexible Single-Master Operations (FSMO) AD is designed as a multimaster replication system and requires that all DCs have write permissions for the AD database. But certain directory operations should be controlled only by single authoritative server. DCs that perform specific roles are known as operations masters, and each has a flexible single-master operations (FSMO) role. The five operation masters roles in AD are: Schema Master Domain Naming Master RID Master PDC Emulator Infrastructure Master The first two roles are per-forest roles. The other three roles are per-domain roles. The first DC in the forest will possess all five operation master roles. As you add domains to the forest, the first DC in each new domain will also acquire these last three operation master roles.

Schema Master The schema master is the only DC that has Write permissions to the directory schema and changes made to the schema, are replicated to all other DC in the forest. The schema master is identified by the value of the fSMORoleOwner attribute on the schema container. On the non-availability of the Schema Master, schema updates will fail. Domain Naming Master The domain naming master is the domain controller on which new domains can be added to a forest or from which existing domains can be removed. Domains are added to a forest in one of two ways, both requiring remote procedure call (RPC) connection to the domain naming master role holder.
First method is by running Dcpromo.exe at the command line. Second method is by precreating using Ntdsutil, which creates a cross-reference object in the partitions container of the configuration directory partition, which is then replicated to every DC in the forest. Then, Dcpromo.exe can be run to create a new domain without having to contact the domain naming master.

On the non-availability of the Domain Naming Master, domain creation and deletion will fail.

RID Master It is used to manage the RID pool (block of relative identifiers), to create new security principals throughout the domain, such as users, groups and computers. It fulfills the request of issuing new RID pool when the number of available RIDs in the RID pool runs low on any DC in the domain and also ensures that no RID is allocated more than once, thus guarantying the unique security identity of every account in the domain. On the non-availability of the RID Master and the exhaustion of the RID pool on a DC in the domain, the creation of security principals will fail. PDC Emulator It is required for Windows 2003 to coexist with pre-Windows 2003 DCs. It acts as the primary domain controller (PDC) for all the down-level (Windows NT 3.51/4) backup domain controllers (BDCs). In a mixed mode, it is required for processing password changes, replicating domain changes to BDCs, and running the domain master browser service. In a native mode, it is required to maintain password updates. On the non-availability of the PDC Emulator, all the events mentioned above, both in mixed and native mode, will fail.

Infrastructure Master
It is responsible for updating the cross-domain group-to-user references. It ensures that changes made to user account names (changes to the common name attribute, cn) are reflected in the group membership information for groups located n the different domain. On the non-availability of the Infrastructure Master, the cross-domain group-to-user references will be out of date.

Schema
The kinds of things that can be contained within a directory servicethat is, the objects and the properties associated with those objectsare defined in the directory schema. AD uses an object-oriented approach to defining directory objects. That is, there is a hierarchy of classes, which define the kinds of objects that can be created within the directory. Each class has a set of attributes that define the properties associated with that class. For example, AD has a user class that has attributes such as firstName, Address, and so on. Interestingly, the AD schema itself is stored in the directory as objects. That is, AD stores AD classes as objects of the class classSchema, and stores attributes as objects of class attributeSchema. The schema, then, is just a number of instances of the classes classSchema and attributeSchema, with properties that describe the relationship between all classes in the AD schema

 Figure 1.1: Viewing the AD schema using the Active Directory Schema MMC snap-in.

Classes The default AD schema, when you load Win2003 out of the box, contains 142 classes and 863 attributes. There are actually three different categories of classes within the AD: StructuralA structural class is one that can be instantiated into a directory object. All structural classes in the AD inherit from abstract or auxiliary classes. AuxiliaryAuxiliary classes are used to extend the properties of a class that inherits from it. However, you cant instantiate a directory object directly from an auxiliary class, only from a structural class that has inherited properties from the auxiliary class. There are actually two types of auxiliary classes. System auxiliary classes are defined by the AD and therefore cant be removed. With the second type, you as administrator of the AD can define auxiliary classes by modifying the schema AbstractAbstract classes are meant to be parent classes of structural classes, but you cant instantiate a directory object of an abstract class.

Figure 1.2 illustrates the basic relationship between these three types of classes and a typica

Abstract Auxiliary

Structural

Figure 1.3 shows this relationship for the user class, viewed using the MMC Active Directory Schema s

Attributes Attributes are defined in the schema as objects of type attributeSchema. Every available attribute is represented in the base AD schema.

Attribute objects have a few interesting attributes themselves, namely syntax and whether theyre indexed. Syntax indicates the type of data that the particular attribute can store.
For example, the surname (last name) attribute takes syntax of Unicode string, indicating that the data in this attribute must be a string. However, an attribute such as userPassword, as you can imagine, needs to store information in a different form and thus has a syntax of Octet string, indicating that the attribute can store binary data.

 Figure 1.4: Viewing the syntax of the userPassword attribute.

 Figure 1.5: Choosing the option from the Active Directory Schema snap-in to replicate an attribute to the GC.

Attributes come in two flavorsmandatory and optional. Mandatory and optional attributes for a given class are defined in the schema for class objects using the following four attributes: systemMayContain, mayContain, systemMustContain, and mustContain. The two mayContain attributes specify the optional attributes that the defined class may contain. The two mustContain attributes specify the mandatory attributes for that class. Attributes prefaced by the word system indicate that these are defined by Microsoft in the base AD schema and cant be modified. When an attribute is mandatory for a given class, any object created from that class must contain a value in that mandatory attribute at creation time. For example, the user class has eight mandatory attributes that must be filled in when a new user object is created.

Figure 1.6 shows these mandatory attributes for the user class from the Active Directory Schema sna

Extending Schema One of the biggest advantages of the Win2003 AD over the NT 4.0 SAM is that you can extend the AD schema as your organizations needs dictate. You can in any case, add new attributes and classes to the base AD schema if application or infrastructure needs arise. The following list spells out the restrictions in the current version of the product: You cant add or remove any mandatory attributes from an existing class. You cant add a new mandatory attribute to an existing class by virtue of adding an auxiliary class to an existing class. For example, if I tried to have the organizationalPerson class inherit a mandatory attribute from an auxiliary class that I created, this inheritance wouldnt be allowed. After you add a new class or attribute, you cant delete it from the AD schema. You can only mark it defunct, which prevents any more instances of objects or attributes of that class from being created, but doesnt remove existing objects. Only Category 2 classes and attributes (those that you create yourself) can be declared defunct.

Category 1classes and attributes are considered system critical and cant be marked defunct.
If you mark an attribute defunct, any classes that contain that attribute (that is, have mayContain or mustContain values that include the defunct attribute) must also be declared defunct. The reason is that some of those classes might have the defunct attribute declared mandatory, and that would prevent objects of that class from being created. You cant rename a Category 1 class or attribute. You cant change the following attributes of a Category 1 attribute: rangeUpper, rangeLower, or attributeSecurityGUID. You cant change the defaultObjectCategory attribute for a Category 1 class, nor can you change the objectCategory attribute for an AD object created from a Category 1 class. You cant change the lDAPDisplayName of a Category 1 class or attribute

AD database contains the following structural objects: Partitions Domains Domain trees Forests Sites

Organizational units

Partitions or Naming Contexts (NCs) The directory database of every DC in a forest has at least three different partitions of data. These directory partitions are also known as naming contexts. Each naming context (NC) is responsible for storing and replicating certain kinds of data.

The 3 NCs are

Domain It contains all of the domain information required to authenticate, including information about users, groups and computers. This data is replicated to all the DCs in a domain. Schema It contains the schema, which is a set of rules detailing what types of objects can be created in AD as well as rules about each type of object. This data is replicated to all the DCs in the forest. Configuration It contains all the data related to Display Specifiers, Extended Rights, Lost and Found Config, Partitions, Physical Locations, Services, Sites, Well-Known Security Principals. This data is replicated to all DCs in the forest. Global Catalog Partition It is a read-only partition on all GC servers, and it is built from the contents of the domain databases. This data is replicated to all the GCs.

 Figure 1.13: Viewing the three naming contexts using ADSI Edit.

Domains
It is an administrative boundary, and it also defines the boundary of certain security policies. Each domain will have at least one DC. The first domain in the enterprise is know as the forest root domain commonly referred to as either the root domain or the forest domain and it is the starting point for an AD namespace. The first domain can either be a dedicated or a non-dedicated root domain. A dedicated root, also know as empty root, is used as an empty placeholder to start AD. It will not contain live user or group accounts, and it will not be used to assign access to resources.

A non-dedicated root, is used to hold the live user or group accounts and to assign access to resources.
All other domains exist as peers or as child domains to the root domain. Child domains share the same AD namespace as the parent domain (the root domain).

 Domain Trees A domain tree results when an organization creates a domain subsequent to the forest root domain but does not want to use an existing namespace. A domain tree contains at least one domain. Using multiple trees rather than child domains does have an impact on the DNS configuration. Domains Domain Trees

Peers
xyz.com abc.com xyz.com a.xyz.com b.xyz.com lmn.com a.abc.com b.abc.com abc.com

Parent - Child

forest root domain

FOREST

Forests It is the ultimate boundary for the enterprise. It is the outermost replication and security boundary for the organization. An AD forest can be defined by what is shared by all DCs in the forest. They are: A common schema All DCs in the forest will have the same schema. A common configuration directory partition All DCs in the forest have the same configuration container, which is useful for AD operations like replication within forest. A common GC The GC contains information about all of the objects in the entire forest. This make searching for any object in the forest efficient and enables users to log on in any domain in the forest using their UPN. A common set of forest-wide administrators Two security groups, the Schema Admins group that has right to modify schema and the Enterprise Admins group that has the right to perform forest-level actions such as adding or removing domains from the forest. A shared trust configuration All the domains in the forest are automatically configured to trust all the other domains in the forest with transitivity.

Trusts
A trust is an authentication connection between two domains by which security principals can be authorized to access resources on the other domain. Following are the three types of trust relationships:

Transitive trusts
One-way trusts Realm trusts Realm Trust

Transitive Two-way Trusts

Transitive Two-way Trusts

Non-Transitive One-way Trust

Transitive Trusts All domains in a tree maintain transitive, two-way trust relationship with every other domain in that tree. Within a forest, the trusts are setup as either parent-child trusts or as tree root trusts. All of the trusts between domains in a forest are transitive. One-Way Trusts One-way trusts can be created between domains in the forest. One-way trusts are called shortcut trusts. Realm Trusts A realm trust is configured between a Windows Server 2003 domain or forest and a non-Windows implementation of a Kerberos v5 realm. Realm trusts can be either one-ways or two-way, and they can also be configured to be transitive or non-transitive.

Sites
A site is defined as an area of the network where all DCs are connected by a fast, inexpensive, and reliable network connection. Site contains one or more IP subnets connected on a LAN or very high speed WAN and connected to the rest of the network with slower WAN connections. It is created to manage network traffic that must use slow network connection for: Replication Replication traffic can be controlled by schedules. Authentication Restricting client logon traffic within a site.

Site-aware network services Limiting client connections to site-aware applications and services on the site.
Every computer on a Windows Server 2003 network will be assigned to a site. Client computers determine their sites the first time they start up and log on to the domain and will cache that information for the next logon. If a DC or a client computer has an IP address that is not linked to a specific site, that computer will be placed in the Default-First-Site-Name site.

Organizational Units (OU) OUs are container objects that can contain several types of directory service objects: Computers Contacts Groups Printers Users Shared folders Organizational units OUs are used to create a hierarchical structure within a domain. OUs are used to group objects together for administrative purposes. There are two ways that OUs can be used as administrative units: Using OUs to Delegate Administrative Rights Using OUs to Administer Groups of Objects. OUs are not security principals and hence cannot be used to assign permissions to a resource.

Windows NT Replication Model

Single-Master Replication Model PDC is the only DC that can accept changes to the domain information. The change is replicated to all the BDCs. Not scalable due to the very nature of Single-Master. PDC can be a bottleneck in case of thousands of changes in a small interval. PDC acts as a single point of failure. On non-availability of the PDC, the BDC needs to be promoted to PDC for the changes to be made to the domain information.

Windows 2003 Replication Model

Multi-Master Replication Model All the DCs can accept changes to the domain information. The change is replicated to all the DCs. Scalable due to the very nature of Multi-Master. No single DC can be a bottleneck in case of thousands of changes in a small interval. (provided multiple DCs exist for a domain) No single point of failure (provided multiple DCs exist for a domain). Replication model is loosely consistent, but with convergence. Replication model uses a store and forward replication process.

Intrasite Replication
Fast RPC is used as a transport protocol. Replication occurs almost immediately after a change has been made to the AD.

Change notification is of 15 seconds.

After change notification, the destination DC will pull update from the source DC. The DC will complete replication with one partner, wait 3 seconds, and the initiate replication with another partner.

Replication traffic is not compressed.

The DC will replicate the information to all direct replication partners.

Intersite Replication
Slow RPC is used as a default transport protocol.
Replication is initiated by the bridgehead server according to a schedule rather than when changes are made. Site link must be configured for intersite replication.

Replication traffic is compressed down to 10% to 15% if the traffic is more than 32 KB in size.
Bridgehead servers in each site compress traffic. Change notifications are not used to alert a DC in another site.

Replication can use IP (Slow RPC) or SMTP transport.

Replication traffic is sent through bridgehead servers (per directory partition) rather than to multiple replication partners. Almost every component of the intersite replication can be changed.

Replication Latency

The way replication works, it can take some time for a change made on one DC to be replicated to all the other DCs, and this time lag is called replication latency.
The replication latency within a site is about 15 seconds times the number of hops the change has to take before reaching all DCs. The replication latency between sites is calculated the following way: The replication latency within the source site. The site link schedule and the replication interval. The replication latency within the destination site.

 Urgent Replication It is in which a DC forwards the changes immediately to its replication partners. Any DC receiving an urgent update will also immediately forward the change. Thus, all DCs will be updated within seconds for urgent replication. The following types of changes trigger an urgent replication: Modifying the account lockout policy for the domain. Modifying the domain password policies. Moving the relative identifies (RID) master to a new DC. Changing a LSA secret, such as when the DC machine password is modified. By default, urgent updates apply only to intrasite replication. User password change is immediately replicated directly to the PDC Emulator. This replication crosses site boundaries and does not make use of the bridgehead servers.

Knowledge Consistency Checker (KCC)

KCC is runs on every DC and is responsible for creating the replication topology within a site and between sites. As DCs are added or removed, KCC uses the information about servers, sites, site links, and the schedules to create the optimal. By default, KCC on every DC recalculates the replication topology every 15 mins.

Connection Objects
They are direct logical connections between DCs that are used to replicate directory information. They are always created as one-way pull connections between two DCs. In most cases, KCC will build two one-way connections between DCs so that information can be replicated either way.

Intrasite Replication Topology

AD uses multiple-source rather than single-source (Spanning Tree) algorithm. This topology will form replication ring. KCC creates a replication ring in which every DC is configured with multiple incoming replication connections creating redundant ring configuration.

The topology will have each DC in a site no more than three hops away from any other DC. As the number of DCs increase beyond seven, extra connection objects are created to decrease the potential number of hops to three or fewer.
Replication rings are based on directory partitions. KCC will not create additional connection objects for each replication ring, but reuses connection objects for as many replication rings. Within a site, KCC on each DC is responsible for creating the connection objects that it needs to ensure that it has the required replication redundancy for all of its partitions, and it then replicates the information about the connection objects to the other DCs, eventually creating an optimal replication configuration.

Update Types
The first type of update is an originating update, which is performed when an object is added, modified, or deleted on a DC. The second type of update is a replicated update, which is performed when a change that was made on one DC is replicated to another DC.

Originating updates occur in AD under any of the following circumstances:

A new object is added to AD. An existing object is deleted from AD. The attributes for an existing object are modified. This modification can include adding a new value to an attribute, deleting a value for an attribute, or modifying an existing value. An object in AD is moved to a new parent container. If the parent container is renamed, each object in the container is also moved to the renamed container.

All originating updates to AD are atomic operations, which means that when an update is committed to AD, either the entire transaction is committed and permanent, or no part of the update will be committed.

Replicating Changes To optimize AD replication, only those changes that need to be replicated between two DCs should be sent. To accomplish the above, AD uses a combination of: Update Sequence Numbers (USNs) High-Watermark Values Up-to-date Vectors and Propagation Dampening.

Change Stamps

Update Sequence Number (USN) A USN is a 64-bit number maintained by each AD DC to track updates.

When the server writes to any attribute, or property, on an AD object (including the originating write or a replicated write), the USN is advanced and stored with the updated property and with a property that is specific to the DC.
This operation is performed atomicallythat is, the incrementing and storage of the USN and the write of the property value succeed or fail as a single unit. High-Watermark Value It is just the latest uSNChanged value that the DC has received from a specific replication partner. The destination DC retains this uSNChanged as the high-watermark value, and sends this to the source DC when requesting updates. A separate high-watermark value is maintained for each directory partition on the DC and for each direct replication partner.

Up-to-date Vector and Propagation Dampening The up-to-date vector is a list of serverUSN pairs held by each server. The up-to-date vector at each server indicates the highest USN of originating writes received from the server in the serverUSN pair. An up-to-date vector for a server in a given site lists all the other servers in that site The process of limiting the updated sent during replication by using the up-to-date vector is called propagation dampening. Change Stamps and Conflict Resolution The last property that is used to manage the replication between DCs is a change stamp and it consists of : Version number When an object is created, the version number is initialized to 1. Only Originating writes advance the property version number. Last write time It is the last write occurred to the property / attribute. Originating server This is the GUID for the server where the last originating update to the attribute was applied. If a conflict arises, the decision as to which is the final change is made in the following order: Version number, Last write time and Originating server.

Time Sync Overview The Win2003 Time Service is implemented in w32time.dll, and is hosted by the generic service host (svchost.exe), running as a background service on all Win2003 computers in a domain. The Time Service is designed to prevent drastic changes to a computers system clock by using progressive time adjustment when possible: If the local time is slow, the service automatically adjusts it. If the local time is more than 3 minutes fast, the service automatically adjusts it. If the local time is less than 3 minutes fast, the service slows the local clock until the time is synchronized. Where does the Time Service look for its synchronization? Client computers and member servers receive their time information from the domain controller that authenticated them. Domain controllers synchronize their clocks with the domains PDC emulator. PDC emulators in child domains synchronize with a domain controller in the parent domain, using the domain and forest hierarchy. By default, the PDC emulator in a forest root domain does not perform time synchronization; it uses whatever its system clock is set to. The Time Service attempts to resynchronize every 45 minutes, ensuring that the local time is the same as the official domain time. After three synchronization passes complete with no changes to the local time, the Time Service shifts into a standby mode, synchronizing every 8 hours.

Time Sync tools Win2003 includes several utilities that let you manage time synchronization, including NET TIME, a command-line utility used to check time and force synchronization; and W32TM, an comprehensive time troubleshooting tool. NET TIME NET TIME is implemented as part of the main NET utility, which youre probably familiar with (NET USE, NET SHARE, and other commands). NET TIME is used specifically to configure the Time Service and to force time synchronization. W32TM W32TM uses the current Time Service synchronization, so you can use it to determine how the Time Service will behave. Its especially useful for verifying that the Time Services external time sources (if any are configured) are reachable and for providing accurate information.

NET TIME supports the following functions: NET TIME displays the local time. NET TIME computer name displays the time on the specified computer. NET TIME /DOMAIN:domain name displays the time on a domain controller in the specified domain. NET TIME /DOMAIN /SET synchronizes the local time with the domain time. NET TIME /querysntp displays the currently configured time server that the local computer will synchronize with. NET TIME /setsntp: clears the external time synchronization server. NET TIME /setsntp:server name configures a Simple Network Time Protocol (SNTP) server for use as a time source.

W32TM supports the following functions: W32TM TZ displays the local time zone information. W32TM S computername forces the designated computer (or the local computer, if computername is not specified) to synchronize its time once. W32TM SOURCE displays the time source that the local computer will use on its next synchronization. W32TM ONCE forces a single time synchronization. Any of these commands can be modified with the following parameters: -V display verbose output with additional details. -TEST prevents the local time from actually being modified. Use with V to see what W32TM would have done. -P port specifies an alternative port number for the time server. Stop the Time Service before using W32TM. W32TM uses the same ports as the Time Service, and in order for the utility to function properly, you must stop the Time Service. Be sure to restart the Time Service once youve finished using W32TM.

System Monitor includes several counters that can help you determine whether a domain controller is overworked or nearing its limit: The % Processor Time counter, part of the Processor performance object, shows how hard each of the computers processors are working. On a multiprocessor computer, select the _Total instance to view an average of all installed processors. % Processor Time is affected by all tasks running on the domain controller and should not exceed a sustained average of 80 percent, although it may sometimes peak to 100percent Kerberos authentications per second, part of the NTDS performance object, shows how many logons the domain controller is processing. The maximum value for this number depends on the domain controllers hardware. Use this counter along with other counters to determine if logon traffic alone is causing a performance problem. For example, if both this counter and % Processor Utilization are high, its an indication that another domain controller is needed to help handle logon traffic.

 NTLM Authentications per second, also part of the NTDS performance object, shows how many legacy logons (Windows 9x and Windows NT clients) the domain controller is handling. Add the value of this counter to the Kerberos authentications per second counter for an accurate picture of logon processing workload. LDAP Bind Time, part of the NTDS performance object, shows how long the domain controller took to bind the last LDAP request. This counter should be as low as possible. If it shows any significant activity, this activity usually indicates a hardware bottlenecktime for an additional domain controller to help out.

Cache Page Fault Stalls per second, part of the Database performance object, should always be zero. If it is consistently higher than zero at any value, its an indication that the domain controller needs more memory, or that an additional domain controller is needed to help pick up the load.

Installing the Database Object

The Database performance object contains a number of other counters that help you determine what kind of load ADs database engine (called the Extensible Storage EngineESE) is under.
To install the database object 1. Copy Esentprf.dll from %SystemRoot%\System32\esentprf.dll to a different directory. For example, create a directory named C:\Performance, then copy the DLL and paste it in the new directory. 2. Run Regedit.exe, then create the following registry subkeys: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\Performa nce

3. Under the new Performance subkey, create the following String Value entries (all are type REG_SZ): Create an entry named Close and set its value to ClosePerformanceData Create an entry named Collect and set its value to CollectPerformanceData Create an entry named Library and set its value to C:\Performance\esentprf.dll

Create an entry named Open and set its value to OpenPerformanceData

4. Open a command-line window and change to the Windows System32 folder. 5. Run Lodctr.exe Esentperf.ini The Database object should now be visible in System Monitor.

DCDIAG.EXE is one of the useful unsupported tools included in the Microsoft Windows 2003 (Win2003) Server resource kit. Its also included in the subset of the resource kit on the Win2003 Server CD-ROM, under \SUPPORT\TOOLS. DCDIAG is basically an all-in-one diagnostic tool for Active Directory (AD) domains. The tool is capable of running a number of useful tests and can help you track down domain problems that would otherwise be almost impossible to figure out. Anytime youre having any kind of trouble with your domainusers cant log on, domain controllers are acting funnyrun DCDIAG first and see what it comes up with. Dcdiag /s:dc01 /e /f:logfile.txt /c The /s parameter specifies the domain controller to connect to.

The /e parameter specifies that all domain controllers in the enterprise be tested. You can also specify /a to test all domain controllers in the current site.
The /f parameter specifies a log file, to which all DCDIAG output is written. The /c parameter runs all tests that DCDIAG can perform. Alternatively, you can specify /test: and list a single test name.

The following list includes the most commonly used tests and their functions: ConnectivityThis test, which is always performed when you run DCDIAG, checks to see that all domain controllers are listed in DNS, they can be reached using the PING command, and they are accepting Lightweight Directory Access Protocol (LDAP) and remote procedure call (RPC) connections. CutoffServersThis test checks the AD replication topology and ensures that all servers will receive replication. If a servers designated replication partners are unreachable, that server is considered cut off, and this test will reveal it. Cut off servers can be a problem because they continue to act as normal domain controllers, but contain outdated copies of the AD database. You can correct cut off servers by checking their replication partners for problems, and examining your site connectivity to make sure servers can reach one another. IntersiteThis test checks for any problems or failures that might delay or prevent intersite replication. For example, if a bridgehead server is unavailable, the site it is responsible for will not receive replication updates. The tests results give you good information that you can use to narrow down the problem.

LocaterGetDCThis test checks to see that each domain controller is advertising itself as offering the services it is capable of. At a minimum, each domain controller should advertise itself as able to accept logon traffic. Any advertising failures are noted by the test, and a reboot of the domain controller in question will often solve the problem. If it doesnt, check your DNS infrastructure, which is how domain controllers advertise their services to the network. NetLogonsThis test verifies that AD permissions are correct to allow replication to work. If this test fails, itll point you to the specific AD objects that need their permissions corrected, and you can take the necessary corrective actions. ReplicationsThis test checks to see that replication is occurring in a timely fashion between domain controllers. If this test fails, it will tell you which domain controllers arent participating correctly in the replication process. Often, domain controllers that are overloaded and unable to process replication traffic quickly enough will show up on this test. Whenever a domain controller shows up on this test, you should check its Event Viewer to see whats causing the problem.

RidManagerThe relative ID (RID) master is an important role held by one domain controller, and this test verifies that the RID master is available, responding to requests, and contains the correct information. If it doesnt, consider transferring the RID master role to a more powerful domain controller

RolesHeldThis test verifies that each of the Flexible Single-Master Operation (FSMO) roles, including the RID master, is accessible, can be located through AD, and is responding to requests. If a FSMO shows up as not known or not reachable, consider transferring the role to a domain controller that is operating correctly.
ServicesThis test ensures that all the services necessary to the proper functioning of a domain controller are up and running. If any service is shown as failing, you should immediately check the domain controller indicated to determine the nature of the problem. As with many problems, a reboot is often the cure, but be sure to carefully examine the Event Viewer to see why the service stopped. Also, keep an eye on that domain controller to make sure that the service doesnt fail a second time. TopologyThis test ensures that the AD replication topology is complete, and that all serves are included in the topology.

REPADMIN REPADMIN is designed to help you troubleshoot problems with the replication that occurs between domain controllers. REPADMIN supports several commands, each with its own syntax. REPADMIN also supports two universal parameters: /u:username lets you specify a user name. If you omit this parameter, your current user name is used instead. To specify a domain user account, use the syntax domain\username. /pw:password lets you specify the password to go with the user name specified with the /u parameter. The following section provide information about the most commonly used REPADMIN commands. Checking Replication You can check a servers replication status with the following command: repadmin /showreps servername This command displays the replication neighbors of the designated server. AD restricts replication to no more than three connections per domain controller, both inbound and outbound. This command will display any inbound replication partners, as well as any outbound changenotification requests to other domain controllers.

Forcing Replication with a Specific Partner To force replication to occur with a specific replication partner, use the following command: repadmin /sync namingcontext servername objectguid This command forces the specified server to synchronize the designated naming context with the destination server identified by objectguid. For example repadmin /sync dc=mycompany,dc=com server1 e55c6c85-85bb-459a-a0d2020a44c3afe7 You can use repadmin /showreps to determine the GUID of other servers replicating with a specific server. Force Replication with all Replication Partners To force a server to synchronize with all its replication partners, use the following command: repadmin /syncall servername namingcontext This command forces the designated server to synchronize the specified naming context with all of its replication partners. A naming context must be provided, such as dc=mycompany,dc=com for the domain mycompany.com. Be sure to include the naming context in quotation marks.

Display Replication Data

When you add or modify objects in AD, they must replicate. That replication is governed by the version numbers, called update sequence numbers (USNs), that AD assigns to each of an objects attributes.
If replication isnt working correctly, you can check all of an objects attributes and their version numbers using the following command: repadmin /showmeta "cn=user,ou=ou,dc=mycompany,dc=com" server1 The /showmeta command requires a complete naming context of the object you want to check, as shown, and the name of the domain controller from which to display information.

Check to See Whether an Object is Up-to-Date

You might need to check to see whether a server has the latest version of a particular object.
Youll need to know the GUID of the server on which the object is most up-to-date as well as the complete naming context of the object. With this information, use the following command: repadmin /propcheck dc=mycompany,dc=com GUID USN servername Provide the GUID of the original server, the USN number to check, and the name of the server you want to check. REPADMIN will determine whether the object referenced is up-to-date on the server or not.

Transferring FSMOs You have complete control over which domain controllers host the various FSMO roles. You use one of three Microsoft Management Console (MMC) snap-ins to transfer the roles: Active Directory Users and Computers allows you to transfer the RID master, PDC emulator, or infrastructure master FSMO roles. Active Directory Schema you to transfer the schema master FSMO role. Active Directory Domains and Trusts allows you to transfer the domain-naming master FSMO role. Transferring the RID Master, PDC Emulator, or Infrastructure Master Launch Active Directory Users and Computers, connect to the appropriate domain controller, then right-click Active Directory Users and Computers, and select Operations Masters from the pop-up window. Windows displays the Operations Master dialog box. On one of the three tabs, click Change to transfer that FSMO role to the domain controller you are currently connected to.

Transferring the Domain-Naming Master Launch Active Directory Domains and Trusts, connect to the appropriate domain controller, then right-click Active Directory Domains and Trusts, and select Operations Masters from the pop-up window. Windows displays the Change Operations Master dialog box Click Change to transfer that FSMO role to the domain controller youre currently connected to. Transferring the Schema Master Launch Active Directory Schema, connect to the appropriate domain controller, then right-click Active Directory Schema and select Operations Master from the pop-up window. Windows displays the Change Schema Master dialog box Click Change to transfer that FSMO role to the domain controller youre currently connected

What to Do When a FSMO Fails You have three basic options when you notice that a FSMO has failed on your network: Return the domain controller to active service. This option is the easiest choice if the domain controller hasnt suffered a hardware failure or complete operating system (OS) crash. Most of your network operations can survive a brief unavailability of any of the FSMOs. Temporarily return the domain controller to active service, and transfer the FSMOs to a more stable domain controller. This option is a good bet if you can boot the affected domain controller, but it wont stay running for very long.

Seize the FSMOs with another domain controller. This option is the most drastic approach and requires that you be very careful when bringing the original domain controller back on the network.

Seizing FSMOs If the domain controller hosting a FSMO fails, you can use another domain controller to seize thevFSMO role. Be aware that seizing the role may have a potentially adverse affect on your network if the original domain controller is brought back online: If you seize the schema master, domain-naming master, or RID master, you must never bring the original domain controller back online. If you need to recover files from that server, keep it disconnected from your network. If you seize the PDC emulator or infrastructure master roles, you can safely return the original domain controller to your network. It will automatically detect the role change, and no conflict will be created.

If you do somehow wind up with two schema masters, domain-naming masters, or RID masters, remove one of them as quickly as possible. If you dont, the two FSMOs can corrupt AD, requiring you to restore from a backup tape.

To seize any of the FSMOs, youll need to use the ntdsutil utility, which you run from a command line. Follow these steps: 1. From a command line, run ntdsutil 2. At the main ntdsutil prompt, type roles 3. At the fsmo maintenance prompt, type connections 4. At the server connections prompt, type connect to server followed by the fully qualified name of the domain controller you want to move the FMSO role to. 5. At the server connections prompt, type quit 6. At the fsmo maintenance prompt, type the appropriate command to seize a FSMO role. The available commands are:
seize pdc seize infrastructure master seize rid master seize domain naming master seize schema master

7. At the fsmo maintenance prompt, type quit 8. At the ntdsutil prompt, type quit

NTDSUTIL NTDSUTIL is a general-purpose troubleshooting and maintenance utility for Active Directory (AD). Its installed on every domain controller, and it lets you perform a variety ofcuseful tasks. NTDSUTIL can be used interactively from a command line, or it can be used in batch files to automate specific processes.

NTDSUTIL supports ten primary commands, known as menus: Semantic database analysis, which provides miscellaneous database analysis tools. Security account management, which provides security ID (SID) management tools. Roles, which let you manage the FSMO roles within a domain. Popups, which provide ways to automate NTDSUTIL. Metadata cleanup, which lets you perform cleanup tasks within AD. LDAP policies, which let you manage the LDAP policies in AD. IP deny list, which lets you manage the list of IP addresses from which the domain controller will accept LDAP information. Files, which let you manage ADs database files. Domain management, which provides various domain commands. Authoritative restore, which contains commands that let you perform an authoritative restore of AD. Quit, which quits the current menu

Files This menu lets you work with the AD database files. Needless to say, you should make sure you have a backup before performing any of these commands. Compact to path compacts the AD database files to the path you specify, freeing up disk space. This action is also referred to as an offline defragmentation. You must manually copy the compacted files to replace the originals. Info reports disk size and internal free space in the database files. Integrity performs a basic integrity check of the database files, alerting you to any internal errors within the files. Move DB to path moves the AD databases to the path you specify. This command is useful for moving the files to a new hard drive when you upgrade a server. Move Logs to path moves the AD log files to the path you specify. Keeping the database and log files on separate physical disks will improve system performance and reliability. Repair performs a soft repair of the database files, correcting certain types of internal errors.

IP Deny List ADs IP Deny List prevents AD from accepting LDAP connections from any IP address or address range on the list. This command lets you prevent specific servers from attempting to modify or query AD. Add ipaddress subnetmask adds an entire range of IP addresses to the deny list. Add ipaddress NODE adds a specific, single IP address to the deny list. Show displays a numbered list of deny list entries. Delete # deletes the specified deny list entry. Commit saves the updated deny list to AD. Test ipaddress indicates whether the specified IP address would be allowed to connect, based upon the entries currently in the deny list. Metadata Cleanup Metadata Cleanup lets you remove information from AD. Remove selected domain removes the domain currently targeted by the Select Operation Target menu. Remove selected server removes the server currently targeted by the Select Operation Target menu. For example, if a particular server crashed and was never replaced, its machine account remains in AD. Using this command, you can delete that account.

Roles This menu lets you work with the FSMO roles within AD.

Abandon all roles instructs the domain controller to which you are connected to give up all FSMO roles that it holds. Only use this command if you know that the domain controller can contact other domain controllers that can pick up the FSMO roles. Otherwise, you risk having the roles abandoned and not adopted by other servers, which can impair ADs operations. Seize instructs the domain controller to which you are connected to forcibly take over a role. You must specify a role. The domain controller previously holding the role is not notified of the seizure.
Transfer instructs the domain controller to which you are connected to perform a normal transfer of a FSMO role. You must specify the role, and the domain controller previously holding the role is notified of the transfer and asked to voluntarily drop the role.

Connections The Connections submenu lets you have NTDSUTIL commands target a specific server, using credentials other than the ones youre currently logged on with. The Connections submenu is available under the following NTDSUTIL menus: Domain Management, IP Deny List, LDAP Policies, Metadata Cleanup, and Roles. Set creds domainname username password sets the credentials that NTDSUTIL will use for subsequent operations. Prior to using this command, NTDSUTIL will use the credentials that you are logged on with. Connect to domain domainname finds any domain controller for the domain specified, and connects to it using the current credentials. Connect to server servername connects to the domain controller specified by using the credentials currently in effect. Info displays the credentials that NTDSUTIL will use for the next operation, and the state of NTDSUTILs current connections to other servers. Clear creds clears any previously defined credentials and disconnects any existing connections. This command lets you specify new credentials and connections and ensure that all connections are using the desired credentials.

Select Operation Target Select Operation Target submenu is available for the Domain Management, Metadata Cleanup, and Roles menus. This submenu lets you select sites, domains, or other AD objects as the targets for specific operations within NTDSUTIL. The Select Operation Target submenu provides the following commands: List current selections lists the currently selected site, domain, and server. List domains lists all domains. All the domains listed might not exist if the last domain controller for that domain was removed without performing the demotion properly. List domains in site lists the domains that have domain controllers in the currently selected site. List servers for domain in site lists all the servers known for the currently selected site and domain. List servers in site lists all the domain controllers known to be in the currently selected site. List sites lists all the sites in the forest. Select domain # selects the domain specified. Select server # selects the server specified. Select site # selects the site specified.

Offline Defrag An offline defrag is the only way to ph ysically reduce the size of the AD database file,NTDS.DIT. To perform an offline defrag, youll need to take the domain controller offline 1. Restart the domain controller in Directory Services Restore mode. 2. Run NTDSUTIL. 3. Type the command COMPACT TO path where path is the full path name on the local computer on which you want the compacted NTDS.DIT to go. If the path includes spaces, you should enclose it in quotation marks. 4. Copy the compacted NTDS.DIT file to \WINNT\NTDS, overwriting the NTDS.DIT file thats already there. 5. Restart the domain controller normally (that is, not in Directory Services Restore mode).

Authoritative Restore This menu lets you mark restored AD data as authoritative, meaning that the data will overwrite whatever is on your other domain controllers. Authoritative Restore has two primary commands: Restore databases marks all AD databases as authoritative, with the exception of the schema. You cannot authoritatively restore the schema. Restore subtree NC marks the subtree specified as authoritative. That subtree will overwrite other domain controllers, while the other domain controllers will overwrite all other subtrees on the restored domain controller. NC is the naming context to mark as authoritative, such as OU=Marketing,DC=mycompany,DC=com.

Authoritative Restore An authoritative restore allows you to return your entire domains AD database to an earlier point in time, which you might need to do if someone accidentally deletes several AD objects that you cant easily re-create. An authoritative restore starts out just like a non-authoritative restore Start the domain controller in Directory Services Restore mode and perform the restore and then do the following to make it authoritative restore: 1. From a command line, run ntdsutil 2. At the ntdsutil prompt, type authoritative restore and restore database 3. Follow the prompts to confirm your choice. 4. At the ntdsutil prompt, type quit 5. Restart the server. Ntdsutil goes through the entire AD database that you restored and marks each object with a version number that is much higher than any version number already in the database. When the server restarts, normal AD replication kicks in. Because the server has a higher version number for each object than the other domain controllers on your network, it will be treated as the source for AD replication, and its version of the AD database will begin to overwrite the other domain controllers databases.

DNS
AD integrated DNS DNS is the primary name resolution service for Windows Server 2003, and a core component of Windows Server 2003 TCP/IP networking. DNS is used by Active Directory for domain controller location and DNS naming is leveraged by Active Directory for domain naming. Because Active Directory depends on DNS for domain controller location and DNS influences Active Directory domain naming, During or after the creation of the DNS zones used to support Active Directory domains, the zones are populated with DNS resource records that enable network hosts and services to locate Active Directory domain controllers.