Active Directory
Applies To: Windows Server 2008
Active Directory technologies define the data structure and services that provide organization, management, and security of accounts and resources in a Microsoft network.
Hierarchy of Managed Entities
.gif)
Managed Entities
| Name | Description |
|---|---|
Active Directory Domain Services (AD DS) defines the data structure and services that provide organization, management, and security of accounts and resources in a Microsoft network. |
|
An Active Directory forest contains all the domains, sites, and trusts that are part of Active Directory Domain Services (AD DS). The forest acts as a security boundary for an organization, and it defines the scope of authority for administration. By default, a forest contains a single domain, which is called the forest root domain. |
|
A domain is a distinct unit of administration and resource grouping in Active Directory Domain Services (AD DS). |
|
Domain controllers are servers that host Active Directory Domain Services (AD DS) resources. These servers host essential services in AD DS, including the following:
In addition, domain controllers host the SYSVOL share. Domain controllers must register Domain Controller Locator (DC Locator) records with Domain Name System (DNS) so that domain member computers can locate resources on the domain. |
|
The directory service is a database with multiple data partitions, as well as the processes to maintain, manage, and secure the database. Domain controllers host and replicate the directory service database inside the forest. The directory service also provides services for managing and authenticating resources in the forest. |
|
Lightweight Directory Access Protocol (LDAP) is the standard protocol that directory clients use to gain access to data that is held by directory servers. LDAP supports a relatively simple set of operations, such as bind, unbind, read, and modify. LDAP is the primary interface to Active Directory Domain Services (AD DS), and it is responsible for packaging and interpreting LDAP packets over the network. |
|
Active Directory data is replicated as a database that is separated into several partitions. These partitions represent the major object categories that organize, manage, and secure domain resources. Administrators and services can define custom data partitions. For example, Domain Name System (DNS) data partitions are created when DNS information is integrated with Active Directory Domain Services (AD DS). The partitions that are created by default include the following:
The database itself consists of the Ntds.dit file and its related logs, which are stored in the NTDS folder on each domain controller by default. The folder location where the database is stored can be changed. Another essential component of AD DS is the SYSVOL shared folder on each domain controller. The SYSVOL shared folder provides a location to which domain controllers replicate AD DS data to each other. |
|
Active Directory Domain Services (AD DS) data is logically partitioned so that all domain controllers in the forest do not store all objects in the directory. Active Directory objects are instances of schema-defined classes, which consist of named sets of attributes. When a change is made to an object in a directory partition, the value of the changed attribute or attributes must be updated on all domain controllers that store a replica of the same directory partition. Domain controllers communicate data updates automatically through Active Directory replication. Communication about updates is always specific to a single directory partition at a time. Different categories of data are stored in replicas of different directory partitions, as follows:
|
|
The Active Directory schema is the set of definitions that defines the kinds of objects, and the types of information about those objects, that can be stored in Active Directory Domain Services (AD DS). The definitions are themselves stored as objects so that AD DS can manage the schema objects with the same object management operations that are used for managing the rest of the objects in the directory. There are two types of definitions in the schema: attributes and classes. Attributes and classes are also referred to as schema objects or metadata. Attributes are defined separately from classes. Each attribute is defined only once and can be used in multiple classes. For example, the Description attribute is used in many classes, but it is defined once in the schema, which helps ensure consistency. Classes, also referred to as object classes, describe the possible directory objects that can be created. Each class is a collection of attributes. When you create an object, the attributes store the information that describes the object. The User class, for example, is composed of many attributes, including Network Address, Home Directory, and so on. Every object in AD DS is an instance of an object class. |
|
The schema is stored in its own partition (the schema directory partition). The schema directory partition is replicated among all the domain controllers in the forest, and any change that is made to the schema is replicated to every domain controller in the forest. Because the schema dictates how information is stored, and because any changes that are made to the schema affect every domain controller, changes to the schema should be made only when necessary — through a tightly controlled process — after testing has been performed to ensure that there will be no adverse effects on the rest of the forest. |
|
Active Directory Domain Services (AD DS) supports application directory partitions. An application directory partition can contain a hierarchy of any type of objects, except security principals. You can configure an application directory partition to replicate to any set of domain controllers in the forest. An application directory partition can replicate to domain controllers in different domains in the forest. Unlike a domain directory partition, an application directory partition is not required to replicate to all domain controllers in a domain. |
|
The Windows Time service (W32time) automatically synchronizes the local computer's time with other computers on the network. The Windows Time service architecture consists of the following components:
The Windows Time service internal time synchronization process involves the following steps:
If a computer has been designated as a time server, it can send the time on to any computer requesting time synchronization at any point in this process. |
|
A time source peer is a server from which time samples are acquired. The time source for this varies, depending on whether the computer is joined to a domain in Active Directory Domain Services (AD DS) (domain heirarchy peers) or to a workgroup (manually configured peers). |
|
The Clock Manager receives updates from a peer and uses them to skew local system time within compliance. |
|
A time source (also known as a time provider or an input provider) represents a source protocol for acquiring time samples. Windows includes a Network Time Protocol (NTP) time source with the Windows Time service. |
|
The Security Accounts Manager (SAM) is a database that stores user accounts and security descriptors for users on the local computer. |
|
Account management includes all aspects of creating, modifying, and deleting user accounts. This includes detection of duplicate accounts and security identifiers (SIDs). |
|
Database/configuration is a process that ensures that the security database is initialized, properly configured, and available for use by the system. |
|
The Security Accounts Manager (SAM) database changes state (active or inactive):
The database upgrade, domain controller installation, and domain controller removal processes are designed to track events that are related to SAM state changes. |
|
The relative ID (RID) manager is responsible for providing numbers that are used to create unique security identifiers (SIDs) for each account in a domain. |
|
You can use Local Security Authority (LSA) policy to manage trust relationships between domains. The LSA also provides a software interface for other software components when they query mappings of account names to security identifiers (SIDs) between the local domain and trusted domains. |
|
You can use Local Security Authority (LSA) policy to manage trust relationships between domains and forests. |
|
The NetLogon service verifies NTLM logon requests, and it registers, authenticates, and locates domain controllers. Also, to maintain compatibility with older operating systems, NetLogon manages replication of the user account database to back up domain controllers running Windows NT 4.0 and earlier. |
|
The global catalog is a distributed data repository that facilitates searches and logons in an Active Directory forest. The Active Directory replication system builds global catalog data automatically. One or more domain controllers in an Active Directory forest host the global catalog. The domain controllers that host the global catalog are called global catalog servers. Users and applications can use the global catalog to locate objects in any domain in the forest by searching for an attribute of the object. For example, an administrator can use the global catalog to search for a user's last name to locate that user's account in the forest. A user can also use the global catalog to search the forest for a list of printers that are organized by location. The global catalog facilitates logons by ensuring that membership in universal groups from all domains is represented in the user's access credentials (also known as the access token). |
|
Organizations that have applications that require a directory for storing application data can use Active Directory Lightweight Directory Services (AD LDS) as the data store. AD LDS runs as a service that is independent of a domain's directory service. AD LDS does not require deployment on an Active Directory domain controller. In addition, you can install multiple instances of AD LDS and run them concurrently on a single computer. Note: AD LDS was previously known as Active Directory Application Mode (ADAM). |
|
If there is a change to the configuration of an Active Directory Lightweight Directory Services (AD LDS) instance, the change must be registered with the instance's internal database as well as with the databases of any replication partners that are configured. Such updates are especially important when replication partners exist, because a local instance cannot receive any updates from its replication partners until the change is registered by the replication partners in their respective databases. The configuration changes that must be recorded and replicated include the following:
Note: AD LDS provides services by using the security credentials of a user account. A user account that a service uses is commonly known as a service account. |
|
When Active Directory Lightweight Directory Services (AD LDS) is running on a computer that is joined to a domain, the AD LDS instance creates a serviceConnectionPoint (SCP) object in the domain so that other computers in the domain can locate the AD LDS instance. |