Domains And Forests Technical Reference

Domains and Forests Technical Reference Updated: March 28, 2003

Domains and forests are logical representations of the directory hierarchy in the Microsoft Windows Server 2003 Active Directory directory service. Active Directory domains and forests allow administrators to organize elements of a network (such as users, computers, devices, resources, and application-specific data from Active Directory–enabled applications) into a non-physical hierarchical structure, known as the logical structure. You can use domains and forests to provide an information repository and services to make information available to users and applications. In this subject

• • •

What Are Domains and Forests? How Domains and Forests Work Domains and Forests Tools and Settings

What Are Domains and Forests? Updated: March 28, 2003

What Are Domains and Forests? In this section

• • • • •

The Logical Structure of Active Directory The Physical Structure of Active Directory What are Domains? What are Forests? Related Information

The Active Directory directory service is a distributed database that stores and manages information about network resources, as well as application-specific data from directory-enabled applications. Active Directory allows administrators to organize objects of a network (such as users, computers, and devices) into a hierarchical collection of containers known as the logical structure. The top-level logical container in this hierarchy is the forest. Within a forest are domain containers, and within domains are organizational units. Understanding domains and forests requires understanding the possible relationships they might have in Active Directory. The relationships between these logical containers might be based on administrative requirements, such as delegation of authority, or they might be defined by operational requirements, such as the need to provide for data isolation. Service administrators can use domain and forest containers to meet a number of specific requirements, including:

• • • •

Implementing an authentication and authorization strategy for sharing resources across a network Providing a mechanism for centralizing management of multiple domains and forests Providing an information repository and services to make information available to users and applications Organizing objects of a network (such as users, computers, devices, resources, and application specific data from

directory-enabled applications) into a non-physical hierarchical structure To learn more about domains and forests, you must first understand the logical and physical structures of Active Directory. This section describes how those structures differ, and defines domains and forests in terms of the logical structure. Top of page

The Logical Structure of Active Directory Active Directory stores network object information and implements the services that make this information available and usable to users. Active Directory presents this information through a standardized, logical structure that helps you establish and understand the organization of domains and domain resources in a useful way. This presentation of object information is referred to as the logical structure because it is independent of the physical aspects of the Active Directory infrastructure, such as the domain controllers required for each domain in the network.

Benefits of the Logical Structure The logical structure provides a number of benefits for deploying, managing, and securing network services and resources. These benefits include:

•

Increased network security. The logical structure can provide security measures such as autonomy for individual groups or complete isolation of specific resources.

• • •

Simplified network management. The hierarchical nature of the logical structure simplifies configuration, control, and administration of the network, including managing user and group accounts and all network resources. Simplified resource sharing. The logical structure of domains and forests and the relationships established between them can simplify the sharing of resources across an organization. Low total cost of ownership. The reduced administration costs for network management and the reduced load on network resources that can be achieved with the Active Directory logical structure can significantly lower the total cost of

ownership. An efficient Active Directory logical structure also facilitates the system integration of features such as Group Policy, enabling desktop lockdown, software distribution, and administration of users, groups, workstations, and servers. In addition, the logical structure can facilitate the integration of services such as Exchange 2000, public key infrastructure (PKI), and domain-based distributed file system (DFS).

Components of the Logical Structure The logical structure consists of leaf object and container object components that must conform to the hierarchical structure of an Active Directory forest. Leaf objects are objects that have no child objects, and are the most basic component of the logical structure. Container objects store other objects and occupy a specific level within the forest hierarchy. The relationships among the components of the logical structure control access to stored data and determine how that data is managed across one or more domains within a single forest. The components that make up the Active Directory logical structure are described in the following table. Components of the Active Directory Logical Structure

Component

Description

Organizational

Organizational units are container objects. You use these container objects to arrange other objects in a

Units

manner that supports your administrative purposes. By arranging objects in organizational units, you make it easier to locate and manage them. You can also delegate the authority to manage an organizational unit. Organizational units can be nested in other organizational units. You can arrange objects that have similar administrative and security requirements into organizational units. Organizational units provide multiple levels of administrative authority, so that you can apply Group Policy settings and delegate administrative control. This delegation simplifies the task of managing these objects and enables you to structure Active Directory to fit your organization’s requirements.

Domains

Domains are container objects. Domains are a collection of administratively defined objects that share a common directory database, security policies, and trust relationships with other domains. In this way, each domain is an administrative boundary for objects. A single domain can span multiple physical locations or sites and can contain millions of objects.

Domain Trees

Domain trees are collections of domains that are grouped together in hierarchical structures. When you add a domain to a tree, it becomes a child of the tree root domain. The domain to which a child domain is attached is called the parent domain. A child domain might in turn have its own child domain. The name of a child domain is combined with the name of its parent domain to form its own unique Domain Name System (DNS) name such as Corp.nwtraders.msft. In this manner, a tree has a contiguous namespace.

Forests

A forest is a complete instance of Active Directory. Each forest acts as a top-level container in that it houses all domain containers for that particular Active Directory instance. A forest can contain one or more domain container objects, all of which share a common logical structure, global catalog, directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. The first domain in the forest is called the forest root domain. The name of that domain refers to the forest, such as Nwtraders.msft. By default, information in Active Directory is shared only within the forest. In this way, the forest is a security boundary for the information that is contained in that instance of Active Directory.

Site Objects

Sites are leaf and container objects. The sites container is the topmost object in the hierarchy of objects that are used to manage and implement Active Directory replication. The sites container stores the hierarchy of objects that are used by the Knowledge Consistency Checker (KCC) to effect the replication topology. Some of the objects located in the sites container include NTDS Site Settings objects, subnet objects, connection

Component

Description objects, server objects, and site objects (one site object for each site in the forest). The hierarchy is displayed as the contents of the Sites container, which is a child of the Configuration container.

By understanding the purpose and hierarchical structure of these components, you can complete a variety of tasks, including installing, configuring, managing, and troubleshooting Active Directory. Although the logical structure of Active Directory is a hierarchical organization of all users, computers, and other physical resources, the forest and domain form the basis of the logical structure. Forests, which are the security boundaries of the logical structure, can be structured to provide data and service autonomy and isolation in an organization in ways that can both reflect site and group identities and remove dependencies on the physical topology. Domains can be structured within a forest to provide data and service autonomy (but not isolation) and to optimize replication with a given region. This separation of logical and physical structures improves manageability and reduces administrative costs because the logical structure is not impacted by changes in the physical structure, such as the addition, removal, or reorganization of users and groups. Note

•

You can view and manage components of the logical structure by using the Active Directory Users and Computers, Active Directory Domains and Trusts, and Active Directory Schema Microsoft Management Console (MMC) snap-ins, and other tools.

Top of page

The Physical Structure of Active Directory The physical structure of Active Directory is represented by a set of physical components which, when configured correctly, can help optimize the transmission of network replication and authentication in ways specifically tailored to fit your physical network. Physical network components, such as domain controllers and physical subnets, are used to facilitate network communication and to set physical boundaries around network resources. More specifically, the physical structure of Active Directory represents all of the physical subnets in your enterprise network, the domain controllers in those physical subnets (commonly referred to as Sites in Active Directory) and the replication connections between the domain controllers. Sites and subnets are represented in Active Directory by site and subnet objects. Computers on TCP/IP networks are assigned to site objects based on their location in a physical subnet or a set of physical subnets. Physical subnets group computers in a way that identifies their physical proximity on the network. Each site object is associated with one or more subnet objects. Subnet objects are used during the process of domain controller location to find a domain controller in the same site as the computer that is logging on. This information also is used during Active Directory replication to determine the best routes between domain controllers. This enables you to use network bandwidth more efficiently. For example, it ensures that when users log on to the network they are authenticated by the authentication authority nearest to the user, thus reducing the amount of network traffic. The physical domain controller contains the directory partitions that are replicated. Although the logical and physical structures are defined and configured independently, they have interdependencies that affect replication. Note

•

You can view the physical structure of Active Directory by using Active Directory Sites and

Services. For more information about the network components associated with the physical structure of Active Directory, see the “Active Directory Replication Topology Technical Reference.” Top of page

What Are Domains? Domains are logical directory components that you create to manage the administrative requirements of your organization. The logical structure is based on the administrative requirements of an organization, such as the delegation of administrative authority, and operational requirements, such as the need to control replication. In general, domains are used to control where in the forest replication of domain data occurs and organizational units are used to further organize network objects into a logical hierarchy and delegate control to appropriate administrative support personnel. A domain is a partition in an Active Directory forest. Partitioning data enables organizations to replicate data only to where it is needed. In this way, the directory can scale globally over a network that has limited available bandwidth. Domains can also be defined as:

• • • • •

Containers within a forest Units of Policy Units of Replication Authentication and Authorization Boundaries Units of Trust

Each domain has a domain administrators group. Domain administrators have full control over every object in the domain. These administrative rights are valid within the domain only and do not propagate to other domains.

Domains as Containers within a Forest Within the scope of a forest, a domain is a container. Objects in that container inherently trust each other and the security services located in that same container. Each time you create a new domain container in a forest, a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. Trusts are logical relationships established between domains to allow pass-through authentication in which a trusting domain honors the logon authentications of a trusted domain. Because all domain containers within a forest are joined together by two-way transitive trusts, objects within one domain container also inherently trust all other objects and security services located in every domain container located in that forest. Domain containers are used to store and manage Active Directory objects, some of which have a physical representation. All of the objects within the domain container are stored in a central database that stores only objects created within that domain. Some objects represent people or groups of people, while others represent computers or network servers. Examples of Active Directory objects that have a physical representation are user, computer, and group objects. While domains contain objects that represent physical things, they also contain objects that are used to help self-regulate domain operations such as trusted domain objects (TDOs) and site link objects. Domain containers can also hold subordinate containers such as organizational units. The following figure shows where objects are stored within the logical structure of a domain. Domain Containment Structure Within a Forest

Organizational Units and Objects Organizational units are used to group objects, including accounts and resources in a domain, for administrative purposes, such as the application of Group Policy or delegation of authority. Control over an organizational unit, including the objects within it, is determined by the access control lists (ACLs) on the organizational unit and on the objects in the organizational unit.

Organizational Units The organizational unit is a particularly useful type of directory object contained within domains. Each organizational unit is an Active Directory container within a domain into which users, groups, computers, and other organizational units of the domain can be placed. An organizational unit cannot contain objects from other domains.

An organizational unit is the smallest scope or unit to which Group Policy settings can be assigned or to which administrative authority can be delegated. A hierarchy of organizational units can be extended as necessary to model the hierarchy of an organization within a domain. The administrative model of the organizational unit can be scaled to any size. For more information about Group Policy, see “How Core Group Policy Works.” Administrative authority can be delegated for individual organizational units or for multiple organizational units. Organizational units can be nested to create a hierarchy within a domain and form logical administrative units for users, groups, and resource objects, such as printers, computers, applications, and file shares. The organizational unit hierarchy within a domain is independent of the structure of other domains: Each domain can implement its own hierarchy. Likewise, domains that are managed by the central authority can implement similar organizational unit hierarchies. The structure is flexible, which allows organizations to create an environment that mirrors the administrative model, whether it is centralized or decentralized.

Objects Active Directory objects represent the physical entities that make up a network. An object stores an instance of a class. A class is defined in the Active Directory schema as a specific set of mandatory and optional attributes — that is, an attribute can be present in an object in Active Directory only when that attribute is permitted by the object’s class. Classes also contain rules that determine which classes of objects can be superior to (parents of) a particular object of the class. Each attribute is also defined in the directory schema. The attribute definitions determine the syntax for the values the attribute can have. Creation of an Active Directory object requires specification of values for the attributes of the object in its particular class, consistent with the rules of the directory schema. For example, creating a user object requires specification of alphanumeric values for the user’s first and last names and the logon identifier, which are mandatory according to the directory schema. Other non-mandatory values can also be specified, such as telephone number and address. Applications that create or modify objects in Active Directory use the directory schema to determine what attributes the object must and might have, and what those attributes can look like in terms of data structures and syntax constraints. The directory schema is maintained forest-wide so that all objects created in the directory conform to the same values. Objects are either container objects or leaf objects. A container object stores other objects, and as such occupies a specific level in a subtree hierarchy. An object class is a container if at least one other class specifies it as a possible superior, so any object class defined in the schema can become a container. A leaf object does not store other objects, so it occupies the endpoint of a subtree. For more information about Active Directory Objects, see “How Domains and Forests Work” and “How the Active Directory Schema Works.”

Domains as Units of Policy A domain defines a scope or unit of policy within a forest. Some policy settings apply only to the scope of a domain, that is, the policy settings are domain-wide. Account policies, for example, apply uniformly to all user accounts in the domain. Although a domain is not the smallest unit of policy that can be assigned (policies can be assigned to organizational units) it is the most commonly used unit when splitting administrative duties between departments and subsidiaries located in different geographical locations. As shown in the following figure, you might need to create multiple domains to provide for policy variance among domains throughout a forest. A domain is also considered a unit of access control, in that it can be used for business groups requiring general autonomy. Delegation of Domains to Domain Admins that Require Different Policies or Autonomy

You cannot define different account policies for different organizational units in the same domain. Policy settings are stored as Group Policy objects (GPOs) in Active Directory. A GPO establishes how domain resources can be accessed, configured, and used. The policies associated with a GPO are applied only within the domain and not across domains. A GPO can be associated with one or more Active Directory containers, such as a site, domain, or organizational unit. Account policies and Public Key policies have domain-wide scope and are set at the domain GPO level. All other policies can be specified at the level of the organizational unit. Some policies that can be applied only at the domain container level include:

• • •

Password policy. Determines the rules, such as password length, that must be met when a user sets a password. Account lockout policy. Defines rules for intruder detection and account deactivation. Kerberosticket policy. Determines the lifetime of a Kerberos ticket. A Kerberos ticket is obtained during the logon process

and is used for network authentication. A particular ticket is only valid for the lifetime specified in the policy. Because organizational units provide multiple levels of administrative authority, you can use them to systematically apply Group Policy settings and delegate administrative control. Delegation simplifies the task of managing these objects and enables you to structure Active Directory to fit the requirements of your organization. Using delegated authority in conjunction with GPOs and group memberships allows one or more administrators to be assigned rights and permissions to manage objects in an entire domain or in one or more organizational units within the domain. For more information about Group Policy, see “How Core Group Policy Works.”

Domains as Units of Replication The physical significance of a domain is that it is a unit of replication. In fact, with the exception of application partitions, which replicate only non-security principal objects, the domain is the smallest unit of replication that can be administered within an Active Directory forest. This is because all objects that are located within a domain container, also referred to as domain data, are replicated to other domain controllers within that same domain, regardless of whether those domain controllers are located over a local area network (LAN) or wide area network (WAN) connection.

As shown in the following figure, Active Directory multi-master replication manages the transfer of domain objects to the appropriate domain controllers automatically, keeping domain data up-to-date among all domain controllers in the domain, regardless of location. Replication of Domain Data Within Each Domain in the Forest

All domain controllers in the forest are also updated with changes to forest-wide data. For more information about replication at the Forest level, see “Forests as Units of Replication” later in this section Domain-wide replication relies on three components of the Active Directory physical structure to be in place for optimal performance, these include:

Domain Controllers The physical domain controller contains the domain partition data that is replicated to other domain controllers in that same domain. A domain partition stores only the information about objects located in that domain. All domain controllers in a domain receive changes and replicate those changes to the domain partition stored on all other domain controllers in the domain. In this way, all domain controllers are peers in the domain and manage replication as a unit. Domain controllers also have two non-domain directory partitions that store forest-wide data, which includes the directory schema and configuration data. Optionally, on Windows Server 2003 domain controllers, application partitions can be configured to be located on designated domain controllers anywhere in a forest. Unlike the schema and configuration partitions, application partitions are not located on every domain controller in a forest. For more information about the replication of forest-wide data, see “Forests as Units of Replication” later in this section. Partitioning Active Directory data into three physical partitions on each domain controller helps to control replication so that data is replicated only to where it is needed. In this way, Active Directory can scale globally over a network that has limited available bandwidth.

Sites Within the scope of a forest, sites are a representation of the physical network topology. This includes physical subnet and site definitions. Replication of updates to domain data occurs between multiple domain controllers to keep replicas synchronized. Multiple domains are common in large organizations, as are multiple sites in disparate locations. In addition, domain controllers for the same domain are commonly placed in more than one site. Therefore, replication must often occur both within sites and between sites to keep domain and forest data consistent among domain controllers that store the same directory partitions. Replication within sites generally occurs at typical LAN speeds between domain controllers that are on the same network segment. Replication between sites usually occurs over WAN links that might be costly in terms of bandwidth. To accommodate the differences in distance and cost of replication within a site and between sites, the intrasite replication topology is used to optimize speed, and the intersite replication topology is used to minimize cost based on a configurable replication schedule. The Knowledge Consistency Checker (KCC) is a distributed application that runs on every domain controller and is responsible for creating the connections between domain controllers that collectively form the replication topology. The KCC uses Active Directory data to determine where to create connections between source domain controllers and destination domain controllers. Intersite replication is optimized for bandwidth efficiency, and directory updates between sites occur automatically based on a configurable schedule.

Domain-Wide Operations Masters Active Directory supports multi-master replication of the directory data store between all domain controllers in the domain. However, some changes are impractical to perform in multi-master fashion, so only a single domain controller, called the operations master, accepts requests for such changes. Because these roles can be transferred to other domain controllers within the domain or forest, they are sometimes referred to as operations master roles. There are three operations master roles per domain. These include the Relative Identifier (RID) Master, Primary Domain Controller (PDC) emulator, and Infrastructure Master. These three roles must be unique in each domain, so each domain can have only one RID master, one PDC emulator, and one Infrastructure Master. For information about forest-wide roles, see “Forest-Wide Operations Master Roles” later in this section. For more information about replication, see “How Active Directory Replication Topology Works.”

Domains as Authentication and Authorization Boundaries By default, a domain provides authentication and authorization services for all its accounts in order to facilitate logons and single sign-on access control to shared resources within the boundaries of the domain. The process of authentication ensures that users are who they claim to be. Once identified, the user can be authorized access to a specific set of network resources based on permissions.Authorization takes place through the mechanism of access control, using access control lists (ACLs) that define permissions on file systems, network file and print shares, and entries in Active Directory. Authorization is determined not only by the identity of the user but also the membership of the user in one or more security groups. In fact, the preferred method of controlling domain-wide resources is to grant access to groups rather than to individuals, adjusting the level of authorization for a group according to the needs of its members. This method of controlling access makes it easier to keep ACLs up-to-date on domains that have thousands of users and objects. Group membership can be managed centrally by anyone with the appropriate administrative credentials. You can change the level of authorization a particular user has to many resources simply by adding or removing the user from a group. The following figure shows when authentication and authorization for a user in a given domain occur. Authentication and Authorization of a User Within the Same Domain

Authentication is not limited to users. Computers and services are also authenticated when they make network connections to other servers. For example, Windows Server 2003–based servers and client computers connect Active Directory in their domain for policy information during startup. Computers and services also prove their identity to clients that request mutual authentication. Mutual authentication prevents an intruder from adding another computer as an imposter between the client and the real network server. The Kerberos version 5 authentication protocol is a technology for single sign-on to network resources. Windows Server 2003 uses the Kerberos V5 protocol to provide single sign-on to network services within a domain, and to services residing in trusted domains. The Kerberos V5 protocol verifies both the identity of the user and of the network services, providing mutual authentication. Authentication and authorization services in one domain can be extended to accounts that are located in trusted domains. This can be done by using trusts. Trusts are logical relationships established between domains to allow pass-through authentication in which a trusting domain honors the logon authentications of a trusted domain. Consequently, trust relationships inherently allow domain-specific authentication and authorization services to be extended, thereby enabling single sign-on access control capabilities throughout a forest. Because the domain trust relationships between all domains in the forest are bidirectional by default, authentication in one domain is sufficient for referral or pass-through authentication to resources in other domains in the forest.

Domains as Units of Trust A domain is the smallest container within Active Directory that can be used in a trust relationship. All domains within a forest are connected by Kerberos-based trusts. Kerberos-based trusts are two-way and transitive in nature. Trusts act as authentication pipelines that must be present in order for users in one domain to access resources in another domain. All authentication requests made between domains located inside or outside of a forest must occur over trusts. Trust relationships within a forest are created as implicit two-way transitive trusts. Note

•

“Access to resources” in any discussion of trust relationships always assumes the limitations of access control.

Within a forest, trust relationships are automatically created between the forest root domain and any tree root domains on the one hand, and all child domains that are subordinate to the forest root domain on the other. Because trust relationships are two-way and transitive by default, users and computers can be authenticated between any domain containers in the forest, as shown in the following figure. Domains as Units of Trust and the Authentication Paths they Provide

In accordance with DNS naming standards, Active Directory domains within a single forest are created in an inverted tree structure, with the forest root domain at the top. This tree structure requires that trusts exist between domains to facilitate security of communications. Adding a domain tree to a forest requires specification of the forest root domain, which results in the establishment of a trust relationship between the root domain of the new tree and the forest root domain. For more information about trusts and root domains, see “Forests as Collections of Domain Containers that Trust Each Other” later in this section.

What Domains Are Not Domains are not security boundaries within the scope of Active Directory and do not provide complete isolation in the face of possible attacks by malicious service administrators who might manage that forest. This is because a malicious service administrator, such as a member of the Domain Admins group, can use nonstandard tools and procedures to gain full access to any domain in the forest or to any computer in the forest. For example, service administrators in a non-root domain can make themselves members of the Enterprise Admins or Schema Admins group. However, administrative rights do not flow across domain boundaries, nor do they flow down through a domain tree. For example, if you have a domain tree with domains A, B, and C, where A is the parent domain of B and B is the parent domain of C, users with administrative rights in domain A do not have administrative rights in B, nor do users with administrative rights in domain B have administrative rights in domain C. For a user to obtain administrative rights in a given domain, a higher authority must grant them. This does not mean, however, that an administrator cannot have administrative rights in multiple domains; it simply means that all rights must be explicitly defined. For more information about isolation, see “Forests as Security Boundaries” later in this section. Top of page

What Are Forests? At its highest level, a forest is a single instance of Active Directory. Therefore, a forest is synonymous with Active Directory, meaning that the set of all directory partitions in a particular Active Directory instance (which includes all domain, configuration, schema and optional application information) makes up a forest. This means that when you have multiple

forests in an enterprise they will, by default, act separately from each other as if they were the only directory service in your organization. This behavior, however, is easily be modified so that multiple forests can share Active Directory responsibilities across an enterprise. This is done by creating external or forest trust relationships between the forests. In this way, each forest can be connected with every other forest to form a collaborative directory service solution for any enterprise with business needs that include multiple forest collaboration. Forests can also be defined as:

• • • •

Collections of Domain Containers that Trust Each Other Units of Replication Security Boundaries Units of Delegation

Forests as Collections of Domain Containers that Trust Each Other Within the scope of Active Directory, a forest is a collection of domain containers that inherently trust each other and other security services that are located in that same forest. All domain containers in a forest share a common global catalog, directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. Because all of the domain containers are inherently joined through two-way transitive trusts, all authentication requests made from any domain in the forest to any other domain in the same forest will be granted. In this way, all security principals that are located in domain containers within a forest inherently trust each other. Forests can be used to segregate domain containers into one or more unique DNS namespace hierarchies known as domain trees. Although each domain tree consists of a unique namespace the schema and configuration data for the forest are shared throughout all the domain containers in a forest irrespective of namespace. Each domain container in a forest must adhere to DNS naming schemes and all domains are organized in a root and subordinate domain hierarchy. Root domains, such as forest root and tree root domains, define the DNS namespace for their subordinate domains. Although a forest can consist of multiple domain trees, it represents one organization. However, an organization can have multiple forests. For more information about multiple forests, see “Forests as Units of Delegation” later in this section. As shown in the following figure, the namespace for each root domain must be unique. Domain Containers, Root Domains and DNS Namespaces Within a Forest

Forest Root Domain Although trees in a forest do not share the same DNS namespace, a forest does have a single root domain, called the forest root domain. The forest root domain is, by definition, the first domain created in the forest. The Enterprise Admins and Schema Admins groups are located in this domain. By default, members of these two groups have forest-wide administrative credentials. In Windows 2000 Active Directory, the forest root domain cannot be deleted, changed, or renamed. In Windows Server 2003 Active Directory, the forest root domain cannot be deleted, but it can be restructured or renamed. Objects are located within Active Directory domains according to a hierarchical path, which includes the labels of the Active Directory domain name and each level of container objects. The full path to the object is defined by the distinguished name (also known as a DN). The distinguished name is unambiguous (identifies one object only) and unique (no other object in the directory has this name). By using the full path to an object, including the object name and all parent objects to the root of the domain, the distinguished name uniquely and unambiguously identifies an object within a domain hierarchy. The distinguished name of the forest root domain is used to locate the configuration and schema directory partitions in the namespace. The distinguished names for the Configuration and Schema containers in Active Directory always show these containers as child objects in the forest root domain. For example, in the child domain Noam.wingtiptoys.com (where Wingtiptoys.com is the name of the forest root domain), the distinguished name of the Configuration container is cn=configuration,dc=wingtiptoys,dc=com. The distinguished name of the Schema container is cn=schema,cn=configuration,dc=wingtiptoys,dc=com. However, this naming convention provides only a logical location for these containers. These containers do not exist as child objects of the forest root domain, nor is the schema directory partition actually a part of the configuration directory partition: They are separate directory partitions. Every domain controller in a forest stores a copy of the configuration and schema directory partitions, and every copy of these partitions has the same distinguished name on every domain controller.

Tree Root Domain A domain tree represents a unique DNS namespace: it has a single root domain, known as the tree root domain, and is built as a strict hierarchy: Each domain above the tree root domain has exactly one superior, or parent, domain (the forest root domain). The namespace created by this hierarchy, therefore, is contiguous — each level of the hierarchy is directly related

to the level above it and to the level below it. In other words, the names of domains created beneath the tree root domain (child domains) are always contiguous with the name of the tree root domain. The DNS names of the child domains of the root domain of a tree reflect this organization; therefore, the children of a root domain called Somedomain are always children of that domain in the DNS namespace (for example, Child1.somedomain, Child2.somedomain, and so forth). Multiple domain trees can belong to a single forest and do not form a contiguous namespace; that is, they have noncontiguous DNS domain names. Although the roots of the separate trees have names that are not contiguous with each other, the trees share a single overall namespace because names of objects can still be resolved by the same Active Directory instance. A forest exists as a set of cross-reference objects and trust relationships that are known to the member trees. Transitive trusts at the root domain of each namespace provide mutual access to resources. The domain hierarchy in a forest determines the transitive trust links that connect each domain. Each domain has a direct trust link with its parent and each of its children. If there are multiple trees in a forest, the forest root domain is at the top of the trust tree and, from a trust perspective, all other tree roots are children. That means authentication traffic between any two domains in different trees must pass through the forest root.

Forests as Units of Replication Unlike domains, forests are the largest unit of replication that can be administered in an Active Directory environment. To efficiently synchronize data between domain controllers throughout a forest, Active Directory replication transfers updates according to directory partition. Directory partitions are used to help organize how replication occurs within a forest. Active Directory uses four distinct directory partition types to store and copy four different types of data. One directory partition contains domain data; the other three are forest-wide partitions, and contain configuration, schema, and application data. This storage and replication design provides directory information to users and administrators throughout the domain. Each domain controller receives directory updates to the data stored in its domain only, as well as updates to the data in the two directory partitions that store configuration and schema data for the forest. As shown in the following figure, schema and configuration data must be replicated to all domain controllers that exist in a forest, while optional Application data is replicated only to domain controllers within the same forest running Windows Server 2003 that are specified as replication partners. Forest-Wide Replication Scope

The following table describes each of the three forest-wide partitions in more detail. Forest-Wide Directory Partitions

Partition

Description

Schema

The schema partition contains the forest-wide schema. Each forest has one schema so that the definition of each object class is consistent. The schema is the formal definition of all object and attribute data that can be stored in the directory. Active Directory domain controllers include a default schema that defines many object types, such as user and computer accounts, groups, domains, organization units, and security policies. Administrators and programmers can extend the schema by defining new object types and attributes or by adding new attributes for existing objects. Schema objects are protected by access control lists, ensuring that only authorized users can alter the schema. The schema partition is replicated to each domain controller in the forest.

Configuration The configuration partition describes the topology of the forest as well as other forest, domain and domain controller settings. This configuration data includes a list of all domains, trees, and forests and the locations of the domain controllers and global catalogs. The configuration partition is replicated to each domain controller in the forest. Application

Applications and services can use application directory partitions to store application-specific data. Data stored

Partition

Description in the application directory partition is intended to satisfy cases where information needs to be replicated but not necessarily on a global scale. Application directory partitions can contain any type of object, except security principals. Application directory partitions are usually created by the applications that will use them to store and replicate data. One of the benefits of an application directory partition is that, for redundancy, availability, or fault tolerance, the data in it can be replicated to different domain controllers in a forest. The data can be replicated to a specific domain controller or any set of domain controllers anywhere in the forest. This differs from a domain directory partition in which data is replicated to all domain controllers in that domain. Only domain controllers running Windows Server 2003 can host a replica of an application directory partition. Application directory partitions are created, configured, and managed by the administrator.

All forest replication is Multi-Master with the exception of the three domain-wide and two forest-wide operations master roles. Forest-wide replication requires domain controllers and three other components of the Active Directory physical structure to be in place for optimal performance. These components are forest-wide operations master roles, sites, and global catalogs.

Forest-Wide Operations Master Roles There are two operations master roles assigned for the entire forest. These include the domain naming master and the schema master. Each forest must have one and only one schema master and one domain naming master, so these two roles must remain in the forest root domain. The other three operations master roles are assigned to each domain in the forest. These three roles must be unique in each domain, so each domain can have only one relative ID master, one PDC emulator, and one infrastructure master. In an Active Directory forest with only one domain and one domain controller, that domain controller has all the operations master roles. For more information about operations master roles, see “How Operations Masters Work.”

Sites Sites in Active Directory represent the physical structure, or topology, of the network. Within the scope of a forest, sites are a representation of the physical network topology, including physical subnet and site definitions. When you establish sites, domain controllers within a single site communicate frequently. This communication minimizes the latency within the site; that is, the time required for a change that is made on one domain controller to be replicated to other domain controllers. You create sites to optimize use of the bandwidth between domain controllers in different locations. For more information about sites, see “How Active Directory Replication Topology Works.”

Global Catalogs The global catalog stores a full copy of all Active Directory objects in the directory for its host domain and a partial copy of all objects for all other domains in the forest. Users in a forest do not need to be aware of directory structure because all users see a single directory through the global catalog. Applications and clients can query the global catalog to locate any object in a forest. The global catalog is hosted on one or more domain controllers in the forest. It contains a partial replica of every domain directory partition in the forest. These partial replicas include replicas of every object in the forest, including the attributes most frequently used in search operations and the attributes required to locate a full replica of the object. A global catalog is created automatically on the first domain controller in the forest. Optionally, other domain controllers can be configured to serve as global catalogs. A global catalog serves the following roles:

• •

Enables user searches for directory information about objects throughout all domains in the forest

• •

Supplies universal group membership information in a multiple domain environment

Resolves user principal names (UPNs) during authentication, when the authenticating domain controller does not have information about the account Validates references to objects in other domains in the forest

For more information about global catalogs and their roles, see “How the Global Catalog Works.”

Forests as Security Boundaries Each forest is a single instance of the directory, the top-level Active Directory container, and a security boundary for all objects that are located in the forest. This security boundary defines the scope of authority of the administrators. In general, a security boundary is defined by the top-level container for which no administrator external to the container can take control away from administrators within the container. As shown in the following figure, no administrators from outside a forest can control access to information inside the forest unless first given permission to do so by the administrators within the forest. Enterprise Administrators Outside of a Forest Can Administer Only Within Their Own Forest

A forest is the only component of the Active Directory logical structure that is a security boundary. By contrast, a domain is not a security boundary because it is not possible for administrators from one domain to prevent a malicious administrator from another domain within the forest from accessing data in their domain. A domain is, however, the administrative boundary for managing objects, such as users, groups, and computers. In addition, each domain has its own individual security policies and trust relationships with other domains.

Forests as Units of Delegation The forest is the largest management unit of Active Directory as well as the ultimate unit of autonomy and isolation of authority. Members of the Enterprise Admins and forest root Domain Admins security groups are known as enterprise administrators. Enterprise administrators control the Active Directory objects in the configuration container that do not belong to any one domain, including Enterprise Certification Authority objects and other configuration data that affects all domains in the forest. Because enterprise administrators have authority over all domains in the forest, the domain administrators in each domain must trust the enterprise administrators. You cannot truly restrict enterprise administrators from managing objects in any domain in the forest. Enterprise administrators can always regain control over objects. Some organizations with political challenges, such as those frequently encountered in mergers and acquisitions, might find the scope of this enterprise authority too great and require more than one forest. If your organization requires strict isolation of authority between domains, you must deploy multiple forests with manually created trusts between domains in the different forests. Because each forest is administered separately, adding additional forests to your organization increases the management overhead of the organization. The number of forests that you need to deploy is based on the autonomy and isolation requirements of each group within your organization. Reasons to create multiple forests in your organization include:

• •

To secure data within each forest. Sensitive data can be protected so that only users within that forest can access it. To isolate directory replication within each forest. Schema changes, configuration changes, and the addition of new

domains to a forest have forest-wide impact only within that forest, not on a trusting forest. Because the forest is a security boundary, each forest does not trust or allow access from any other forest by default. However, in Windows Server 2003 Active Directory, transitive trust relationships can be manually established between forests to establish cross-forest access to resources, so that users in one forest can access resources in another forest. Forest trusts help you to manage a segmented Active Directory infrastructure within your organization by providing support for accessing resources and other objects across multiple forests. By using forest trusts, you can link two different Windows Server 2003 forests to form a one-way or two-way transitive trust relationship. A forest trust allows administrators to

federate two Active Directory forests with a single trust relationship to provide a seamless authentication and authorization experience across the forests. When two forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests. Trust security settings and firewalls can be configured between domains in different forests that are joined by trust relationships to limit cross-forest connectivity to specific users or applications. For more information about trust security settings, see “Security Considerations for Trusts.” A forest trust can be created only between a forest root domain in one Windows Server 2003 forest and a forest root domain in another Windows Server 2003 forest. Forest trusts can be created between two forests only and cannot be implicitly extended to a third forest. This means that if a forest trust is created between Forest 1 and Forest 2, and another forest trust is created between Forest 2 and Forest 3, Forest 1 does not have an implicit trust with Forest 3. The following figure shows two separate forest trust relationships between three Windows Server 2003 forests in a single organization. Two Forest Trusts Between Three Windows Server 2003 Forests

Top of page

Related Information The following resources contain additional information that is relevant to this section.

•

How Active Directory Replication Topology

• • • • • •

How Core Group Policy Works

Works How Domains and Forests Work How Operations Masters Work How the Active Directory Schema Works How the Global Catalog Works Security Considerations for Trusts

How Domains and Forests Work

Updated: March 28, 2003

How Domains and Forests Work In this section

• • • • • •

Domain and Forest Structure Active Directory Objects Domain and Forest Protocols and Programming Interfaces Domains and Forests Processes and Interactions Network Ports used by Domains and Forests Related Information

Active Directory stores data for an entire forest. A forest is a distributed database, which is made up of directory partitions spread across multiple computers. A domain is one partition of the database; each domain contains Active Directory objects, such as security principal objects (users, computers, and groups) to which you can grant or deny access to network resources. All domain data stored in the domain directory partition is replicated to domain controllers in that domain only. The directory partitions that store configuration and schema information are replicated to domain controllers in all domains. In this way, Active Directory provides a data repository that is logically centralized but physically distributed. Because all domain controllers store forest-wide configuration and schema information, a domain controller in one domain can reference a domain controller in any other domain if the information that it is requesting is not stored locally. This section details how domains and forests work, discusses the various components of domains and forests, describes several common processes that depend on domains and forests, and lists the network ports related to domains and forests.

Top of page

Domain and Forest Structure A forest consists of a hierarchical structure of domain containers that are used to categorically store information about objects on the network. Domain containers are considered the core functional units in the forest structure. This is because each domain container in a forest is used primarily to store and manage Active Directory objects, most of which have a physical representation (such as people, printers, or computers). Forests also provide the structure by which domain containers can be segregated into one or more unique Domain Name System (DNS) namespace hierarchies known as domain trees. In addition, the domain tree hierarchy is based on trust relationships — that is, the domain containers are linked by intraforest trust relationships. When it is necessary for domain containers in the same organization to have different namespaces, you can create a separate tree for each namespace. In Active Directory, the roots of trees are linked automatically by twoway, transitive trust relationships. Trees linked by trust relationships form a forest. A single tree that is related to no other trees constitutes a forest of one tree. The domain and forest structure is made up of the following components:

• • • •

Cross-References

•

Domain Names

Trust Relationships Forest Root Domain Trees and Child Domains

For more information about Active Directory Domains and DNS, see “How DNS Support for Active Directory Works.” This section describes the structure and function of these components, and describes how this structure helps administrators manage the network so that users can accomplish business objectives.

Cross-References Cross-references enable every domain controller to be aware not only of the partitions that it holds, but of all directory partitions in the forest. The information contained within cross-references form the glue that holds the pieces of the domain and forest structure together. Because Active Directory is logically partitioned, and directory partitions are the discrete components of the directory that replicate between domain controllers, either all objects in a directory partition are present on a particular domain controller or no objects in the directory partition are present on the domain controller. For this reason, cross references have the effect of linking the partitions together, which allows operations such as searches to span multiple partitions. Cross-references are stored as directory objects of the class crossRef that identify the existence and location of all directory partitions, irrespective of location in the directory tree. In addition, these objects contain information that Active Directory uses to construct the directory tree hierarchy. Values for the following attributes are required for each cross-reference:

• •

nCName. The distinguished name of the directory partition that the crossRef object references. (The prefix nC stands for naming context, which is a synonym for directory partition.) The combination of all of the nCName properties in the forest defines the entire directory tree, including the subordinate and superior relationships between partitions. dNSRoot. The DNS name of the domain where servers that store the particular directory partition can be reached. This value can also be a DNS host name.

How Cross-Reference Information is Propagated Throughout the Domain and Forest Structure For every directory partition in a forest, there is an internal cross-reference object stored in the Partitions container (cn=Partitions,cn=Configuration,dc=ForestRootDomain). Because cross-reference objects are located in the Configuration container, they are replicated to every domain controller in the forest, and thus every domain controller has information about the name of every partition in the forest. By virtue of this knowledge, any domain controller can generate referrals to any other domain in the forest, as well as to the schema and configuration directory partitions. When you create a new forest, the Active Directory Installation Wizard creates three directory partitions: the first domain directory partition, the configuration directory partition, and the schema directory partition. For each of these partitions, a cross-reference object is created automatically. Thereafter, when a new domain is created in the forest, another directory partition is created and the respective cross-reference object is created. When the configuration directory partition is

replicated to the new domain controller, a cross-reference object is created on the domain naming master and is then replicated throughout the forest. Note

•

The state of cross-reference information at any specific time is subject to the effects of replication

latency. For more information about cross-reference objects, see “How Active Directory Searches Work.” Cross-reference objects can also be used to generate referrals to other directory partitions located in another forest through external cross-references.

External Cross-References An external cross-reference is a cross-reference object that can be created manually to provide the location of an object that is not stored in the forest. If your Lightweight Directory Access Protocol (LDAP) clients submit operations for an external portion of the global LDAP namespace against servers in your forest, and you want servers in your forest to refer the client to the correct location, you can create a cross-reference object for that directory in the Partitions container. There are two ways that external cross-references are used:

• •

To reference external directories by their disjoint directory name (a name that is not contiguous with the name of this directory tree). In this case, when you create the cross-reference, you create a reference to a location that is not a child of any object in this directory. To reference external directories by a name that is within the Active Directory namespace (a name that is contiguous with the name of this directory tree). In this case, when you create the cross-reference, you create a referenceto a location

that is a child of a real object in this directory. Because the domain component (dc=) portion of the distinguished names of all Active Directory domains matches their DNS addresses, and because DNS is the worldwide namespace, all domain controllers can generate external referrals to each other automatically.

Trust Relationships Active Directory provides security across multiple domains through intra-forest trust relationships. When there are trust relationships between domains in the same forest, the authentication mechanism for each domain trusts the authentication mechanism for all other trusted domains. If a user or application is authenticated by one domain, its authentication is accepted by all other domains that trust the authenticating domain. Users in a trusted domain have access to resources in the trusting domain, subject to the access controls that are applied in the trusting domain. Note

•

Default intra-forest trust relationships are created at the time the domains are created. The number of trust relationships required to connect n domains is n–1, whether the domains are linked in a single, contiguous parent-child hierarchy or

constitute two or more separate contiguous parent-child hierarchies. A trust relationship is a relationship established between two domains that allows users in one domain to be recognized by a domain controller in the other domain. Trusts let users access resources in the other domain, and also let administrators manage user rights for users in the other domain. Account authentication between domains is enabled by two-way, transitive trust relationships. All domain trusts in an Active Directory forest are two-way and transitive and are have the following attributes:

• •

Two-way. When you create a new child domain, the child domain automatically trusts the parent domain, and vice versa. At the practical level, this means that authentication requests can be passed between the two domains in both directions. Transitive. A transitive trust reaches beyond the two domains in the initial trust relationship. For example, if Domain A and Domain B (parent and child) trust each other, and if Domain B and Domain C (also parent and child) trust each other,

Domain A and Domain C also trust each other (implicitly), even though no direct trust relationship between them exists. At the level of the forest, a trust relationship is created automatically between the forest root domain and the root domain of each domain tree added to the forest, with the result that complete trust exists between all domains in an Active Directory forest. At the practical level, because trust relationships are transitive, a single logon process lets the system authenticate a user (or computer) in any domain in the forest. As shown in the following figure, this single logon process lets the account access resources on any domain in the forest. Transitive Trusts Facilitate Cross-Domain Access to Resources With a Single Logon

Note

•

Single logons enabled by trusts do not necessarily imply that the authenticated user has rights and permissions in all domains in the forest. This is because in any discussion of trust relationships, access to resources always assumes the limitations of access control.

Forest Root Domain The first domain created in the forest is called the forest root domain. When you create a new tree, you specify the root domain of the initial tree, and a trust relationship is established between the root domain of the second tree and the forest root domain. If you create a third tree, a trust relationship is established between the root domain of the third tree and the forest root domain. Because all trust relationships created within a forest are transitive and two-way, the root domain of the third tree also has a two-way trust relationship with the root domain of the second tree. In Windows 2000 Active Directory, the forest root domain cannot be deleted, changed, or renamed. In Windows Server 2003 Active Directory, the forest root domain cannot be deleted, but it can be restructured or renamed. The distinguished name of the forest root domain is used to locate the configuration and schema directory partitions in the namespace. The distinguished names for the configuration and schema containers in Active Directory always show these containers as child objects in the forest root domain. For example, in the child domain Noam.wingtiptoys.com, the distinguished name of the Configuration container is cn=configuration,dc=wingtiptoys,dc=com. The distinguished name of the Schema container is cn=schema,cn=configuration,dc=wingtiptoys,dc=com. However, this naming convention provides only a logical location for these containers. The containers do not exist as child objects of the forest root domain, nor is the schema directory partition actually a part of the configuration directory partition. They are separate directory partitions. Every domain controller in a forest stores a copy of the configuration and schema directory partitions, and every copy of these partitions has the same distinguished name on every domain controller. The following operations occur when you create the forest root domain:

• •

The Schema container and the Configuration container are created. The Active Directory Installation Wizard assigns the PDC emulator, RID master, domain naming master, schema master, and infrastructure master roles to the domain controller.

The Enterprise Admins and Schema Admins groups are located in this domain. By default, members of these two groups have forest-wide administrative credentials.

Domain Trees and Child Domains A forest is a collection of one or more domain trees, organized as peers and connected by two-way, transitive trust relationships. A single domain constitutes a tree of one domain, and a single tree constitutes a forest of one tree. Thus, a forest is synonymous with Active Directory — that is, the set of all directory partitions in a particular directory service instance (which includes all domains and all configuration and schema information) makes up a forest. Trees in the same forest do not form a contiguous namespace. They form a noncontiguous namespace that is based on different DNS root domain names. However, trees in a forest share a common directory schema, configuration, and global catalog. (The global catalog is a domain controller that stores all objects of all domains in an Active Directory forest, which makes it possible to search for objects at the forest level rather than at the tree level.) This sharing of common schema and configuration data, in addition to trust relationships between their roots, distinguishes a forest from a set of unrelated trees. Although the roots of the separate trees have names that are not contiguous with each other, the trees share a single overall namespace because names of objects can still be resolved by the same Active Directory instance. Note

•

The directory schema and configuration data are shared because they are stored in separate logical directory partitions that are replicated to domain controllers in every domain in the forest. The data about a particular domain is replicated only to domain controllers in the same domain.

Domain Trees A domain tree is a DNS namespace: it has a single root domain and is built as a strict hierarchy; each domain below the root domain has exactly one superior, or parent, domain. The namespace created by this hierarchy, therefore, is contiguous — each level of the hierarchy is directly related to the level above it and to the level below it, if any. In Active Directory, the following rules determine the way that trees function in the namespace:

• • •

A tree has exactly one name. The name of the tree is the DNS name of the domain at the root of the tree. The names of domains created beneath the root domain (child domains) are always contiguous with the name of the tree root domain. The DNS names of the child domains of the tree root domain reflect this organization; therefore, the children of a tree root domain called Somedomain are always children of that domain in the DNS namespace (for example, Child1.somedomain,

Child2.somedomain, and so forth). Note

•

Tree and forest hierarchies are specific to Active Directory domains. A Windows NT 4.0 domain that is configured to trust

or to be trusted by a Active Directory domain is not part of the forest to which the Active Directory domain belongs. The forest structure provides organizations with the option of constructing their enterprise from separate, distinct, noncontiguous namespaces. Having a separate namespace is desirable under conditions where, for example, the namespace of an acquired company should remain intact. If you have business units with distinct DNS names, you can create additional trees to accommodate the names. Note

•

Before creating a new domain tree when you want a different DNS namespace, consider creating another forest. Multiple forests provide administrative autonomy, isolation of the schema and configuration directory partitions, separate security

boundaries, and the flexibility to use an independent namespace design for each forest. When you create a new domain tree, you specify the root domain of the initial tree, and a trust relationship is established between the root domain of the new tree (the second tree) and the forest root domain. If you create a third tree, a trust relationship is established between the root domain of the third tree and the forest root domain. Because a trust relationship is transitive and two-way, the root domain of the third tree also has a two-way trust relationship with the root domain of the second tree. The following operations occur when you create a new tree root domain in an existing forest:

• •

Location of a source domain controller in the forest root domain and synchronization of domain system time with the system time of the source domain controller. Creation of a tree-root trust relationship between the tree root domain and the forest root domain, and creation of the trusted domain object (TDO) in both domains. The tree-root trust relationship is two-way and transitive.

Child Domains Child domains can represent geographical entities (for example, the United States and Europe), administrative entities within the organization (for example, sales and marketing departments), or other organization-specific boundaries, according to the needs of the organization. Domains are created below the root domain to minimize Active Directory replication and to provide a means for creating domain names that do not change. Changes in the overall domain architecture, such as domain collapses and domain re-creation, create difficult and potentially IT-intensive support requirements. A good namespace design should be capable of withstanding reorganizations without the need to restructure the existing domain hierarchy. Each time you create a new child domain, a two-way transitive trust relationship (known as the parent-child trust) is automatically created between the parent and new child domain. In this way, transitive trust relationships flow upward through the domain tree as it is formed, creating transitive trusts between all domains in the domain tree. The parent-child relationship is a naming and trust relationship only. Administrators in a parent domain are not automatically administrators of a child domain. Likewise, policies set in a parent domain do not automatically apply to child domains. The following operations occur when you create a child domain in an existing tree:

• • • •

Verification of the name that you provide as a valid child domain name. Location of a source domain controller in the parent domain and synchronization of the system time of the child domain with the system time of the source domain controller. Creation of parent-child TDOs in the System folder on both the parent domain and the child domain. The TDO objects identify two-way transitive trust relationships between the child domain and the parent domain. Replication of the Active Directory Schema container and the Configuration container from a domain controller in the parent domain.

Domain Names Active Directory uses DNS naming standards for hierarchical naming of Active Directory domains and computers. For this reason, domain and computer objects are part of both the DNS domain hierarchy and the Active Directory domain hierarchy. Although these domain hierarchies have identical names, they represent separate namespaces. The domain hierarchy defines a namespace. A namespace is any bounded area in which standardized names can be used to symbolically represent some type of information (such as an object in a directory or an Internet Protocol [IP] address) and that can be resolved to the object itself. In each namespace, specific rules determine how names can be created and used. Some namespaces, such as the DNS namespace and the Active Directory namespace, are hierarchically structured and provide rules that allow the namespace to be partitioned. Other namespaces, such as the Network Basic Input/Output System (NetBIOS) namespace, are flat (unstructured) and cannot be partitioned. The main function of DNS is to map user-readable computer names to computer-readable IP addresses. Thus, DNS defines a namespace for computer names that can be resolved to IP addresses, or vice versa. In Windows NT 4.0 and earlier, DNS names were not required; domains and computers used NetBIOS names, which were mapped to IP addresses by using the Windows Internet Name Service (WINS). Although DNS names are required for Active Directory domains and Windows 2000–, Windows XP–, and Windows Server 2003–based computers, NetBIOS names also are supported in Windows Server 2003 for interoperability with Windows NT 4.0 domains and with clients that are running Windows NT 4.0 or earlier, Windows for Workgroups, Windows 98, or Windows 95. Note

•

WINS and NetBIOS are not required in an environment where computers run only Windows 2000, Windows XP or Windows Server 2003, but WINS is required for interoperability between Windows 2000 Server– and Windows Server 2003–based domain controllers, computers that are running earlier versions of Windows, and applications that depend on the NetBIOS namespace — for example, applications that call NetServerEnum and other so-called Net* application programming

interfaces (APIs) that depend on NetBIOS. Active Directory domains have both DNS names and NetBIOS names. In general, both names are visible to end users. The DNS names of Active Directory domains include two parts, a prefix and a suffix. The DNS prefix is the first label in the DNS name of the domain. The suffix is the name of the Active Directory forest root domain. For example, the first label of the DNS name for the Child1.wingtiptoys.com domain is Child1 and is referred to as the DNS prefix. The name of the forest root domain in that same forest is wingtiptoys.com and is referred to as the DNS suffix.

Active Directory Domain Names and the Internet Active Directory domain names can exist within the scope of the global Internet DNS namespace. When an Internet presence is required by an individual or organization, the Active Directory namespace is maintained as one or more hierarchical

Windows 2000 domains beneath a root domain that is registered as a DNS namespace. Registration of individual and organizational root domain DNS names ensures the global uniqueness of all DNS names and provides for the assignment of network addresses that are recorded in the global DNS database. Registration of the DNS name for the root domain of the individual or organization also grants that individual or organization the authority to manage its own hierarchy of child domains, zones, and hosts within the root domain. Note

•

An organization might or might not choose to be part of the global Internet DNS namespace. However, even if the root domain of the organization is not registered as an Internet DNS namespace, the DNS service is required to locate Windows 2000–, Windows XP– and Windows Server 2003–based computers in general and Windows 2000 Server– and

Windows Server 2003–based domain controllers in particular. For more information about domain names, see “How DNS Support for Active Directory Works.” Top of page

Active Directory Objects Active Directory objects represent the entities that make up a network. An object is a distinct, named set of attributes that represents something concrete, such as a user, a printer, or an application. When you create an Active Directory object, Active Directory generates values for some of the attributes of the object; others you provide. For example, when you create a user object, Active Directory assigns a globally unique identifier (GUID) and a security identifier (SID), and you provide values for such attributes of the user as the given name, surname, logon identifier, and so on. This section describes the key identifiers assigned to objects by Active Directory and their associated naming schemes

Object Uniqueness Each object in Active Directory is associated with at least one identifier that identifies that object as unique in an enterprise. This object identifier is referred to as a globally unique identifier (GUID). Another identifier, referred to as a security ID (SID), is used on security-enabled objects so that authentication and authorization services can determine its origin and validity within the domain or forest. Active Directory objects that are security-enabled are referred to as security principals. A security principal is an object managed by Active Directory that is automatically assigned a SID for logon authentication and for access to resources. A security principal can be a user account, computer account, or a group, and is unique within a single domain. A security principal object must be authenticated by a domain controller in the domain in which the security principal object is located, and it can be granted or denied access to network resources.

GUIDs Every object in Active Directory has a GUID, a 128-bit number assigned by the Directory System Agent when the object is created. The GUID, which cannot be altered or removed, is stored in an attribute that is required for every object, not just security principal objects. The GUID of each object is stored in its Object-GUID (objectGUID) property. When storing a reference to an Active Directory object in an external store (for example, a Microsoft SQL Server database), the objectGUID value should be used. Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of the properties of an object that is published in the global catalog. Searching the global catalog for the GUID of a User object will yield results if the user has an account somewhere in the enterprise. In fact, searching for any object by Object-GUID might be the most reliable way of finding the object you want to find. This is because the values of other object properties can change, but the Object-GUID never changes. When an object is assigned a GUID, it always keeps that value.

Security IDs (SIDs) When a new security principal is created, Active Directory stores the SID of the security principal in the Object-SID (objectSID) property of the object and assigns the new object a GUID. Each security principal (as well as the domain itself) has a SID, which is the property that authoritatively identifies the object to the Windows security subsystem. The SID of a user, group, or computer is derived from the SID of the domain to which the object belongs; this SID is made up of the value of the domain SID and one additional 32-bit component called the relative identifier (RID). In Windows 2000, Windows XP and Windows Server 2003 operating systems, ACLs are used to identify users and groups by SID, not by GUID — even ACLs on resources in Active Directory. A user gains access to, for example, a Group Policy object, based on one of the SIDs belonging to the user, not based on the GUID for the User object.

SIDs and Migrations When an employee moves to a different location or to a new position, their user account might need to be moved or migrated to a different domain within the organization. Migrating a user account from one domain to another replaces the SID of the account with a new SID and new RID assigned by the new domain. For example, if Nicolette moves from North America to Europe, but stays in the same company, her account can be transferred with her. An administrator with the appropriate credentials can simply move her User object from, say, the Noam.wingtiptoys.com domain to the Euro.wingtiptoys.com domain. When the account is moved, the User object for her account needs a new SID. The domain identifier portion of a SID issued in Noam is unique to Noam, so the SID for her account in Euro has a different domain identifier. The RID portion of a SID is unique relative to the domain, so if the domain changes, the RID also changes. Thus when a User object moves from one domain to another, a new SID must be generated for the user account and stored in the Object-SID property. Before the new value is written to the property, the previous value is copied to another property of a User object, SID History (SIDHistory). This property can hold multiple values. Each time a User object moves to another domain, a new SID is generated and stored in the Object-SID property and another value is added to the list of old SIDs in SIDHistory. When a user logs on and is successfully authenticated, the domain authentication service queries Active Directory for all of the SIDs associated with the user — the current SID of the user, any old SIDs of the user, and the SIDs for the groups to which the user belonged. All of these SIDs are returned to the authentication client and are included in the access token of the user. When the user tries to gain access to a resource, any one of the SIDs in the access token, including one of the SIDs in SIDHistory, can be used to authorize the user to the resource. For more information about SIDHistory, see “How Security Identifiers Work” and “Security Considerations for Trusts.”

Object Names Object names are used to identify accounts in an Active Directory network. Objects have both LDAP-related names and logon names. Each object name represents a unique attribute for that object.

LDAP-Related Names Active Directory is a Lightweight Directory Access Protocol (LDAP)-compliant directory service. In the Windows 2000 Server and Windows Server 2003 operating systems, all access to Active Directory objects occurs through LDAP. LDAP defines what operations can be performed in order to query and modify information in a directory, and how information in a directory can be accessed in compliance with established security requirements. Therefore, you can use LDAP to find or enumerate directory objects and to query or administer Active Directory. It is possible to query by LDAP distinguished name (which is itself an attribute of the object), but because these names are difficult to remember, LDAP also supports querying by other attributes (for example, by using the attribute “color” to find “color” printers). This lets you find an object without having to know the distinguished name. If your organization has several domains, it is possible to use the same user name or computer name in different domains. Like some other types of object names, LDAP-related names can change. The SID, globally unique ID, LDAP distinguished name, and canonical name generated by Active Directory uniquely identify each user, computer, or group in the forest. If the security principal object is renamed or moved to a different domain, the SID, LDAP relative distinguished name, LDAP distinguished name, and canonical name change, but the globally unique ID generated by Active Directory does not change. Top of page

Distinguished Name Objects are located within Active Directory domains according to a hierarchical path, which includes the labels of the Active Directory domain name and each level of container objects. The full path to the object is defined by the distinguished name (also known as a DN). The name of the object itself, separate from the path to the object, is defined by the relative distinguished name. The distinguished name is unambiguous (identifies one object only) and unique (no other object in the directory has this name). By using the full path to an object, including the object name and all parent objects to the root of the domain, the distinguished name uniquely and unambiguously identifies an object within a domain hierarchy. It contains sufficient information for an LDAP client to retrieve information the about the object from the directory. For example, a user named Samantha Smith works in the marketing department of a company as a promotions coordinator. Therefore, her user account is created in an organizational unit that stores the accounts for marketing department employees who are engaged in promotional activities. The user identifier for Samantha Smith is Ssmith, and she works in the North

American branch of the company. The root domain of the company is wingtiptoys.com, and the local domain is noam.wingtiptoys.com. The following distinguished name is of the user object Ssmith in the noam.wingtiptoys.com domain. cn=Ssmith,ou=Promotions,ou=Marketing,dc=noam,dc=wingtiptoys,dc=com Note

•

Active Directory tools do not display the LDAP abbreviations for the naming attributes domain component (dc=), organizational unit (ou=), common name (cn=), and so forth. These abbreviations are shown only to illustrate how LDAP recognizes the portions of the distinguished name. Most Active Directory tools display object names in canonical form, as described later in this section. Because distinguished names are difficult to remember, it is useful to have other means for retrieving objects. Active Directory supports querying by attribute (for example, the building number where you want to find a printer), so an object can be found without having to know the distinguished name. Top of page

Relative Distinguished Name The relative distinguished name of an object is the part of the name that is an attribute of the object itself — the part of the object name that identifies this object as unique from its siblings at its current level in the naming hierarchy. Using the distinguished name mentioned earlier, the relative distinguished name of the object is SSmith. The relative distinguished name of the parent object is Promotions. The maximum length allowed for a relative distinguished name is 255 characters, but attributes have specific limits imposed by the directory schema. For example, in the case of the common name (cn), which is the attribute type often used for naming the relative distinguished name, the maximum number of characters allowed is 64. Active Directory relative distinguished names are unique within a specific parent — that is, Active Directory does not permit two objects with the same relative distinguished name under the same parent container. However, two objects can have identical relative distinguished names but still be unique in the directory because within their respective parent containers, their distinguished names are not the same. (For example, the object cn=SSmith,dc=noam,dc=wingtiptoys,dc=com is recognized by LDAP as being different from cn=SSmith,dc=wingtiptoys,dc=com.) The relative distinguished name for each object is stored in the Active Directory database. Each record contains a reference to the parent of the object. By following the references to the root, the entire distinguished name is constructed during an LDAP operation. Top of page

Canonical Name By default, the user interface in Windows 2000, Windows XP, and Windows Server 2003 displays object names that use the canonical name, which lists the relative distinguished names from the root downward and without RFC 1779 naming attribute descriptors; it uses the DNS domain name (the form of the name where domain labels are separated by periods). For the LDAP distinguished name in the previous example, the respective canonical name would appear as follows: noam.wingtiptoys.com/marketing/promotions/ssmith Note

•

If the name of an organizational unit contains a forward slash character (/), Active Directory requires an escape character in the form of a backslash (\) to distinguish between forward slashes that separate elements of the canonical name and the forward slash that is part of the organizational unit name. The canonical name that appears in Active Directory Users and Computers properties pages displays the escape character immediately preceding the forward slash in the name of the organizational unit. For example, if the name of an organizational unit is Promotions/Northeast and the name of the domain is Wingtiptoys.com, the canonical name is displayed as Wingtiptoys.com/Promotions\/Northeast.

Logon Names A unique logon name is required for user security principals to gain access to a domain and its resources. Security principals are objects to which Windows security is applied in the form of authentication and authorization. Users are security principals, and they are authenticated (their identity is verified) at the time they log on to the domain or local computer. They are authorized (allowed or denied access) when they use resources. In the Windows 2000, Windows XP and Windows Server 2003 operating systems, user security principals require a unique logon name to gain access to a domain and its resources. Security principal objects might be renamed, moved, or contained within a nested domain hierarchy. The names of security principal objects must conform to the following guidelines:

•

The name cannot be identical to any other user, computer, or group name in the domain. It can contain up to 20

•

A user name, computer name, or group name cannot consist solely of periods (.) or spaces.

uppercase or lowercase characters except for the following:" / \ [ ] : ; | = , + * ? <>

The two types of logon names are user principal name and Security Account Manager account names.

User Principal Name In Active Directory, each user account has a user principal name (UPN) in the format user@DNS-domain-name. A UPN is a friendly name assigned by an administrator that is shorter than the LDAP distinguished name used by the system and easier to remember. The UPN is independent of the DN of the user object, so a user object can be moved or renamed without affecting the user logon name. When logging on using a UPN, users do not have to choose a domain from a list on the logon dialog box. The three parts of a UPN are the UPN prefix (user logon name), the @ character, and the UPN suffix (usually a domain name). The default UPN suffix for a user account is the DNS name of the Active Directory domain where the user account is located. For example, the UPN for user Frank Miller, who has a user account in the Wingtiptoys.com domain (if Wingtiptoys.com is the only domain in the tree), is [email protected]. The UPN is an attribute (userPrincipalName) of the security principal object. If the userPrincipalName attribute of a User object has no value, the User object has a default UPN of userName@DnsDomainName. If your organization has many domains forming a deep domain tree organized by department and region, default UPN names can become unwieldy. For example, the default UPN for a user might be Sales.westcoast.microsoft.com. The logon name for a user in that domain is [email protected]. Instead of accepting the default DNS domain name as the UPN suffix, you can simplify both administration and user logon processes by providing a single UPN suffix for all users. (The UPN suffix is used only within the Active Directory domain and is not required to be a valid DNS domain name.) You can choose to use your e-mail domain name as the UPN suffix — [email protected]. This gives the user in the example the UPN name of [email protected]. For a UPN–based logon, a global catalog might be necessary, depending on the user logging on and the domain membership of the computer where the user logs on. A global catalog is needed if the user logs on with a non-default UPN and the computer account of the user is in a different domain than the user account of the user. For example, if, instead of accepting the default DNS domain name as the UPN suffix (in the example [email protected]), you provide a single UPN suffix for all users (so that the user then becomes simply [email protected]), a global catalog is required for logon. You use the Active Directory Domains and Trusts tool to manage UPN suffixes for a domain. UPNs are assigned at the time a user is created. If you have created additional suffixes for the domain, you can select from the list of available suffixes when you create the user or group account. The suffixes appear in the list in the following order:

•

Alternate suffixes (if any; last one created appears

• •

Root domain

first) The current domain

SAM Account Name A Security Accounts Manager (SAM) account name is required for compatibility with Windows NT 3.x and Windows NT 4.0 domains. The user interface in Windows 2000, Windows XP, and Windows Server 2003 refers to the SAM account name as User logon name (pre-Windows 2000). SAM account names are sometimes referred to as flat names because — unlike DNS names — SAM account names do not use hierarchical naming. Because SAM names are flat, each one must be unique in the domain.

Organizational Units Active Directory allows administrators to create a hierarchy within a domain that meets the needs of their organization. The object class of choice for building these hierarchies is the organizationalUnit, a general-purpose container that can be used to group most other object classes together for administrative purposes. An organizational unit in Active Directory is analogous to a directory in the file system; it is a container that can hold other objects. You can use organizational units for purposes such as creating an administrative hierarchy, applying Group Policy, and delegating control of administration.

Administrative Hierarchy Organizational units can be nested to create a hierarchy within a domain and form logical administrative units for users, groups, and resource objects, such as printers, computers, applications, and file shares. The organizational unit hierarchy within a domain is independent of the structure of other domains; each domain can implement its own hierarchy. Likewise,

domains that are managed by a central authority can implement similar organizational unit hierarchies. The structure is completely flexible, which allows organizations to create an environment that mirrors the administrative model, whether it is centralized or decentralized.

Group Policy Group Policy can be applied to organizational units to define the abilities of groups of computers and users that are contained within the organizational units. Levels of control range from complete desktop lockdown to a relatively autonomous user experience. Group Policy can affect functionality, such as what applications are available to a group of users, what features within an application are accessible on a particular computer, where documents are saved, and can affect access and user permissions. Group Policy also affects where, when, and how application and operating system updates or special scripts are applied. Group Policy settings are stored as Group Policy objects in Active Directory. A Group Policy object can be associated with one or more Active Directory containers, such as a site, domain, or organizational unit.

Delegation of Control The Active Directory object-based security model implements default access control that is propagated down a subtree of container objects. You can use this technology to determine the security for an entire group of objects according to the security that you set on the organizational unit that contains the objects. By default, most Active Directory objects inherit ACEs from the security descriptor on their parent container object. If necessary, you can change the inherited permissions. However, as a best practice, you should avoid changing the default permissions or inheritance settings on Active Directory objects unless you have additional security requirements. Note

•

Because Active Directory is indexed, you can organize the tree to match your administrative model, instead of having to

organize it for ease of browsing. Inheritance enables the access control information defined at a container object in Active Directory to apply to the security descriptors of any subordinate objects, including other containers and their objects. One benefit this provides is that it eliminates the need to apply permissions each time a child object is created. You can apply or delegate administrative control over directory objects to organizational units by setting access control. This inheritance of access effectively delegates administrative control to individuals in the organization. The best way to take full advantage of delegation and inherited control on directory objects is to organize the hierarchy to match the way that the directory is administered.

User Accounts and Access Control Active Directory authenticates and authorizes security principals such as user, inetorgperson, and computer accounts to access shared resources on the network. The Local Security Authority (LSA) is the security subsystem responsible for all interactive user authentication and authorization services on a local computer. The LSA also processes authentication requests made through the Kerberos V5 protocol or the NTLM protocol in Active Directory. Once the identity of a user is verified in Active Directory, the LSA on the authenticating domain controller creates a security access token for that user. An access token contains the name of the user, the groups to which that user belongs, a SID for the user, SIDs included in the SIDHistory property and all of the SIDs for the groups to which the user belongs. The information in the access token is used to determine the level of access a user has to resources whenever the user attempts to access them. The SIDs in the access token are compared with the list of SIDs that make up the discretionary access control list (DACL) on the resource to ensure that the user has sufficient permission to access the resource. This is because the access control process identifies user accounts by SID rather than by name. Note

•

When a domain controller provides an access token to a user, the access token only contains information about membership in domain local groups if the domain local groups are local to the domain where the domain controller is located.

User Authorization In addition to securing network access through user authentication, Active Directory protects shared resources by facilitating user authorization. Once a user logon has been authenticated by Active Directory, the user rights assigned to the user

through security groups and the permissions assigned on the shared resource determine if the user will be authorized to access that resource. This authorization process protects shared resources from unauthorized access and permits access to only authorized users or groups. Administrators can use access control to manage user access to shared resources for security purposes. In Active Directory, access control is administered at the object level by setting different levels of access, or permissions, to objects, such as Full Control, Write, Read, Delete, or No Access. Access control in Active Directory defines how users can use Active Directory objects. By default, most permissions on objects in Windows Server 2003 Active Directory are at the most secure setting. The elements that define access control permissions on Active Directory objects include security descriptors and the concept of object inheritance.

Security Descriptors Access control permissions are assigned to securable objects and Active Directory objects to control how different users can use each object. A securable object, or shared resource, is an object that is intended to be used over a network by one or more users, and includes files, printers, folders, and services. All securable objects and Active Directory objects store access control permissions in security descriptors. A security descriptor contains two access control lists (ACLs) used to assign and track security information for each object: these are the discretionary access control list (DACL) and the system access control list (SACL). Discretionary access control lists (DACLs). DACLs identify the users and groups that are assigned or denied access permissions on an object. If a DACL does not explicitly allow access to a user, or to any group that a user is a member of, the user is implicitly denied access to that object. By default, a DACL is controlled by the owner of an object or the person who created the object (In Windows, the creator of an object is also the owner). The DACL contains access control entries (ACEs) that determine user access to the object. System access control lists (SACLs). SACLs identify the users and groups that you want to audit when they successfully access or fail to access an object. Auditing is used to monitor events related to system or network security, to identify security breaches, and to determine the extent and location of any damage. By default, a SACL is controlled by the owner of an object or the person who created the object. A SACL contains ACEs that determine whether to record a successful or failed attempt by a user to access an object using a given permission, for example, Full Control or Read. Active Directory allows you to apply access control permissions to objects at very low levels, including the ability to assign permissions on a per-attribute basis. To view DACLs and SACLs on Active Directory objects using Active Directory Users and Computers, on the View menu, click Advanced Features to access the Security tab for each object. You can also use the DSACLS support tool to manage access control lists in Active Directory. By default, DACLs and SACLs are associated with every Active Directory object, which helps reduce attacks to your network by malicious users or any accidental mistakes made by domain users.

Computer Accounts Each computer account created in Active Directory has a relative distinguished name, a pre-Windows 2000 computer name (Security Accounts Manager account name), a primary DNS suffix, a DNS host name, and a service principal name (SPN). The administrator enters the computer name when creating the computer account. This computer name is used as the LDAP relative distinguished name. Active Directory suggests the pre-Windows 2000 name using the first 15 bytes of the relative distinguished name. The administrator can change the pre-Windows 2000 name at any time. The DNS name for a host is called a full computer name and is a DNS fully qualified domain name (FQDN). The full computer name is a concatenation of the computer name (the first 15 bytes of the SAM account name of the computer account without the $ character) and the primary DNS suffix (the DNS domain name of the domain in which the computer account exists). It is listed on the Computer Name tab in System Properties in Control Panel. By default, the primary DNS suffix portion of the FQDN for a computer must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator might create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces (ADSI) or LDAP. The SPN is a multivalue attribute. It is usually built from the DNS name of the host. The SPN is used in the process of mutual authentication between the client and the server hosting a particular service. The client finds a computer account based on the SPN of the service to which it is trying to connect. The SPN can be modified by members of the Domain Admins group.

Top of page

Domain and Forest Protocols and Programming Interfaces The primary protocol that is used by domain controllers in every domain throughout the forest is LDAP, which runs on top of TCP/IP. LDAP is both a protocol and an API. In addition, the secured communications between domain controllers must use the remote procedure call (RPC) protocol for Messaging Application Programming Interface (MAPI), replication, domain controller management, and SAM-related operations.

LDAP LDAP is a directory service protocol that specifies directory communications. It runs directly over TCP/IP, and it can also run over User Datagram Protocol (UDP) connectionless transports. Clients can use LDAP to query, create, update, and delete information that is stored in a directory service over a TCP connection through the TCP default port 389. Active Directory supports LDAP v2 (RFC 1777) and LDAP v3 (RFC 3377). LDAP v3 is an industry standard that can be used with any directory service that implements the LDAP protocol. LDAP is the preferred and most common way of interacting with Active Directory. Historically, LDAP is a simplified (lightweight) version of Directory Access Protocol (DAP), which is the original protocol that was used to interact with X.500 directories. X.500 defines an earlier set of standards that was developed by the International Organization for Standardization (ISO). LDAP is simpler than DAP in two key ways:

•

Rather than using its own protocol stack according to the Open Systems Interconnection (OSI) networking model, LDAP

•

LDAP syntax is easier to use than DAP syntax.

communicates over Internet Protocol (IP) by using either UDP or TCP.

For these reasons, LDAP is widely used and accepted as the standard protocol for directory service access. The following key aspects characterize LDAP:

•

The protocol is carried directly over TCP for connection-oriented transport (receipt of data is acknowledged) and over UDP

• • •

Most protocol data elements can be encoded as ordinary strings, for example, as distinguished names.

• • •

Attribute values and distinguished names can be internationalized using the ISO 10646 character set.

for connectionless transport (sent or received data is not acknowledged). Referrals to other servers can be returned to the client. Simple Authentication and Security Layer (SASL) mechanisms can be used with LDAP to provide associated security services. SASL Digest is supported in Windows Server 2003 as the authentication standard for LDAP. The protocol can be extended to support new operations, and controls can be used to extend existing operations. The schema is published through an attribute on the directory root object (rootDSE) for use by clients.

For more information about LDAP, see “How Active Directory Searches Work.”

RPC Active Directory uses remote procedure call (RPC) for replication (REPL) and domain controller management communications, MAPI communications, and SAM-related communications. RPC is a powerful, robust, efficient, and secure interprocess communication (IPC) mechanism that enables data exchange and invocation of functionality located in a different process. That different process can be on the same computer, on the local area network (LAN), or across the Internet.

Authentication Protocols Domain controllers authenticate users and applications by using one of two protocols: either the Kerberos version 5 authentication protocol or the NTLM authentication protocol. When two Active Directory domains or forests are connected by a trust, authentication requests made using these protocols can be routed to provide access to resources in both forests.

NTLM The NTLM protocol is the default protocol used for network authentication in the Windows NT 4.0 operating system. For compatibility reasons, it is used by Active Directory domains to process network authentication requests that come from earlier Windows-based clients and servers. Computers running Windows 2000, Windows XP or Windows Server 2003 use NTLM only when authenticating to servers running Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains.

When the NTLM protocol is used between a client and a server, the server must contact a domain authentication service on a domain controller to verify the client credentials. The server authenticates the client by forwarding the client credentials to a domain controller in the client account domain.

Kerberos Version 5 Protocol The Kerberos version 5 protocol is the default authentication protocol used by computers running Windows 2000, Windows XP Professional, or Windows Server 2003. This protocol is specified in RFC 1510 and is fully integrated with Active Directory, server message block (SMB), HTTP, and RPC, as well as the client and server applications that use these protocols. In Active Directory domains, the Kerberos protocol is used to authenticate logons when any of the following conditions is true:

• • • • •

The user who is logging on uses a security account in an Active Directory domain. The computer that is being logged on to is a Windows 2000, Windows XP or Windows Server 2003–based computer. The computer that is being logged on to is joined to an Active Directory domain. The computer account and the user account are in the same forest. The computer from which the user is trying to access resources is located in a non-Windows-based operating system

Kerberos version 5 realm. If any computer involved in a transaction does not support the Kerberos version 5 protocol, the NTLM protocol is used. The authentication protocol of choice for Active Directory authentication requests is Kerberos V5. In contrast to NTLM, when the Kerberos protocol is used, the server does not have to contact the domain controller. Instead, the client gets a ticket for a server by requesting one from a domain controller in the server account domain; the server validates the ticket without consulting any other authority. For more information about Kerberos, see “How the Kerberos Version 5 Authentication Protocol Works.”

Active Directory APIs You can use the following application programming interfaces (APIs) to access information in any LDAP directory including Active Directory:

•

Active Directory Service Interface

• • • •

LDAP C API

(ADSI) REPL MAPI SAM

ADSI Active Directory Service Interfaces (ADSI) provides a simple, powerful, object-oriented interface to Active Directory. ADSI makes it easy for programmers and administrators to create directory programs by using high-level tools, such as Microsoft Visual Basic, without having to worry about the underlying differences between the different namespaces. ADSI is supplied as a software development kit that enables you to build or buy programs that give you a single point of access to multiple directories in your network environment, whether those directories are based on LDAP or another protocol. ADSI is fully scriptable for ease of use by administrators. ADSI also enables access to Active Directory by exposing objects stored in the directory as Component Object Model (COM) objects. A directory object is manipulated using the methods available on one or more COM interfaces. ADSI has a providerbased architecture that allows COM access to different types of directories for which a provider exists.

LDAP C The LDAP C API, defined in Internet standard RFC 1823, is a set of low-level C-language APIs to the LDAP protocol. Microsoft supports LDAP C APIs on all Windows platforms. Developers have the choice of writing Active Directory-enabled applications using LDAP C APIs or ADSI. LDAP C APIs are most often used to ease portability of directory-enabled applications to the Windows platform. ADSI is a more powerful language and is more appropriate for developers writing directory-enabled code on the Windows platform.

LDAP is the primary interface for the data store. Directory clients use LDAP v3 to connect to the DSA through the LDAP interface. The LDAP interface is part of Wldap32.dll. LDAP v3 is backward compatible with LDAP v2.

REPL The REPL management interface provides functionality for finding data about domain controllers, converting the names of network objects between different formats, manipulating SPNs and DSAs, and managing replication of servers.

MAPI Messaging clients gain access to the Microsoft Exchange Server directory service by using MAPI address book providers. For compatibility with existing messaging clients, Active Directory supports the MAPI-RPC address book provider, which provides access to Active Directory, for example, to find the telephone number of a user.

SAM Security Accounts Manager (SAM) is a proprietary interface for connecting to the DSA on behalf of clients that use Windows NT 4.0 or earlier. These clients use Windows NT 4.0 networking APIs to connect to the DSA through SAM. Replication with Windows NT 4.0 backup domain controllers (BDCs) goes through the SAM interface as well. Top of page

Domain and Forest Processes and Interactions Many network related operations depend on domains and forests in order to complete various tasks. This section describes some of the processes and interactions that commonly occur within the boundaries of domains or forests.

Logging on to a Domain When a user with an account in an Active Directory domain logs on at the keyboard of a computer running Windows 2000, Windows XP or Windows Server 2003, the logon request is processed in three stages: 1.

The user requests admission to the ticket-granting service for the domain. This is accomplished through an Authentication Service (AS) Exchange between the Kerberos security support provider (SSP) on the computer and the Key Distribution Center (KDC) in the domain in which the user account exists. The result

2.

is a ticket-granting ticket (TGT) that the user can present in future transactions with this KDC. The user requests a ticket for the computer. This is accomplished through a Ticket-Granting Service (TGS) Exchange between the Kerberos SSP on the computer and the KDC for the domain in which the computer account exists. The result is a session ticket that the user can present

3.

when he or she requests access to system services on the computer. The user requests admission to Local System services on the computer.

This is accomplished when the Kerberos SSP on the computer presents a session ticket to the LSA on the computer. If the account domain of the computer is different from the account domain of the user, an extra step is involved. Before the Kerberos SSP can request a session ticket for the computer, it must ask the KDC in the domain where the user account exists for a TGT that is good for admission to the KDC in the domain where the computer account exists. The SSP can then present the TGT to the KDC in the domain of the computer and get a session ticket for the computer. The precise steps in the logon process depend on how the computer is configured. With standard configurations of Windows, interactive users log on with a password. In another optional configuration of Windows, users log on with a smart card. Although the basic process is the same for both configurations, there are some differences. For more information about the domain logon process, see “How Interactive Logon Works.”

Processing Authentications Across Domains and Forests When a request for authentication is referred to a domain, before the domain controller in that domain authenticates the user to access resources in the domain, it must determine whether a trust relationship exists with the domain from which the request comes, as well as the direction of the trust and whether the trust is transitive or nontransitive. The authentication process between trusted domains varies according to the authentication protocol in use. The Kerberos version 5 and NTLM protocols in Windows 2000 Server and Windows Server 2003 process referrals for authentication to a domain differently, as do other authentication protocols, such as Digest and SChannel, that Windows 2000 Server and Windows Server 2003 support. In an Active Directory environment the Kerberos-based authentication process is most commonly used. To access a shared resource in another domain by using Kerberos authentication, a computer where the user logs on first requests a ticket from

a domain controller in its account domain to the server in the trusting domain that hosts the requested resource. This ticket is then issued by an intermediary trusted by both the requesting computer and the server. The computer then presents this trusted ticket to the server in the trusting domain for authentication. This process, however, becomes more complex when a workstation in one forest attempts to access data on a resource computer in another forest. In this case, the Kerberos authentication process contacts the domain controller for a service ticket to the SPN of the resource computer. Once the domain controller queries the global catalog and determines that the SPN is not in the same forest as the domain controller, the domain controller sends a referral for its parent domain back to the workstation. At that point, the workstation queries the parent domain for the service ticket and continues to follow the referral chain until it reaches the domain where the resource is located. For more detailed information about how authentication requests are processed across domains and forests, see “How Domain and Forest Trusts Work.”

Joining a Computer to a Domain Joining a computer to a domain creates the computer account object for the client in an Active Directory location where all computer accounts are created by default during a join operation. The default location is set to the Computers container in Active Directory. A computer account differs from a user account in that it identifies the computer to the domain, while a user account identifies a user to a computer. The act of joining a computer to a domain creates an account for the computer on the domain if it does not already exist. When you join a client computer running Windows NT 4.0, Windows 2000, Windows XP or Windows Server 2003 to an Active Directory domain, the following events occur:

• • • • • •

The domain name is validated. A domain controller in the domain is located through a call to the DsGetDcName API. A session is established with the domain controller under the security context of the passed-in credentials that are supplied in the Network Identification tab under System Properties in Control Panel. The computer account is enabled. If the flags so specify (NETSETUP_ACCT_CREATE), the APIs create the computer account on the domain controller. The local password for this account is created in the Local Security Authority (LSA). The local primary domain information LSA policy is set to refer to the new domain. This includes the domain name and the domain SID. Note

•

For clients running Windows 2000, Windows XP and Windows Server 2003 only, the LSA policy consists of the domain name, domain SID, DNS domain name, DNS forest name, and domain GUID.

• •

The DNS name assigned to the local computer is updated.

• •

The Net Logon trusted domain cache is initialized to the trusted domains domain list.

•

The Net Logon service is started.

The local group membership is changed to add members of the Domain Admins group to the Local Accounts Administrators group. For clients running Windows 2000, Windows XP and Windows Server 2003 only, the Windows Time Service is enabled and started.

To join a workstation or member server to a domain, you can use the Netdom tool. For example, to join a workstation to the Wingtiptoys.com domain in the engineering organizational unit, type the following command at the workstation: Netdom join /d:wingtiptoys.com /OU:OU=engineering,DC=wingtiptoys,DC=com When a computer joins a domain, the following changes occur on domain controllers running Windows NT 4.0, Windows 2000 Server and Windows Server 2003:

• •

A computer object is created. The name of this object is generated by appending a dollar sign ($) to the name (uppercase letters) of the client. On Windows 2000 Server– and Windows Server 2003–based domain controllers only, the Net Logon service creates SPNs on the computer object.

Netsetup.log When joining a computer to an Active Directory domain, the Networking Setup (NetSetup) utility installs all the necessary Microsoft supported networking components. The Netsetup.log file provides information about attempts to join domains and records any errors that might prevent the join operation from succeeding.

Registering DNS Names and Locating Domain Controllers When a Windows 2000 Server–based server or Windows Server 2003–based member server is promoted to a domain controller by installing Active Directory, the Net Logon service registers the DNS resource records necessary for network hosts and services to locate the domain controller on the network. When network hosts and services attempt an operation (such as joining a domain) that requires a domain controller, the locator mechanism attempts to locate the domain controller through DNS. DNS is used because every Active Directory–based domain controller dynamically registers SRV records in DNS. The SRV records enable servers to be located by service type (for example, LDAP) and protocol (for example, TCP). Because domain controllers are LDAP servers that communicate over TCP, SRV records can be used to find the DNS computer names of domain controllers. In addition to registering LDAP-specific SRV records, Net Logon also registers Kerberos v5 authentication protocol–specific SRV records to enable locating servers that run the Kerberos Key Distribution Center (KDC) service. Domain controllers not only register their DNS domain names on a DNS server, but also register their NetBIOS names by using a transport-specific mechanism (for example, WINS). Thus, a DNS client locates a domain controller by querying DNS, and a NetBIOS client locates a domain controller by querying the appropriate transport-specific name service. The domain controller locator service consists of two main parts:

• •

Locator finds which domain controllers are registered with a DNS server. Locator submits a DNS query to the DNS server to locate a domain controller in the specified

domain. After this query is resolved, an LDAP User Datagram Protocol (UDP) lookup is sent to one or more of the domain controllers listed in the response to the DNS query to ensure their availability. Finally, the Net Logon service caches the discovered domain controller to aid in resolving future requests. For more information about the DC Locator process, see “How DNS Support for Active Directory Works.”

Raising Domain and Forest Functional Levels When Active Directory is installed on a server running Windows Server 2003, a set of basic Active Directory features is enabled by default. In addition to the basic Active Directory features on individual domain controllers, there are new domainand forest-wide Active Directory features available when all domain controllers in a domain or forest are running Windows Server 2003. To enable the new domain-wide features, all domain controllers in the domain must be running Windows Server 2003, and the domain functional level must be raised to Windows Server 2003. To enable new forest-wide features, all domain controllers in the forest must be running Windows Server 2003, and the forest functional level must be raised to Windows Server 2003. Before raising the forest functional level to Windows Server 2003, verify that all domains in the forest are set to the domain functional level of Windows 2000 native or Windows Server 2003. Note that domains that are set to the domain functional level of Windows 2000 native will automatically be raised to Windows Server 2003 at the same time the forest functional level is raised to Windows Server 2003. For more detailed information about functional levels, see the “How Active Directory Functional Levels Work.”

Replicating Directory Partitions Active Directory uses RPC over IP to transfer replication data between domain controllers. RPC over IP is used for both intersite and intrasite replication. To keep data secure while in transit, RPC over IP replication uses both authentication (using the Kerberos V5 authentication protocol) and data encryption. When a direct or reliable IP connection is not available, replication between sites can be configured to use the Simple Mail Transfer Protocol (SMTP). However, SMTP replication functionality is limited, and requires an enterprise certification authority (CA). SMTP can only be used to replicate the configuration, schema and application directory partitions, and does not support the replication of domain directory partitions. For more detailed information about the replication process, see “How Active Directory Replication Topology Works.” Top of page

Network Ports Used by Domains and Forests The following tables list the network ports that are associated with domains and forests. Port Assignments for Raising Active Directory Functional Levels

Service Name UDP TCP LDAP

389

389

LDAP SSL

N/A

636

Port Assignments for Data Store

Service Name

UDP TCP

LDAP

389

389

LDAP SSL

N/A

636

RPC Endpoint Mapper

135

135

Global Catalog LDAP

N/A

3268

Global Catalog LDAP SSL N/A

3269

Port Assignments for Service Publication and SPNs

Service Name

UDP TCP

LDAP

389

389

LDAP SSL

N/A

636

RPC Endpoint Mapper

135

135

Global Catalog LDAP

N/A

3268

Global Catalog LDAP SSL N/A

3269

Kerberos

88

88

Port Assignments for Raising Active Directory Searches

Service Name

UDP TCP

LDAP

389

389

LDAP SSL

N/A

636

Global Catalog LDAP

N/A

3268

Global Catalog LDAP SSL N/A

3269

Port Assignments for Global Catalogs

Service Name UDP TCP LDAP

N/A

3268

LDAP

N/A

3269 (global catalog Secure Sockets Layer [SSL])

LDAP

389

389

LDAP

N/A

686 (SSL)

RPC/REPL

135

135 (endpoint mapper)

Kerberos

88

88

DNS

53

53

SMB over IP

445

445

Port Assignments for Replication

Service Name UDP TCP LDAP

389

389

LDAP

N/A

686 (SSL)

RPC/REPL

N/A

135 (endpoint mapper)

LDAP

N/A

3268

Kerberos

88

88

DNS

53

53

SMB over IP

445

445

Port Assignments for Operations Masters

Service Name UDP TCP LDAP

389

389

LDAP

N/A

686 (SSL)

RPC/REPL

N/A

135 (endpoint mapper)

Netlogon

N/A

137

Kerberos

88

88

DNS

53

53

SMB over IP

445

445

Port Assignments for Interactive Logon

Service Name

UDP

TCP

Kerberos

88

88

Local Security Authority (LSA) RPC Dynmaic RPC Dynamic RPC NTLM

Dynamic

Dynamic

Port Assignments for Kerberos V5 Protocol

Service Name UDP TCP DNS

53

53

Kerberos

88

88

Port Assignment for DC Locator

Service Name UDP TCP LDAP

389

389

The following table shows the list of ports that might need to be opened before you establish trusts. Ports Required for Trusts

Task

Outbound Ports

Set up trusts on both sides from the

LDAP (389 UDP and TCP)

internal forest

Microsoft SMB (445 TCP)

controllers–External domain

Kerberos (88 UDP)

domain controllers (all ports)

Endpoint resolution —

Inbound Ports N/A

From–To Internal domain domain

Task

Outbound Ports

Inbound Ports

From–To

portmapper (135 TCP) Net Logon fixed port Trust validation from the internal forest LDAP (389 UDP)

N/A

Internal domain domain

domain controller to the external forest Microsoft SMB (445 TCP)

controllers–External domain

domain controller (outgoing trust only) Endpoint resolution —

domain controllers (all ports)

portmapper (135 TCP) Net Logon fixed port Use Object picker on the external forest N/A

LDAP (389 UDP and TCP) External server–Internal

to add objects that are in an internal

Windows NT Server 4.0

forest to groups and DACLs

directory service fixed port External domain domain

domain PDCs (Kerberos)

Net Logon fixed port

controllers–Internal domain

Kerberos (88 UDP)

domain controllers (Net Logon)

Endpoint resolution portmapper (135 TCP) Set up trust on the external forest from N/A

LDAP (389 UDP and TCP) External domain domain

the external forest

Microsoft SMB (445 TCP)

controllers–Internal domain

Kerberos (88 UDP)

domain controllers (all ports)

Use Kerberos authentication (internal

Kerberos (88 UDP)

N/A

forest client to external forest) Use NTLM authentication (internal

domain controllers (all ports) N/A

forest client to external forest)

Endpoint resolution –

LDAP (389 UDP and TCP)

N/A

internal network to an external domain Microsoft SMB (445 TCP) Kerberos (88 UDP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port Windows NT Server 4.0 directory service fixed port Top of page

Related Information The following resources contain additional information that is relevant to this section.

• • • • • • • •

Active Directory Schema Technical Reference

•

Windows Support Tools

Data Store Technical Reference DNS Support for Active Directory Technical Reference Active Directory Replication Model Technical Reference Logon and Authentication Technologies Domain Controller Roles Active Directory Search and Publication Technologies Active Directory Installation, Upgrade, and Migration Technologies

Domains and Forests Tools and Settings Updated: March 28, 2003

In this section

External domain domain

portmapper (135 TCP) Net controllers–Internal domain Logon fixed port

Join a domain from a computer in the

Internal client–External domain

domain controllers (all ports) Internal client–External domain domain controllers (all ports)

• • • • •

Tools for Managing Domains and Forests

•

Related Information

Domains and Forests Registry Entries Domains and Forests Group Policy Settings Domains and Forests WMI Classes Network Ports Used by Domains and Forests

Administrators can use a number of methods to configure and manage Active Directory domain and forest environments. This section contains information about the tools, registry entries, Group Policy settings, Windows Management Instrumentation (WMI) classes, and network ports that are associated with Active Directory domains and forests. Note

•

When using Windows Server 2003 Active Directory administrative tools to connect to a domain controller running Windows 2000 you must first make sure that the Windows 2000–based domain controller to which you are connecting has Service Pack 3 or later installed. This is because Windows Server 2003 administrative tools sign and encrypt all LDAP traffic by default. If business reasons do not permit the installation of Service Pack 3 or later on domain controllers running Windows 2000 it is possible to disable this default behavior.

Tools for Managing Domains and Forests The following tools are associated with domains and forests.

Adsiedit.exe: ADSI Edit Category ADSI Edit is included when you install Windows Server 2003 Support Tools.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional ADSI Edit is a Microsoft Management Console (MMC) tool that uses Active Directory Service Interfaces (ADSI), which ultimately uses the LDAP protocol. This tool can be used to view and modify directory objects in the Active Directory database. To find more information about ADSI Edit, see “Adsiedit Overview.”

Csvde.exe: Csvde Category Csvde is a command-line tool that ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

•

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Csvde to import and export data from Active Directory by using files that store data in the comma-separated value (CSV) file format. Csvde also supports batch operations that are based on CSV. To find more information about Csvde, see Command-Line References in the “Tools and Settings Collection.”

Dcdiag.exe: Domain Controller Diagnostic Tool Category The Domain Controller Diagnostic Tool command-line tool (Dcdiag) is included when you install the Windows Server 2003 Support Tools.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition •

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

Can Be Run From

Can Be Run Against

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional with Adminpak.msi installed You can use the Domain Controller Diagnostic Tool to verify external trusts. This tool cannot be used to verify trust relationships based on the Kerberos version 5 authentication protocol; to verify Kerberos V5-based trust relationships, the recommended method is to use the Netdom tool. Using the Domain Controller Diagnostic Tool you can scope your external trust verification by site or by domain controller, check for trust establishment, check secured channel setup, and check for ticket validity between each pair of domain controllers. By default, errors are flagged. In verbose mode, successes are printed as well. You can use the Domain Controller Diagnostic Tool to verify that there are sufficient resources for the DNS infrastructure when deploying the Windows 2000 Server or Windows Server 2003 Active Directory directory service. This tool analyzes the state of domain controllers in a forest or enterprise and reports any problems to assist in troubleshooting. As an end-user reporting program, the Domain Controller Diagnostic Tool queries the directory service infrastructure and uses the results to identify abnormal behavior in the system. The Domain Controller Diagnostic Tool provides a framework for executing tests to verify different functional areas of the system. This framework selects which domain controllers are tested according to scope directives from the user, such as enterprise, site, or single server.

Dcpol.msc: Domain Controller Security Policy Category Domain Controller Security Policy is a snap-in for MMC and is automatically installed when you install Active Directory. You can also use Domain Controller Security Policy on computers not running Active Directory by installing the Administration Tools Pack (Adminpak.msi).

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can set security settings for a domain controller in Domain Controller Security Policy. For more information about Domain Controller Security Policy, see Help and Support Center in Windows Server 2003.

Dcpromo.exe: Active Directory Installation Wizard Category An Active Directory wizard that is included with Windows Server 2003 and is available from the command line or from the Configure Your Server Wizard on any computer running Windows Server 2003.

Version compatibility This tool is compatible with computers running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition. The Active Directory Installation Wizard provides a graphical user interface for setting up a domain controller by installing Active Directory and, optionally, DNS. The Active Directory Installation Wizard can also be used on a Windows NT 4.0 primary domain controller (PDC) when upgrading it to Windows Server 2003 and forming a new forest, to raise the forest functional level to Windows Server 2003 interim, if appropriate.

Domain.msc: Active Directory Domains and Trusts Category An Active Directory Administrative Tools MMC snap-in that is automatically installed on all domain controllers running Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional with Adminpak.msi installed Note

•

You cannot run the Windows Server 2003 Administration Tools Pack (Adminpak.msi) on a computer that is running Windows XP Professional, Windows XP Home Edition, or Windows XP 64-Bit Edition Version 2003 without Windows XP

Service Pack 1 (SP1). Active Directory Domains and Trusts provides a graphical interface in which you can view all domains in the forest. Using this tool, an administrator can manage each of the domains in the forest, trust relationships between domains, configure the functional level for each domain or forest, and configure the alternative user principal name (UPN) suffixes for a forest. Active Directory Domains and Trusts can be used to accomplish most trust related tasks. It can be used to target all Active Directory domain controllers and can verify all Active Directory trust types. Trust verification takes place between two domains by enumerating all of the domain controllers in each domain. If you choose to have Active Directory Domains and Trusts create both sides of the trust at once, the trust password is automatically generated.

For more information about Active Directory Domains and Trusts, see Help in Active Directory Domains and Trusts.

Dompol.msc: Domain Security Policy Category Domain Security Policy is a snap-in for MMC and is automatically installed when you install Active Directory. You can also use Domain Controller Security Policy on computers not running Active Directory by installing the Administration Tools Pack (Adminpak.msi).

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

•

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional Security settings for a domain are set in Domain Security Policy. Group Policy settings can be applied to lock-down which users are allowed to log on to the server as well as who can access the server from the network. For more information about Domain Security Policy, see Help and Support Center in Windows Server 2003.

Dsa.msc: Active Directory Users and Computers Category An Active Directory Administrative Tools MMC snap-in that is automatically installed on all Windows Server 2003 domain controllers running Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows 2000 Server

Can Be Run From

Can Be Run Against

• Windows Server 2003, Standard Edition

• Windows 2000 Advanced Server

• Windows Server 2003, Enterprise Edition

• Windows 2000 Datacenter Server

• Windows Server 2003, Datacenter Edition • Windows Server 2003, Web Edition Computers running:

• Windows XP Professional with Adminpak.msi installed Active Directory Users and Computers provides a graphical user interface that can be used to manage users and computers in Active Directory domains. Additionally, LDAP Query can be used in this tool for the following:

•

To identify domain controllers running

•

To connect to a domain

Windows NT 4.0

Dsadd.exe: Dsadd Category Dsadd is a command-line tool that ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsadd to add specific types of objects to the directory. To find more information about Dsadd, see Command-Line References in the “Tools and Settings Collection.”

Dsget.exe: Dsget Category Dsget is a command-line tool that ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

•

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsget to display the selected properties of a specific object in the directory.

•

To find more information about Dsget, see Command-Line References in the “Tools and Settings Collection.”

Dsmod.exe: Dsmod Category Dsmod is a command-line tool that ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

•

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsmod to modify an existing object of a specific type in the directory. To find more information about Dsmod, see Command-Line References in the “Tools and Settings Collection.”

Dsmove.exe: Dsmove Category Dsmove is a command-line tool that ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

•

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsmove to move a single object in a domain from its current location in the directory to a new location. You can also use Dsmove to rename a single object without moving it in the directory tree. To find more information about Dsmove, see Command-Line References in the “Tools and Settings Collection.”

Dsquery.exe: Dsquery Category Dsquery is a command-line tool that ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

Can Be Run From

Can Be Run Against

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsquery to perform searches against Active Directory according to specified criteria. To find more information about Dsquery, see Command-Line References in the “Tools and Settings Collection.”

Dsrm.exe: Dsrm Category Dsrm is a command-line tool that ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsrm to delete an object of a specific type, or any general object, from the directory. To find more information about Dsrm, see Command-Line References in the “Tools and Settings Collection.”

Dssite.msc: Active Directory Sites and Services Category An Active Directory Administrative Tools MMC snap-in that is automatically installed on all Windows Server 2003 domain controllers running Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

Can Be Run From

Can Be Run Against

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows 2000 Server

• Windows Server 2003, Standard Edition

• Windows 2000 Advanced Server

• Windows Server 2003, Enterprise Edition •

• Windows 2000 Datacenter Server

Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional with Adminpak.msi installed You can use Active Directory Sites and Services to create, modify, and delete site configuration objects in Active Directory, including sites, subnets, connection objects, and site links. You can also use Active Directory Sites and Services to create the intersite topology, including mapping subnet addresses to sites, creating and configuring site links, creating manual connection objects, forcing replication over a connection, setting a domain controller to be a global catalog server, and selecting preferred bridgehead servers. For more information about Active Directory Sites and Services, see Help and Support Center in Windows Server 2003.

Ldifde.exe: Ldifde Category Ldifde is a command-line tool that ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition •

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Ldifde to create, modify, and delete directory objects on domain controllers. You can also use Ldifde to extend the schema, export Active Directory user and group information to other applications or services, and populate Active Directory with data from other directory services.

To find more information about Ldifde, see Command-Line References in the “Tools and Settings Collection.”

Ldp.exe: Ldp Category Ldp is included when you install Windows Server 2003 Support Tools.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional Ldp is a Lightweight Directory Access Protocol (LDAP) graphical user interface (GUI) tool that you can use to perform operations such as connect, bind, search, modify, add, and delete against any LDAP-compatible directory, such as Active Directory. You can also use Ldp to view objects that are stored in Active Directory, along with their metadata, such as security descriptors and replication metadata. To find more information about Ldp, see “Windows Support Tools.”

Netdiag.exe: Network Connectivity Tester Category The Network Connectivity Tester command-line tool (Netdiag) is included when you install Windows Server 2003 Support Tools.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows 2000 Server

Can Be Run From

Can Be Run Against

• Windows Server 2003, Standard Edition

• Windows 2000 Advanced Server

• Windows Server 2003, Enterprise Edition

• Windows 2000 Datacenter Server

• Windows Server 2003, Datacenter Edition • Windows Server 2003, Web Edition Computers running:

• Windows XP Professional with Adminpak.msi installed The Netdiag command-line tool examines .dll files, output from other tools, and the system registry to find potential problems. You can use Netdiag to troubleshoot connectivity over the secured channel that exists between a workstation and a domain controller. For the various trust related tasks that can be performed using this tool, see the table Trust Tools Comparison by Task earlier in this section. To find more information about Netdiag, see “Windows Support Tools.”

Netdom.exe: Windows Domain Manager Category The Windows Domain Manager command-line tool (Netdom) is included when you install Windows Server 2003 Support Tools.

Version compatibility This tool is compatible with computers running Windows XP Professional, Windows Server 2003, Standard Edition; Windows Server 2003, Web Edition, Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition. Netdom is a command-line tool that allows you to create and manage Active Directory trust relationships (except forest trusts) and can help reduce the number of steps needed to create a trust by using Active Directory Domains and Trusts. You can also use the Netdom command line tool to complete batch management of trusts, join computers to domains, verify trusts (including forest trusts) and secured channels, and obtain information about the status of trusts. Netdom can be targeted at all Active Directory domain controllers and can verify all Active Directory trust types. Verification is accomplished between two domains by enumerating the domain controllers in each domain. If you choose to have Netdom create both sides of the trust at once the trust password is automatically generated. To find more information about Netdom, see “Windows Support Tools.”

Nltest.exe: NLTest Category The NLTest command-line tool is included when you install Windows Server 2003 Support Tools.

Version compatibility This tool is compatible with computers running Windows XP Professional, Windows Server 2003, Standard Edition; Windows Server 2003, Web Edition, Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition. You can use the NLTest command-line tool to perform trust-related network administrative tasks such as testing the trust relationship between a Windows–based computer that is a member of a domain and the domain controller on which its computer account is located. In domains where an external trust is defined, NLTest can be used to test the trust relationship between all domain controllers in the trusting domain and a domain controller in the trusted domain. Nltest can also be used to verify any secured channel. To find more information about NLTest, see “Windows Support Tools.”

Ntdsutil.exe: Ntdsutil Category Ntdsutil is a command-line tool that ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Ntdsutil.exe provides management capabilities for Active Directory. You can use Ntdsutil.exe to perform Active Directory database maintenance, manage and control single-master operations, and remove replication metadata left behind by domain controllers that are removed from the network without uninstalling Active Directory. You can also use Ntdsutil to create application directory partitions and perform authoritative restore operations. This tool is intended for use by experienced administrators. To find more information about Ntdsutil, see Command-Line References in the “Tools and Settings Collection.”

Repadmin: Repadmin Category Repadmin is included when you install Windows Server 2003 Support Tools.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional Administrators can use Repadmin to monitor and manage replication between domain controllers. You can determine the last successful replication of all directory partitions, identify inbound and outbound replication partners, identify the current bridgehead servers, view object metadata, and generally manage Active Directory replication topology. You can use

Repadmin to force replication of an entire directory partition or of a single object. You can also list domain controllers in a site. To find more information about Repadmin, at a command prompt type repadmin /? or see Command-Line References in the Tools and Settings Collection.

Schmmgmt.msc: Active Directory Schema Category An Active Directory Administrative Tools MMCsnap-in that is automatically installed on all domain controllers running Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

•

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional with Adminpak.msi installed Active Directory Schema is a graphical user interface that can be used to manage Active Directory objects and their associated attributes. The Active Directory Schema snap-in allows members of the Schema Admins group to manage the schema through a graphical interface. You can create and modify classes and attributes and also specify what attributes are indexed and what attributes are replicated to the Global Catalog. The tool should only be used in a test environment because it does not permit the user to set some important values on new schema objects. Before the snap-in can be used, it must be registered so that it appears as an available snap-in for MMC.

Setspn.exe: Setspn Category Setspn is included when you install Windows Server 2003 Support Tools.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

Can Be Run From

Can Be Run Against

• Windows Server 2003, Datacenter Edition Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition • Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional Administrators can use this command-line tool to read, modify, and delete values in the servicePrincipalNames attribute on an Active Directory service account object. To find more information about Setspn, see “Windows Support Tools.” Top of page

Domains and Forests Registry Entries The following registry entries are associated with domains and forests.

• • •

For data store related registry entries, see “Data Store Tools and Settings.”

• • •

For logon related registry entries, see “Interactive Logon Tools and Settings.”

For global catalog related registry entries, see “Global Catalog Tools and Settings.” For replication related registry entries, see “Active Directory Replication Tools and Settings.” For Kerberos related registry entries, see “Kerberos Authentication Tools and Settings.” For Access Token related registry entries, see “Access Tokens Tools and Settings.” Top of page

Domains and Forests Group Policy Settings The following tables list and describe the Group Policy settings that are associated with domains and forests. Group Policy Settings Associated with Data Store

Group Policy Setting

Description

Audit Directory

When it is enabled, this Group Policy setting causes successful and failed directory access events to

Services Access

be logged in the Directory Service event log.

Group Policy Settings Associated with Active Directory Searches

Group Policy Setting

Description

Maximum size of

Specifies the maximum number of objects that the system displays in response to a command to

Active Directory

browse or search Active Directory.

searches

This policy affects all browse displays that are associated with Active Directory, such as those in Local Users and Groups, Active Directory Users and Computers, and dialog boxes that are used to set permissions for user or group objects in Active Directory. If you enable this policy, you can use it to limit the number of objects that are returned from an Active Directory search. If you disable this policy or if you do not configure it, the system displays up to 10,000 objects.

Enable filter in Find

Displays the filter bar above the results of an Active Directory search. The filter bar consists of buttons

dialog box

for applying additional filters to search results.

Group Policy Setting

Description If you enable this policy, the filter bar appears when the Active Directory Find dialog box opens, but users can hide it.

Hide Active Directory Hides the Active Directory folder in My Network Places. folder

The Active Directory folder displays Active Directory objects in a browse window. If you enable this policy, the Active Directory folder does not appear in the My Network Places folder. If you disable this policy or if you do not configure it, the Active Directory folder appears in the My Network Places folder.

Group Policy Settings Associated with Global Catalogs

Group Policy Setting Description Automated Site

Determines whether domain controllers dynamically register DC Locator site-specific SRV resource

Coverage by the DC

records for the closest sites where no domain controller for the same domain exists (or no global

Locator DNS SRV

catalog server for the same forest exists). These DNS records are dynamically registered by the Net

Records

Logon service, and they are used to locate domain controllers.

Sites Covered by the

Specifies the sites for which global catalog servers should register the site-specific GC Locator SRV

GC Locator DNS SRV

resource records in DNS. These records are registered in addition to the site-specific SRV resource

Records

records registered for the site where the global catalog server is located and, if the global catalog server is appropriately configured, for the sites without a global catalog server in the same forest for which this global catalog server is the closest global catalog server. These records are registered by Net Logon service. If this policy is not configured, it is not applied to any global catalog servers and global catalog servers use their local configuration.

Group Policy Settings Associated with Replication

Group Policy Setting

Description

Account Lockout Policy:

Changes to these settings in the Domain Security Policy trigger urgent replication.

• Account lockout duration • Account lockout threshold

• Reset account lockout counter after

Password Policy:

• Enforce password history

• Maximum password age • Minimum password age • Minimum password length

• Password must meet

complexity requirements

• Store passwords using reversible encryption

Changes to these settings in the Domain Security Policy trigger urgent replication.

Group Policy Setting

Description

Contact PDC on logon

Account lockout and domain password changes rely on contacting the primary domain controller

failure

(PDC) emulator urgently to update the PDC emulator with the change. If Contact PDC on logon failure is disabled, replication of password changes to the PDC emulator occurs non-urgently.

Group Policy Settings Associated with Interactive Logon

Group Policy Setting

Description

Password Policy:

Changes to the Password Policy settings control:

• Enforce password history

• The strength and complexity required of the password of every user

• Maximum password age • Minimum password age • Minimum password length • Password must meet complexity requirements • Store password using reversible encryption for all users in the domain

Audit Policy:

Changes to the Audit Policy settings control:

• Audit account logon events

• Auditing of logons and log offs

• Audit account management

• Auditing of password and permissions changes

• Audit logon events User Rights Assignment:

• Access the computer from the network • Deny logon as a batch job • Deny logon as a service

Changes to the User Rights Assignment settings control:

• Which users are allowed or disallowed to log on to perform

different tasks, including logging on as a batch job and a service

• Which users are allowed or disallowed to logon locally or through terminal services, as well as who can or cannot access the computer from the network

• Deny logon locally • Deny logon through terminal services • Logon as a batch job • Logon as a service • Logon locally Security Options:

Changes to the Security Options settings control:

• Accounts: Limit local accounts use of blank

• Message text and title displayed by the GINA during an interactive

• Domain member: Maximum machine account

• Domain member settings

passwords to console logon only

password age

• Domain member: Require strong (in Windows 2000 or later) session key

logon

• Authentication settings, including allowing or disallowing blank passwords and password age

Group Policy Setting

Description

• Interactive logon: Do not display last user name • Interactive logon: Do not require CTRL+ALT+DEL • Interactive logon: Message Text for users attempting to log on

• Interactive logon: Message title for users attempting to log on

• Interactive logon: Number of previous logons to cache (in case the domain controller is not available)

• Interactive logon: Require domain controller authentication to unlock workstation

• Interactive logon: Smart card removal behavior • Recovery console: Allow automatic administrative logon

• Shutdown: Allow system to be shut down without having to log on

Group Policy Settings Associated with Access Tokens

Group Policy Setting

Description

User Rights Assignment:

Changes to these settings control:

• Create a token object

• Calling APIs to create tokens.

• Replace a process level token

• Whether a process can replace a token.

Audit Policy:

Changes to this setting will:

• Audit policy change •

Audit privilege use

• Audit process tracking

• Generate audits when rights are assigned with one of the tools discussed earlier.

• Enable audit privilege use. Will log when SeAssignPrimaryTokenPrivilege was used.

• Create an audit for assigning a primary token that contains the two processes involved and the identity of the token assigned.

Security Options:

Changes to this setting affect whether Everyone is in the token for anonymous

• Network access: Let Everyone

users.

permissions apply to anonymous users

Group Policy User Rights Assignment Settings Associated with Kerberos

Group Policy Setting

Description

Impersonate a client Windows 2000 security setting that was first introduced in Windows 2000 SP4. When you assign this after authentication

user right to a user, you permit programs that run on behalf of that user to impersonate a client. This security setting helps to prevent unauthorized servers from impersonating clients that connect to it through methods such as remote procedure calls (RPC) or named pipes.

Group Policy Setting

Description By default, members of the Administrators group and the System account are assigned this user right. The following components also are assigned this user right:

• Services that are started by the Service Control Manager • Component Object Model (COM) servers that are started by the COM infrastructure and that are configured to run under a specific account

Group Policy Kerberos Policy Settings Associated with Kerberos

Group Policy Setting

Description

Enforce user logon

Determines whether the KDC validates every request for a session ticket against the user rights

restrictions

policy on the target computer. When this policy is enabled, the user requesting the session ticket must have the right to either Log on locally or to Access this computer from network. Validation of each request is optional because the extra step takes time and might slow network access to services. By default, this policy is enabled.

Maximum lifetime for

Determines the maximum amount of time (in minutes) that a ticket granted for a service (that is, a

service ticket

session ticket) can be used to access the service. If the setting is zero minutes, the ticket never expires. Otherwise, the setting must be greater than ten minutes and less than the setting for Maximum lifetime for user ticket. By default, the setting is 600 minutes (10 hours).

Maximum lifetime for

Determines the maximum amount of time (in hours) that a ticket-granting ticket (TGT) for a user

user ticket

can be used. When a TGT expires, a new one must be requested or the existing one must be renewed. By default, the setting is ten hours.

Maximum lifetime for

Determines the longest period of time (in days) that a TGT can be used if it is repeatedly renewed.

user ticket renewal

By default, the setting is seven days.

Maximum tolerance for

Determines the maximum difference (in minutes) that the Kerberos V5 protocol tolerates between

computer clock

the clock time on a client and the clock time on a server while still considering the two clocks

synchronization

synchronous. By default, the setting is five minutes.

To find more information about these Group Policy settings, see Group Policy Settings Reference in the “Tools and Settings Collection” or see “Account Policy Settings.” Top of page

Domains and Forests WMI Classes Windows Management Instrumentation (WMI) provides access to information about certain objects in a Windows 2000 Server or Windows Server 2003 operating system. WMI providers and classes represent the managed resources on a computer and are used by administrators and developers for scripting and monitoring purposes. The following tables list and describe the WMI classes that are associated with Active Directory domains and forests. WMI Classes Associated with Data Store, Service Principal Names (SPNs) and Active Directory Searches

Class Name

Namespace

Version Compatibility

rootDSE

root\directory\LDAP Domain controllers running:

• Windows Server 2003 • Windows 2000 Server DS_LDAP_Class_Containment

root\directory\LDAP Domain controllers running:

• Windows Server 2003

Class Name

Namespace

Version Compatibility

• Windows 2000 Server DS_LDAP_Instance_Containment root\directory\LDAP Domain controllers running:

• Windows Server 2003 • Windows 2000 Server WMI Classes Associated with Active Directory Replication

Class Name

Namespace

Version Compatibility

MSAD_DomainController \\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003 • Windows 2000 Server MSAD_NamingContext

\\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003 • Windows 2000 Server MSAD_ReplNeighbor

\\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003 • Windows 2000 Server MSAD_ReplCursor

\\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003 • Windows 2000 Server MSAD_ReplPendingOp

\\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003 • Windows 2000 Server WMI Classes Associated with Trusts

Class Name

Namespace

Version Compatibility

Microsoft_TrustProvider

root\microsoftactivedirectory Domain controllers running:

• Windows Server 2003 • Windows 2000 Server Microsoft_DomainTrustStatus root\microsoftactivedirectory Domain controllers running:

• Windows Server 2003 • Windows 2000 Server

Class Name

Namespace

Version Compatibility

Microsoft_LocalDomainInfo

root\microsoftactivedirectory Domain controllers running:

• Windows Server 2003 • Windows 2000 Server WMI Classes Associated with Interactive Logon

Class Name

Namespace Version Compatibility

Win32_LogonSession

\root\cimv2

Computers running:

• Windows Server 2003 • Windows XP Win32_LogonSessionMappedDisk \root\cimv2

Computers running:

• Windows Server 2003 • Windows XP Win32_NetworkLoginProfile

\root\cimv2

Computers running:

• Windows Server 2003 • Windows XP WMI Classes Associated with Access Tokens

Class Name

Namespace Version Compatibility

Win32_TokenGroups

\root\cimv2

Computers running:

• Windows Server 2003 • Windows XP Win32_TokenPrivileges \root\cimv2

Computers running:

• Windows Server 2003 • Windows XP For more information about these WMI classes, see the WMI SDK documentation on MSDN. Top of page

Network Ports Used by Domains and Forests The following tables list the network ports associated with domains and forests. Port Assignments for Raising Active Directory Functional Levels

Service Name UDP TCP LDAP

389

389

LDAP SSL

N/A

636

Port Assignments for Data Store

Service Name

UDP TCP

LDAP

389

389

LDAP SSL

N/A

636

RPC Endpoint Mapper

135

135

Global Catalog LDAP

N/A

3268

Global Catalog LDAP SSL N/A

3269

Port Assignments for Service Publication and SPNs

Service Name

UDP TCP

LDAP

389

389

LDAP SSL

N/A

636

RPC Endpoint Mapper

135

135

Global Catalog LDAP

N/A

3268

Global Catalog LDAP SSL N/A

3269

Kerberos

88

88

Port Assignments for Raising Active Directory Searches

Service Name

UDP TCP

LDAP

389

389

LDAP SSL

N/A

636

Global Catalog LDAP

N/A

3268

Global Catalog LDAP SSL N/A

3269

Port Assignments for Global Catalogs

Service Name UDP TCP LDAP

N/A

3268

LDAP

N/A

3269 (global catalog Secure Sockets Layer [SSL])

LDAP

389

389

LDAP

N/A

686 (SSL)

RPC/REPL

135

135 (endpoint mapper)

Kerberos

88

88

DNS

53

53

SMB over IP

445

445

Port Assignments for Replication

Service Name UDP TCP LDAP

389

389

LDAP

N/A

686 (SSL)

RPC/REPL

N/A

135 (endpoint mapper)

LDAP

N/A

3268

Service Name UDP TCP Kerberos

88

88

DNS

53

53

SMB over IP

445

445

Port Assignments for Operations Masters

Service Name UDP TCP LDAP

389

389

LDAP

N/A

686 (SSL)

RPC/REPL

N/A

135 (endpoint mapper)

Netlogon

N/A

137

Kerberos

88

88

DNS

53

53

SMB over IP

445

445

Port Assignments for Interactive Logon

Service Name

UDP

TCP

Kerberos

88

88

Local Security Authority (LSA) RPC Dynamic RPC Dynamic RPC NTLM

Dynamic

Dynamic

Port Assignments for Kerberos V5 Protocol

Service Name UDP TCP DNS

53

53

Kerberos

88

88

Port Assignment for DC Locator

Service Name UDP TCP LDAP

389

389

The following table shows the list of ports that might need to be opened before you establish trusts. Ports Required for Trusts

Task

Outbound Ports

Inbound Ports

Set up trusts on both sides from the

LDAP (389 UDP and TCP)

internal forest

Microsoft SMB (445 TCP)

controllers–External domain

Kerberos (88 UDP)

domain controllers (all ports)

N/A

From–To Internal domain domain

Endpoint resolution — portmapper (135 TCP) Net Logon fixed port Trust validation from the internal forest LDAP (389 UDP)

N/A

Internal domain domain

domain controller to the external forest Microsoft SMB (445 TCP)

controllers–External domain

domain controller (outgoing trust only) Endpoint resolution —

domain controllers (all ports)

Task

Outbound Ports

Inbound Ports

From–To

portmapper (135 TCP) Net Logon fixed port Use Object picker on the external forest N/A

LDAP (389 UDP and TCP) External server–Internal

to add objects that are in an internal

Windows NT Server 4.0

forest to groups and DACLs

directory service fixed port External domain domain

domain PDCs (Kerberos)

Net Logon fixed port

controllers–Internal domain

Kerberos (88 UDP)

domain controllers (Net Logon)

Endpoint resolution portmapper (135 TCP) Set up trust on the external forest from N/A

LDAP (389 UDP and TCP) External domain domain

the external forest

Microsoft SMB (445 TCP)

controllers–Internal domain

Kerberos (88 UDP)

domain controllers (all ports)

Use Kerberos authentication (internal

Kerberos (88 UDP)

N/A

forest client to external forest) Use NTLM authentication (internal

domain controllers (all ports) N/A

forest client to external forest)

Endpoint resolution –

External domain domain

portmapper (135 TCP) Net controllers–Internal domain Logon fixed port

Join a domain from a computer in the

Internal client–External domain

LDAP (389 UDP and TCP)

N/A

internal network to an external domain Microsoft SMB (445 TCP)

domain controllers (all ports) Internal client–External domain domain controllers (all ports)

Kerberos (88 UDP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port Windows NT Server 4.0 directory service fixed port Top of page

Related Information The following resources contain additional information that is relevant to this section.

• • • • •

Windows Support Tools Command-Line References in the Tools and Settings Collection for information about DSQuery and Ntdsutil. Microsoft Platform SDK on MSDN for more information about many WMI classes that are associated with the DNS Server service. Group Policy Settings Reference in the Tools and Settings Collection for information about Group Policy settings that are associated with the DNS Client service. Registry Reference in the Tools and Settings Collection for information about registry entries that are associated with DNS.

Active Directory Schema Technical Reference Updated: March 28, 2003

The schema is the component of the Active Directory directory service that defines all the objects and attributes that the directory service uses to store data. You can combine some objects in the schema to create more-complex definitions if objects of greater complexity are required. You can also add new definitions to the schema to support new types of objects in the directory. In this subject

• • •

What Is the Active Directory Schema? How the Active Directory Schema Works Active Directory Schema Tools and Settings

What Is the Active Directory Schema? Updated: March 28, 2003

What Is the Active Directory Schema? In this section

• • •

Using Objects to Store Data Building the Schema Related Information

The schema is the Active Directory component that defines all the objects and attributes that the directory service uses to store data. Active Directory stores and retrieves information from a wide variety of applications and services. So that it can store and replicate data from a potentially infinite variety of sources, Active Directory standardizes how data is stored in the directory. By standardizing how data is stored, the directory service can retrieve, update, and replicate data while ensuring that the integrity of the data is maintained. The directory service uses objects as units of storage. All objects are defined in the schema. Each time that the directory handles data, the directory queries the schema for an appropriate object definition. Based on the object definition in the schema, the directory creates the object and stores the data. Object definitions control the types of data that the objects can store, as well as the syntax of the data. Using this information, the schema ensures that all objects conform to their standard definitions. As a result, Active Directory can store, retrieve, and validate the data that it manages, regardless of the application that is the original source of the data. Only data that has an existing object definition in the schema can be stored in the directory. If a new type of data needs to be stored, a new object definition for the data must first be created in the schema. Top of page

Using Objects to Store Data Active Directory uses objects to store information. Objects are data structures that consist of multiple attributes that store both data and its related metadata. Metadata is data that describes the properties of other data. For example, an object that stores a user account has many attributes, including attributes that contain the user’s logon name, first name, last name, and password. Each of those attributes has additional attributes that contain metadata about the information that the attribute stores. The logon name attribute, for example, has multiple attributes of its own. One attribute that is associated with the logon name specifies that the logon name is a required attribute, which means that the user object is not valid unless it contains the logon name attribute. Another attribute that is associated with the logon name specifies the syntax of the value that is stored in the logon name attribute. This ensures that the value that the logon name attribute contains is in a valid format. Both of these attributes contain metadata for the logon name attribute; that is, they define the characteristics of the logon name attribute. The object definitions in the schema list all the object attributes and define how these attributes relate to each other. Some objects are simple and contain only a few attributes, while other objects are quite complex and contain hundreds of attributes. Attributes themselves are objects, and the schema contains a definition for each one. To define new objects, smaller objects are associated with one another to define the necessary attributes of the new objects. For a user object, the user’s logon name attribute is a smaller object that contains a number of attributes of its own. Among them are attributes that define the syntax of the logon name and specify whether or not the logon name attribute is optional or required. The first name and last name attributes are also smaller objects whose definitions can be found in the schema. The object definition that defines the user object lists the logon name attribute object, the first name and last name attribute objects, and many other attribute objects, and it defines how these objects relate to each other to store the data that represents a user account. Defining objects and attributes in this manner gives the schema the ability to efficiently define many different types of objects while retaining the ability to add new types of objects when necessary. Many objects have some attributes in common. For example, many objects have a security descriptor to define who is allowed to access and change their contents. Rather than create a separate security descriptor definition for each object definition, the schema defines a single security descriptor object, and all other object definitions refer to the single security descriptor definition. This makes it possible for

every object that needs a security descriptor to have one security descriptor while keeping only one definition for the security descriptor in the schema. Top of page

Building the Schema The Active Directory installation process that creates the forest also generates the default schema. Thereafter, the default schema replicates to each new domain controller during the installation of the directory on that new domain controller. The default schema contains all the standard object definitions that are necessary for Active Directory to function in a standard deployment of Windows Server 2003. Active Directory uses a multimaster replication topology, which means that any domain controller in a forest can write a change to the directory database and then replicate that change to other domain controllers in the same forest. For a domain controller to create a new object and write it to the directory, the domain controller must have access to the object definition that is needed to create the new object. Every domain controller in a forest maintains a copy of the schema, which makes it possible for domain controllers to have access to the object definitions that they need to store and retrieve information in the directory. In some situations, the default attributes and object definitions in the schema are insufficient to create new object types that are required by some applications or services that interoperate with the directory. In these situations, it is possible to customize the schema by adding new object definitions to it. The process of adding definitions to the schema is referred to as “extending the schema.” It is important to plan the deployment of schema extensions carefully. The directory stores the schema and replicates schema changes to every domain controller throughout the forest. Therefore, extending the schema creates replication traffic, which can briefly affect network traffic. For more information about extending the schema, see “How the Active Directory Schema Works.”

How the Active Directory Schema Works Updated: March 28, 2003

How the Active Directory Schema Works In this section

• • • •

Active Directory Schema Architecture Active Directory Schema Physical Structure Active Directory Schema Processes and Interactions Related Information

The schema is the Active Directory component that defines all the objects and attributes that the directory service uses to store data. The physical structure of the schema consists of the object definitions. The schema itself is stored in the directory. The schema is stored in its own partition (the schema partition) in the directory. The schema 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. Top of page

Active Directory Schema Architecture In Active Directory, the schema defines the following:

• • •

Objects that are used to store data in the directory The rules that govern the structure of those objects The structure and the content of the directory itself

These definitions consist of objects, attributes, and classes, which are described in the following section.

Schema Components Objects, attributes, and classes are the basic components that are used to build object definitions in the schema.

Objects Objects are structures that store both data that the objects represent and data that controls the content and structure of the objects. For example, a user account object contains a user’s logon name as well as data that indicates the proper syntax for storing the user’s logon name in the user object. Active Directory uses objects to store data while the data is maintained in the directory. When the directory stores an object, some associated data is also stored along with the object. The extra data is stored in the attributes of the object.

Attributes Attributes contain data that defines the information that is stored in an object or in another attribute. For example, a user account object has attributes that store user information, such as the user’s first name, last name, password, office number, and telephone number. Different types of objects have different attributes. A printer object has attributes that store information that is related to printers, such as the printer model, the number of paper trays, the current location of the printer, and the port to which the printer is attached. Some attributes contain information that relates to other attributes, such as syntax information or flags that label the attribute as optional or required. Syntax attributes define the format that is used to store data in other attributes. For example, because a telephone number comprises only digits, a syntax attribute might specify that the phone number attribute can only store digits 0 through 9, and letters of the alphabet are prohibited. Active Directory uses syntax attributes to ensure that information is stored in a legitimate format and that the information is a valid data type. Attributes can be required or optional. A user account object requires a user name attribute and a password attribute, although the office number attribute is optional. That is, a user account cannot be used without a user name; however, it can be used without an office number. The office number attribute is included for convenience, and it is considered an optional attribute. An object definition is really an association of various attributes that are used to describe the characteristics of an object that stores specific pieces of data. The kind of data that the object stores determines which attributes are needed to define the object. Large objects are made up of many smaller objects. In the user account object example, the user’s logon name attribute is a smaller object that contains a number of attributes of its own, including attributes that define the syntax of the logon name and that specify whether or not the logon name attribute is optional or required. The first name and last name attributes are also smaller objects that are defined in the schema. The object definition for the user account object lists the logon name attribute and the first name and last name attributes, as well as many other attributes, and it defines how these attributes relate to each other to store the data that represents a user account. Defining objects and attributes this way gives the schema the ability to efficiently define many different types of objects. Many objects have some attributes in common. For example, many objects have a security descriptor to define who is allowed to access and make changes to the contents of the object. Rather than create a separate security descriptor definition for each object definition, the schema defines a single security descriptor object, and all other object definitions refer to the single security descriptor definition. This makes it possible for every object that needs a security descriptor to have one, while keeping only one definition for the security descriptor in the schema.

Classes Object definitions are categorized into groups that are called classes. Classes act as blueprints that can be used each time a new object is created. When a new object is created in the directory, the object’s class determines the attributes that are associated with the new object, including which attributes are required and which attributes are optional. Active Directory has predefined classes that define all of the different object type’s that the directory needs to function properly. For example, when a new user account object is created in the directory, its definition comes from the classUser class. The class dictates that the new account object is required to have a user name attribute and a password attribute, and optionally it might have an office number attribute. Object definitions are created by nesting classes inside one another. Nesting classes produces a parent/child relationship between the classes. Classes that are nested inside another class are referred to as subclasses. The parent of a subclass is referred to as a superclass. When one class is nested inside another, the nested class inherits the properties of the parent superclass. When various classes that contain particular attributes are nested inside another object class, a new object definition is created. Which classes are nested depends on which attributes are needed to define the new object type.

The schema stores class information, but it does not store the actual objects that are derived from a class. For example, when a new user account object is created, it is not stored in the schema. Active Directory looks up the user class in the schema. Active Directory then retrieves information regarding the object type and its associated attributes from the user class in the schema and uses that information to create the new user account object. When the new account is created, the data is stored in the new object, and Active Directory then writes the new account information into the directory database. The schema is the master list of all classes and attributes that can be used in the directory. During the installation of Active Directory, the Schema.ini file is used to build the default schema on the first domain controller in the forest. The default schema provides all the necessary classes that Active Directory needs to function. Administrators or developers might want to add their own classes or add their own attributes to an existing object type. They can do this through the process of extending the schema. The schema should only be extended in special situations. For more information on extending the schema, see “Modifying the Schema” later in this section.

Schema Objects Active Directory uses objects to store and reference data in the directory. The schema defines the types of objects that are available to the directory service. The schema is stored in the schema partition, which is also defined as an object in the directory. The attributes and classes in Active Directory are stored in the schema partition as directory objects that are called schema objects. The schema partition itself is represented in Active Directory by an object that is an instance of the Directory Management Domain (dMD) class. Storing the schema in the directory has many advantages. For example, when user applications locate the schema in the directory, they can read the schema to discover what types of objects and properties are available. Because the schema is stored in the directory — like the rest of the data in the directory — applications can locate the schema by using the same process that they use to locate any other object in the schema. A schema object, called a classSchema object, defines each class in the schema. Another schema object, called an attributeSchema object, defines each attribute in the schema. Therefore, every class is actually an instance of the classSchema class, and every attribute is an instance of the attributeSchema class, as shown in the following figure. Schema Objects

Schema objects are used to define classes and attributes in the schema. Classes in the schema are used to define objects in the directory.

attributeSchema Objects Attributes describe the classes that are defined in the schema. Attributes are defined in the schema separately from classes, which enables a single attribute definition to be applied to many classes. Attributes are attributeSchema objects. Each attributeSchema object is an instance of the attributeSchema class. Like any other object, the attributeSchema object has its own attributes. The attributes for the attributeSchema object store, among other things, the following information:

• • •

The Lightweight Directory Access Protocol (LDAP) display name of the attribute The object identifier for the attribute The globally unique identifier (GUID) for the attribute

• • • •

The syntax of the attribute The range for the attribute. For integers, range defines the minimum and maximum value; for strings, range defines the minimum and maximum length. Whether the attribute is a multivalue attribute. Note that multivalue attributes hold a set of values with no particular order. Multivalue attributes might not be returned in the order in which they were stored (or in any other order). Whether and how the attribute is indexed

Attributes for the attributeSchema class Attributes for the attributeSchema class are described in the following table. Attributes for the attributeSchema Class

Attribute

Syntax

Mandatory?

Multivalue? Description

cn

Unicode

Yes

No

Descriptive relative distinguished name for the schema object

attributeID

Object

Yes

No

Object identifier that uniquely identifies this attribute

Yes, but

No

Name by which LDAP clients identify this attribute

identifier lDAPDisplayName

Unicode

automatic schemaIDGUID

String(Octet)

Yes

No

GUID that uniquely identifies this attribute

mAPIID

Integer

No

No

Integer by which Messaging API (MAPI) clients identify this attribute

attributeSecurityGUID GUID

No

No

GUID by which the security system identifies the property set of this attribute

attributeSyntax

Object

Yes

No

Syntax object identifier of this attribute

Yes

No

Syntax of this attribute as defined by the XAPIA

identifier oMSyntax

Integer

X/Open Object Model (XOM) specification isSingleValue

BOOL

Yes

No

Indicates whether this attribute is a single-value or multivalue attribute Note that multivalue attributes hold a set of values with no particular order. Multivalue attributes might not be returned in the order in which they were stored (or in any other order).

extendedCharsAllowed BOOL

No

No

Indicates whether extended characters are allowed in the value of this attribute Applies only to attributes of syntax String(teletex).

rangeLower

Integer

No

No

Lower range of values that are allowed for this attribute

rangeUpper

Integer

No

No

Upper range of values that are allowed for this attribute

systemFlags

Integer

No

No

Flags that determine specific system operations Note: This attribute cannot be set or modified. The following systemFlags attributes are relevant to the schema objects: Attribute is required to be a member of the partial set = 0x00000002 Attribute is not replicated = 0x00000001 Attribute is a constructed attribute = 0x00000004

Attribute

Syntax

Mandatory?

Multivalue? Description

searchFlags

Integer

No

No

The searchFlags property of each property’s attributeSchema object defines whether a property is indexed and other behavior. The seven currently defined bits for this attribute are: 1 = Index over attribute only 2 = Index over container and attribute 4 = Add this attribute to the ambiguous name resolution (ANR) set (should be used in conjunction with 1) 8 = Preserve this attribute on logical deletion (that is, make this attribute available on tombstones) 16 = Include this attribute when copying a user object 32 = Create a Tuple index for the attribute to improve medial searches 64 = Reserved for future use; value should be 0. 128 = Available in Windows Server 2003 Service Pack 1 (SP1) only. Mark the attribute confidential (CONTROL_ACCESS is required to read it).

isMemberof

BOOL

No

No

PartialAttributeSet

A Boolean value that defines whether the attribute is replicated to the global catalog A value of TRUE means that the attribute is replicated to the global catalog. In environments where domain controllers are running Windows 2000 Server, changing this value might cause full synchronization of the Partial Attribute Set. For more information about the conditions under which full synchronization occurs, see How the Global Catalog Works on the Microsoft Web site at http://go.microsoft.com/fwlink/? LinkId=47817.

systemOnly

BOOL

No

No

Attributes on which Windows Server 2003 and Active Directory depend for normal operations If TRUE, only the system can modify this attribute. No user-defined attribute must ever have the systemOnly flag set.

objectClass

Object

Yes

Yes

Class of this object, which is always attributeSchema

Yes

No

Security descriptor on the attributeSchema object

identifier nTSecurityDescriptor

NT-Sec-Des

itself oMObjectClass

String(Octet)

No

No

For object-syntaxed attributes (OM-syntax = 127), the Basic Encoding Rules (BER) encoded object identifier of the XOM object class For more information about BER encoding, see Request for Comments (RFC) 2251 in the IETF RFC Database.

LinkID

Integer

No

No

Whether it is for a linked attribute or not, an even integer denotes a forward link; an odd integer denotes a back link.

Attribute

Syntax

Mandatory?

Multivalue? Description A forward link points to another object in the directory; a back link points back to the first object that has a forward link to it.

Single-value and multivalue attributes Some attributes contain a single value, and other attributes can contain multiple values. For example, the password attribute on a user object contains a single value: the password that is associated with the user account. The memberOf attribute contains multiple values: a list of the various groups of which the user account is a member. Each item in the list is stored as a separate value in the memberOf attribute. Attributes that can store more than a single value are referred to as “multivalue” attributes. Whether or not attributes are single-value or multivalue is defined by the singleValue attribute as a Boolean value. The Active Directory Schema snap-in reports this attribute as “single-value” or multivalue rather than as the attribute-value pair. (Active Directory Schema is a Microsoft Management Console (MMC) graphical interface tool in Windows Server 2003 that administrators can use to manage the schema.) All values that are defined for a multivalue attribute must have a uniform syntax. Multivalue attributes that are not linked can store a maximum of 1,300 entries. This limit is based on the size and type of the values that are stored. Note

•

When it retrieves data, LDAP reads a multivalue attribute as a single entity. This can be inconvenient or even impossible when the number of values in a multivalue attribute becomes large. A property called Range can be specified as part of an attribute description to retrieve the values of a multivalue attribute incrementally. Servers might or might not honor the Range property. Servers that support the Range property include the object identifier 1.2.840.113556.1.4.802 in the supportedControls operational attribute on the rootDSE. Clients must not use the Range property unless this object identifier is present. The Range property is a constant, case-insensitive string value (Range=), followed by a range specifier that lists the initial value and terminal value in the range.

Linked attributes Linked attributes make it possible to associate one attribute with another attribute. A linked attribute consists of a pair of attributes for which the system calculates the values of one attribute based on the values that are set on the other attribute. One attribute of the pair is referred to as the back link, and the other attribute is referred to as the forward link. The back link is a multivalue attribute that contains the distinguished names of all the other objects that have an attribute linked to it. The forward link is a single-value attribute that contains the distinguished name of the object to which it is linked. For example, you can create an object to store information in the directory that is related to a specific project. Among other things, the project object stores the names of the project team members. To store the names of the team members, you can use the linked attributes ProjectName and TeamMembers. ProjectName is the forward link, and it is an attribute of the team member’s user account object that stores the name of the project that the user works on. TeamMembers is the back link, and it is an attribute of the project object that stores the list of team members who work on the project. Assume that Mike and Amanda are members of the project team. If you store the distinguished name of the project object in the ProjectName attribute of Mike’s user object and Amanda’s user object, the distinguished names of Mike’s user object and Amanda’s user object appear in the TeamMembers attribute of the project’s object. A linked pair is identified by the linkID values of two attributeSchema objects. The linkID of the forward link is an even, positive, nonzero value, and the linkID of the associated back link is the value of the forward linkID, incremented by one. For example, if the linkID for ProjectTeam is 37, the linkID for TeamMembers is 38.

Automated links The linkIDs must be unique within the forest. In Windows 2000 Server, linkIDs are allocated by the applications that used them, and it is up to application developers to make sure that the linkIDs for the applications do not conflict with linkIDs that are already in use. Windows Server 2003 can generate link values automatically to ensure that there are no conflicts within the forest. When new objects that use linked attributes are created, Active Directory automatically generates the necessary linkIDs.

Indexed attributes Directory searches for attributes that are indexed are more efficient than searches for attributes that are not indexed. Attributes are indexed when the least significant bit in their searchFlags attribute is set to the value 1. Changing the value of the bit to 1 dynamically builds an index; changing the value to 0 or deleting it removes an index for the attribute in question. The index is built automatically by a background thread on the directory server. The values for indexed attributes are stored in a sorted list. This makes searching much more efficient because the system needs to search only until it locates the area in the list where the value should be, based on the sort. If the value is not there, the system can assume it will not find the value anywhere else in the list, and it can terminate the search. When attributes are not indexed, the entire list must be searched to determine whether or not a particular value actually exists. Indexing requires more storage to maintain the lists, but it makes searching more efficient. Nonindexed attributes are less efficient to search, but they require less storage to maintain. With this in mind, only attributes that are frequently referenced should be indexed. Ideally, indexed attributes are single-value attributes with unique values that are evenly distributed across the set of instances. Multivalue attributes can be indexed, but building the index requires more storage and updating.

Confidential attributes On domain controllers running Windows Server 2003 with SP1, attributes whose attributeSchema objects are marked with a specific search flag are interpreted as confidential. Attributes that are so marked can be read only by users to whom the following access is granted:

• •

READ_PROPERTY CONTROL_ACCESS

The ability to mark attributes as confidential allows administrators to protect attributes from the read access that is granted by default to most users. Rather than changing the defaults that are expected by existing applications, administrators can create new attributes that can be read only by administrators or those to whom access is specifically granted. Because domain controllers must be running Windows Server 2003 with SP1 to recognize the flag that marks the attribute as confidential, protection of marked attributes is fully effective only in environments where all domain controllers have been upgraded to Windows Server 2003 with SP1. In particular, the schema operations master (also known as the schema flexible single-master operations (FSMO) role holder) must be upgraded to Windows Server 2003 with SP1. By default, Active Directory performs a read-access check on an object in the following cases:

• •

When evaluating whether the object matches the search filter When returning attributes of an object that matches the search

filter Default security in Windows 2000 Server and Windows Server 2003 allows read access to the Pre-Windows 2000 Compatible Access group, which usually contains Authenticated Users. Authenticated Users is a security group that includes users whose identities can be authenticated by the server or by a trusted security authority. Because the Pre-Windows 2000 Compatible Access group is granted Read_Property permissions on user objects (including inetOrgPerson) and group objects, it is difficult to introduce a new attribute on these objects that is protected from reading by most users. For example, you might want to add a social security number attribute to the user class. To solve this problem, Windows Server 2003 SP1 provides a way to mark an attribute as confidential by setting a searchFlags value on the attributeSchema object in the schema. The search flag contains multiple bits representing various properties of an attribute. In Windows 2000 Server and Windows Server 2003 schemas, the searchFlags attribute has six bits that can be set. (See the bits that are defined for the searchFlags attribute in "Attributes for the attributeSchema class" earlier in this section.) For example, a value of 1 in the least significant bit means that the attribute is indexed. The binary form of this flag value is 00000001. A new bit is added in Windows Server 2003 with SP1: A value in bit 128 (10000000) designates the attribute as confidential. Therefore, on a domain controller running Windows Server 2003 with SP1, you can designate an attribute as confidential by setting bit 128 in the searchFlags attribute of the respective attributeSchema object. Note You cannot set this flag on base-schema attributes, such as common-name. When an attribute is so designated, in addition to READ_PROPERTY permission (for that attribute or all attributes on that object), CONTROL_ACCESS permission (for that attribute or a property set that contains that attribute) is required to read the attribute. Note

When you assign CONTROL_ACCESS permissions to a user or group, you must specify a GUID — in this case, the GUID of the attribute or property set that contains the attribute. To set the bit flag when no values are set, you can simply add the value 128 to the searchFlags attribute in the properties of the attributeSchema object for the confidential attribute. If a value is already present in the attribute, perform a bitwise OR operation to add 10000000 to the existing binary value, and then convert to decimal. For example, if the bit is set for indexing and containerized search (00001001), the combined values 10000000 OR 00001001 equal 10001001, translating to a decimal value of 137. By default, only members of the Administrators built-in group are granted CONTROL_ACCESS to all objects. Therefore, only administrators can read confidential attributes. You can delegate the CONTROL_ACCESS right to any specific group by using the Dsacls command-line tool or by scripting. Dsacls is included in Windows Support Tools. To grant access to a confidential attribute, use Dsacls to grant the CONTROL_ACCESS right (CA) to the required group or user. Doing so introduces a way to impose additional security checks that control read access to selected attributes. For more information about Dsacls, see Dsacls.exe in the Active Directory Management Support Tools section of Windows Support Tools on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=43235. For more information about property sets and CONTROL_ACCESS permissions, see the Security Descriptors and Access Control Lists Technical Reference.

Syntaxes The syntax for an attribute defines the storage representation, byte ordering, and matching rules for comparisons of property types. The syntax defines whether the attribute value must be a string, a number, or a unit of time. Each attribute of every object is associated with exactly one syntax. The syntaxes are not represented as objects in the schema, but they are programmed to be understood by Active Directory. The allowable syntaxes in Active Directory are predefined. You cannot add new syntaxes. When you define a new attribute, you must specify both the attributeSyntax and the oMSyntax numbers of the syntax that you want for that attribute. The attributeSyntax number is an object identifier, and the oMSyntax number is an integer. oMSyntax is defined by the XOM specification. Using this model, the syntax can provide detailed syntax definitions. For example, distinct oMSyntax attributes distinguish several types of printable strings, according to such factors as the supported character set and whether case is significant. The following table lists the valid syntaxes for attributes in the Active Directory schema. Valid Syntaxes for Attributes in the Active Directory Schema

Syntax

attributeSyntax oMSyntax ASN 1-Encoded Object Identifier

Description

Undefined

2.5.5.0

\x550500

Not a legal syntax

Object(DN-DN)

2.5.5.1

\x550501

The fully qualified name of an

127

object in the directory String(Object-Identifier)

2.5.5.2

6

\x550502

The object identifier

Case-Sensitive String

2.5.5.3

27

\x550503

General string — differentiates uppercase and lowercase

CaseIgnoreString(Teletex)

2.5.5.4

20

\x550504

Teletex — does not differentiate uppercase and lowercase

String(Printable), String(IA5)

2.5.5.5

19, 22

\x550505

Printable string or IA5-String Both character sets are case sensitive.

String(Numeric)

2.5.5.6

18

\x550506

A sequence of digits

Object(DN-Binary)

2.5.5.7

127

\x550507

A distinguished name plus a binary large object

Boolean

2.5.5.8

1

\x550508

TRUE or FALSE values

Integer, Enumeration

2.5.5.9

2, 10

\x550509

A 32-bit number or enumeration

Syntax

attributeSyntax oMSyntax ASN 1-Encoded Object Identifier

Description

String(Octet)

2.5.5.10

4

\x55050A

A string of bytes

String(UTC-Time),

2.5.5.11

23, 24

\x55050B

UTC time or generalized-time

String(Unicode)

2.5.5.12

64

\x55050C

Unicode string

Object(Presentation-Address)

2.5.5.13

127

\x55050D

Presentation address

Object(DN-String)

2.5.5.14

127

\x55050E

A DN-String plus a Unicode string

String(NT-Sec-Desc)

2.5.5.15

66

\x55050F

A Windows NT security descriptor

LargeInteger

2.5.5.16

65

\x550510

A 64-bit number

String(Sid)

2.5.5.17

4

\x550511

Security identifier (SID)

String(Generalized-Time)

Object identifiers Object identifiers are unique numeric values that are granted by various issuing authorities to identify data elements, syntaxes, and other parts of distributed applications. Because they are globally unique, object identifiers ensure that the objects that are defined by these issuing authorities do not conflict with one another when different directories, such as Active Directory and Novell Directory Services, are used concurrently within a global directory namespace. Object identifiers are found in Open Systems Interconnection (OSI) applications, X.500 directories, applications that use Simple Network Management Protocol (SNMP), and other applications in which uniqueness is important. Object identifiers are based on a tree structure in which a superior issuing authority allocates a branch of the tree to a subordinate authority, which in turn allocates subbranches of the tree. LDAP requires a directory service, such as Active Directory, to identify object classes and attributes with an object identifier syntax. The object identifier is the value for the governsID attribute in a classSchema object and for the attributeID attribute in an attributeSchema object. These are required attributes; therefore, object identifiers are necessary when you create new classes or attributes. Object identifiers in the Active Directory base schema include some object identifiers that are issued by the International Organization for Standardization (ISO) for X.500 classes and attributes and some object identifiers that are issued by Microsoft. Object identifier notation is a dotted string of nonnegative numbers, for example, 1.2.840.113556.1.5.4. The components of this object identifier are shown in the following table. Components of an Object Identifier (1.2.840.113556.1.5.4)

Numerical Values of the Object Identifier What the Numerical Values Mean 1

ISO (“root” authority) issued 1.2 to ANSI.

2

ANSI issued 1.2.840 to the USA.

840

USA issued 1.2.840.113556 to Microsoft.

113556

Microsoft internally manages several object identifier branches under 1.2.840.113556 that include the following three identifiers.

1

A branch called Active Directory that includes the following two identifiers.

5

A branch called Classes that includes the following identifier.

4

A class called Builtin-Domain.

Object identifiers ensure that every object is interpreted appropriately, for example, that a telephone number is not mistaken for an employee number. A series of widely used objects and attributes is standardized for use in object identifiers. New object identifiers are issued by standards authorities, and they form a hierarchy below which new object identifiers can be managed internally. Most countries and regions in the world have an identified National Registration Authority (NRA) that is responsible for issuing object identifiers to enterprises. In the United States, the NRA is the American National Standards Institute (ANSI).

The NRA issues root object identifiers. An enterprise can register a name for the object identifier as well. A fee is associated with registering root object identifiers and registered names. Contact the NRA for your country or region for details. The ISO recognizes NRAs and maintains a list of contacts on its Web site. The issuing authority assigns an object identifier space that is a branch of the ISO-International Telecommunication Union (ITU) object identifier tree. For example, your organization might be assigned the space 1.2.840.111111. You can extend this space internally within the constraints of the structure of an object identifier. You can subdivide this space further (by appending dotted decimals to the object identifier root) and assign these subspaces to various divisions within your organization. Each division, in turn, can further subdivide the subspace that is allotted to it. For the example object identifier 1.2.840.111111, your organization might use the subspace 1.2.840.111111.1.4 for attributes and the subspace 1.2.840.111111.1.5 for classes. An internal issuing authority in your organization, using an Administrator account, might then allocate object identifiers from this space when requested. The governsID attribute on every classSchema object and the attributeID attribute on every attributeSchema object are mandatory attributes that contain an object identifier string. In this example, all of your organization-created classSchema objects have a governsID attribute of the form 1.2.840.111111.1.5.x, where x is a decimal number. Similarly, all of your organization-created attributeSchema objects have an attributeID attribute of the form 1.2.840.111111.1.4.x. Microsoft also offers a free object identifier registration service.

classSchema Objects The classSchema object specifies the various attributes of the class with which it is associated. Among other things, it defines the following constraints for objects that are instances of the class:

•

mustContainattributes, which include mandatory attributes that must be present on any object that is an instance of this

• •

mayContain attributes, which include optional attributes that may be found on an object that is an instance of this class

class Hierarchy rules that determine the possible parents in the directory tree of an object that is an instance of the class

An object can have attributes that belong only to either the mustContain list or the mayContain list for the class. The classSchema object is essentially a template that contains the rules for creating objects in an Active Directory class. When a new object is created in a class, the classSchema object ensures that this new object has the same attributes as all other objects in the class. The classSchema object contains, among other things, the following information:

• • • • • • • • • •

The LDAP display name of the class The object identifier for the class The GUID for the class The attributes that must be present for an instance of the class Other attributes that can be present for an instance of the class The classes to which the parent of instances of this class may belong The superclass from which this class inherits characteristics Other Auxiliaryauxiliary classes from which this class inherits attributes The type of class (Abstractabstract, Structuralstructural, or Auxiliaryauxiliary) The default hiding state for the class. If you do not want instances of the class to be displayed by the end-user user interface (UI), you can define the class as hidden by default.

Attributes for classSchemaobjects The following table lists the attributes that a classSchema object can have. Attributes for a classSchema Object

Attribute

Syntax

Mandatory?

Multivalue? Description

cn

Unicode

Yes

No

Descriptive relative distinguished name for the schema object

governsID

Object identifier Yes

No

The object identifier that uniquely identifies this

Attribute

Syntax

Mandatory?

Multivalue? Description class

lDAPDisplayName

Unicode

Yes

No

The name by which LDAP clients identify this class

schemaIDGUID

String(Octet)

Yes, but

No

The GUID that uniquely identifies this class

No

The relative distinguished name type of instances

defaulted rDNAttID

Object identifier No

of this class (OU, CN) subClassOf

Object identifier Yes

No

The class from which this object inherits attributes

systemMustContain

Object identifier No

Yes

The list of mandatory attributes for instances of this class This list cannot be changed.

mustContain2

Object identifier No

Yes

The mandatory attributes for instances of this class

systemMayContain

Object identifier No

Yes

The optional attributes for instances of this class

mayContain2

Object identifier No

Yes

The optional attributes for instances of this class

systemPossSuperiors2

Object identifier No

Yes

The classes that can be parents of this class in the directory hierarchy After the class is created, this property cannot be changed.

possSuperiors2

Object identifier No

Yes

The classes that can be parents of this class in the directory hierarchy For an existing classSchema object, values can be added to this property but not removed.

systemAuxiliaryClass2

Object identifier No

Yes

The Auxiliaryauxiliary classes from which this class inherits its optional (mayContain) and mandatory (mustContain) attributes After creation of the class, this property cannot be changed.

auxiliaryClass2

Object identifier No

Yes

The Auxiliaryauxiliary classes from which this class inherits its optional (mayContain) and mandatory (mustContain) attributes This is a multivalue property that specifies the auxiliary classes that this class inherits from. For an existing classSchema object, values can be added to this property but not removed.

defaultHidingValue

BOOL

No

No

The default hiding state for the class If you do not want instances of the class displayed in the UI for Active Directory admin tools New menus, you can define the class as hidden.

defaultSecurityDescriptor String(Octet)

No

No

The default security descriptor that is assigned to new instances of this class if no security descriptor is specified during creation of the class or that is merged into a security descriptor if a security descriptor is specified

objectClassCategory

Integer

Yes

No

Class types are defined as follows: 88 Class = 0

Attribute

Syntax

Mandatory?

Multivalue? Description Structural = 1 Abstract = 2 Auxiliary = 3 The 88 class type is included for compatibility with older directories. Active Directory does not use 88 class type objects, and they should not be used in defining new classes for Active Directory.

systemOnly

BOOL

No

No

An attribute of a classSchema object If it is set to TRUE, only the system can create and modify instances of this class. If it is set to FALSE, modifications can also be made by users who have appropriate permissions.

objectClass

Object

Yes

Yes

This object’s class, which is always classSchema

Identifier nTSecurityDescriptor

NT-Sec-Desc

Yes

No

The security descriptor on the classSchema object

defaultObjectCategory

Distinguished

Yes

No

The default object category of new instances of

name

this class If none has been specified, the objectClass value is used.

The attributes in a classSchema object’s mustContain attribute list are not the complete set of attributes that must be present for an instance of a class to exist. For example, in a class A, the classSchema object B specifies a list of mustContain attributes that an instance of A must have through the systemMustContain and mustContain attributes. However, because mandatory attributes are also inherited, the complete list of attributes for an instance of class A includes the inherited mustContain attributes from all classes from which B inherits, that is, all classes in the subClassOf and auxiliaryClass lists for the classSchema object B. The mayContain attributes for object B are also defined this way. The possSuperiors attributes are defined this way as well, except that possSuperiors attributes are inherited only from classes in the subClassOf list, not from the classes in the auxiliaryClass list.

Mandatory attributes Mandatory attributes are object attributes for which you must specify values. If you do not specify a value for a mandatory attribute, the attribute receives a default value or the object is not created until you specify a value for the attribute. The object’s mandatory attributes are determined by the class to which the object belongs. Some mandatory attributes are inherited. Because every classSchemaobject belongs to a superclass called Top in the class hierarchy, each classSchema object inherits the mandatory attributes that belong to Top. The following table lists the mandatory attributes that every object inherits from Top. To see a graphical representation of the Active Directory class hierarchy, see the figure under “Object class hierarchy” later in this section. Mandatory Attributes That All classSchemaObjects Inherit

Inherited Mandatory Attribute

Default Status

nTSecurityDescriptor

Set to a default value if not specified. The default value depends on the default security descriptor for the classSchema object.

objectCategory

Automatically set to the value of the default object category of the class, which is usually the class itself. Can be changed after the class is created.

objectClass

No default. An administrator must specify the class.

You can view an object’s mandatory attributes by using the Active Directory Schema snap-in. The attributes are displayed on the Attributes tab in the properties dialog box for the object. Because some of an object’s mandatory attributes are

inherited from its parent class, you might need to view the attributes of the parent class to identify all the mandatory attributes of the object.

System and changeable attribute pairs Some properties of a class-definition object are contained in pairs of attributes, in which the value of one of these attributes can be changed by administrators and the value of the other attribute cannot be changed. These attribute pairs are as follows:

• • • •

mustContain/systemMustContain mayContain/systemMayContain possSuperiors/systemPossSuperiors auxiliaryClass/systemAuxiliaryClass

In each of these pairs, the value of the attribute that begins with the word “system” cannot be changed by administrators. This enables Active Directory to protect certain key attributes of certain classes and to ensure that the schema stays consistent and usable. System-only properties can be changed only by the Directory System Agent (DSA). System-only properties are those properties on which Windows Server 2003 and Active Directory depend for normal operations. For example, the attributeID attribute and the governsID attribute in the schema are system-only attributes. The values of the other (nonsystem) attributes in each pair can be changed by administrators.

Categories of Object Classes Different categories of object classes make it possible to define structure in the directory. The 1993 X.500 specification requires that object classes be assigned to one of three categories:

• • •

Structural Abstract Auxiliary

A fourth category, which is referred to as 88 classes, is associated with object classes, although this category is not part of the 1993 specification. The 88 class category is in the specification that existed before 1993, and it should not be used for adding classes to Active Directory.

Structural classes Structural classes are the only classes that can have instances in the directory. That is, you can create directory objects whose class is one of the structural classes. A structural class:

• • •

Can be used in defining the structure of the directory. Is derived from either an abstract class or another structural class. Can include any number of auxiliary classes in its definition.

This type of class is specified by a value of 1 in the objectClassCategory attribute.

Abstract classes Abstract classes are templates that are used to derive new structural classes. Abstract classes cannot be instantiated in the directory. This means that no object can belong only to an abstract class; each object of an abstract class also belongs to some structural subclass of that class. A new abstract class can be derived from an existing abstract class. This type of class is specified by a value of 2 in the objectClassCategoryattribute. Abstract classes only provide attributes for subordinate classes, which are called subclasses. A subclass contains all mandatory and optional attributes of the class from which it is derived (its superclass) in addition to those attributes that are specific to the class itself. Likewise, the subclass of that class contains all attributes of both superclasses, and so forth.

Auxiliary classes Auxiliary classes are like include files; they contain a list of attributes. Adding an auxiliary class to the definition of a structural class or an abstract class’ adds the auxiliary classs attributes to the definition. An auxiliary class cannot be instantiated in the directory, but new auxiliary classes can be derived from existing auxiliary classes. This type of class is specified by a value of 3 in the objectClassCategory attribute. For example, the securityPrincipal class is an auxiliary

class, and it derives its attributes from the parent abstract class called Top. Although you cannot create a security principal object in the directory (because auxiliary classes cannot have instances), you can create an object of the structural class user, which has the securityPrincipal class as an auxiliary class. The attributes of the securityPrincipal class help the system recognize the user object as a security account. Similarly, the group class has securityPrincipal as an auxiliary class. The behavior of auxiliary classes has changed in Windows Server 2003. In Windows 2000 Server, changes that are made to an auxiliary class affect its parent class as well as all instances of the parent object. For example, adding an auxiliary class called pager to the structural class user affects all instances of user, which is all of the user accounts that are created with the user class. In Windows Server 2003, auxiliary classes can be assigned dynamically to individual instances of classes, rather than being applied automatically to all instances. For example, you can assign the pager auxiliary class to only those users who need it.

88 classes Classes that were defined before 1993 are not required to fall into one of the preceding categories; assigning classes to categories was not required in the X.500 1988 specification. Classes that were defined before the X.500 1993 standards are assigned to the 88 class. This type of class is specified by a value of 0 in the objectClassCategory attribute. Do not use 88 classes or define new 88 classes.

Object class hierarchy Inheritance, which is also referred to as derivation, is the ability to build new object classes from existing object classes. A new object is defined as a subclass of its parent object. A subclass is a class that inherits from some other class; for example, a subclass inherits structure and content rules from the parent class. The parent object becomes a superclass of the new object. A superclass is a class from which one or more other classes inherit information. The inherited information includes mandatory and optional attributes (systemMustContain, mustContain, systemMayContain, and mayContain) and the parent classes in the directory hierarchy (systemPossSuperiors and possSuperiors). This relationship between the superclasses and their subclasses represents the object class hierarchy, which is illustrated in the following figure. Object Class Hierarchy

All structural object classes are subclasses, directly or indirectly, of a single abstract object class, which is called Top. Every object that is represented in the directory belongs to Top, and as a result every entry must have an objectClass attribute. When you create a new class, you must specify the superclass. If you do not create a subclass of an existing class, the new class is a subclass of Top. A new class can inherit mandatory and optional attributes from more than one existing class. However, any additional classes must be specified by the auxiliaryClass attribute. Note

•

If you later add another attribute to a class that has subclasses or auxiliary subclasses, the new attribute is automatically added to the subclasses after the schema cache has been updated.

Structure and Content Rules The schema enforces rules that govern both the structure and the content of Active Directory. These rules validate changes to objects to ensure the integrity of the directory.

Structure rules Structure rules define the possible tree structures. When you create a new object, structure rules determine the validity of the object class to which you designate the new object. You cannot create an object that belongs to a nonexistent class. You must first create the new class. Conversely, these rules do not allow you to delete or modify an object that has already been deleted. In Active Directory, the structure rules are completely expressed by the possSuperiors and systemPossSuperiors attributes that are present on each classSchema object. These attributes specify the possible classes that can be parents of an object instance of the class. In other words, the possSuperiors and systemPossSuperiors attribute values determine the object classes and, therefore, the location in the directory tree under which objects of the class can be instantiated.

Content rules Content rules determine the mandatory and optional attributes of the class instances that are stored in the directory. New objects must contain all the mandatory attributes that are specified by the classSchema object in the schema. New objects can contain any of the optional attributes. In Active Directory, the content rules are completely expressed by the mustHave, mayHave,mayContain, systemMustContain, and systemMayContain attributes of the schema definitions for each class. In addition, there are some operational attributes that are read-only. These are identified by the first bit of the systemFlags property for an attribute definition that is set to 1, for example, lastLogon. For more information about mandatory and optional attributes, see Active Directory Schema in the Microsoft Platform SDK on MSDN. Top of page

Active Directory Schema Physical Structure The schema exists as a set of directory objects, and it is stored in the directory. Active Directory partitions the information in the directory to facilitate more efficient replication. The schema is stored in its own directory partition so that it can replicate independently of other data that is stored in the directory.

Schema Location The objects that are stored in Active Directory are arranged in a logical hierarchy called the directory tree. The directory tree is divided into directory partitions. A directory partition is a tree of objects that forms a unit of replication in Active Directory. The schema has its own directory partition to prevent potential dependency problems that can arise when new schema classes and new instances of the class are replicated simultaneously. Because the schema has its own tree, it is possible to replicate new schema changes to other domain controllers before replicating any new objects that may have been created based on those changes. This is important because the other domain controllers must have access to the object definitions that are stored in the schema before those domain controllers can properly store any new objects that are created by using those definitions. Active Directory includes a preconfigured database, commonly referred to as the base directory information tree (DIT), which contains the information that is required to install and run Active Directory. The base DIT is created during a fresh installation of a Windows Server 2003 domain controller. The base DIT is contained in a file named Ntds.dit. One section of the base DIT is the base schema.

Schema Head The schema head is the topmost object of the schema directory partition. Conceptually, the schema head functions like other containers in the directory tree, which means that it contains all of the schema information. However, the schema head is not a container in the sense of a special Active Directory object that contains other objects; rather, it is a special-purpose object class. Therefore, it is referred to as the schema head rather than the Schema container. The schema head contains all of the class definitions and attribute definitions that are required to locate objects in Active Directory and create new objects.

The relationships of the schema head, Configuration container, and Domain container are illustrated in the following figure. Schema Head

Every Active Directory object can be referenced by a unique and unambiguous name known as the distinguished name. The distinguished name identifies the domain that holds the object as well as the complete path through the container hierarchy by which the object is reached. The distinguished name of the schema head can be expressed as follows: cn=schema,cn=configuration,dc=forest rootdomainname You can view the contents of the schema head by using the Active Directory Schema snap-in. You can also bind to the schema directory partition and view schema objects by using the Active Directory Service Interfaces (ADSI) Edit snap-in or the Ldp tool. Note

•

ADSI Edit is not one of the default MMC snap-ins that are provided with Windows Server 2003. To use ADSI Edit and Ldp,

install the support tools that are located in the Support\Tools folder on the Windows Server 2003 operating system CD. You can locate the schema head without knowing the domain name. Installation scripts and other applications can gain access to the schema because they bind to a special entry at the top of the logical namespace, called the root DSA-specific Entry (rootDSE), which provides the schema location. rootDSE represents the top of the logical namespace and, therefore, the top of the LDAP search tree. The attributes of rootDSE identify, among other things, the directory partitions — that is, the domain, schema, and configuration directory partitions — as well as the forest root domain directory partition. One attribute, schemaNamingContext, provides the location of the schema so that applications that connect to any domain controller can find and read the schema.

subSchema Subentry rootDSE also carries a mandatory attribute called subSchemaSubEntry. The value of this attribute is the distinguished name of a subSchema object in the directory that defines the attributes (in attributeTypes) and classes (in objectClasses) that make up the Active Directory schema. This special object, which is an instance of the unique subSchema class, is used for administering information about the schema, in particular, the object classes and attribute types that are supported. This enables client applications to retrieve the schema information by querying the subSchema entry. Clients must only retrieve attributes from a subSchemaentry by requesting a base object search of the entry, where the LDAP search filter is (objectClass=subSchema). The following distinguished name describes the location of the SubSchemaSubEntry container: CN=Aggregate,CN=Schema,CN=Configuration,DC=DomainName,DC=DomainRoot For more information about LDAP searches, distinguished names, and containers, see “Data Store Technical Reference.”

Schema Files Active Directory data is distributed among all domain controllers in the forest. No single domain controller stores all Active Directory data for the entire forest, but every domain controller does hold a copy of the schema. The database that stores the Active Directory data on a particular domain controller is in a file named Ntds.dit. The location of the Ntds.dit file is an option that you can set during the domain controller promotion process while you create the directory. The default location for Ntds.dit and the database log files is systemroot\Ntds. For more information about the Ntds.dit file, see “Data Store Technical Reference.” Another file, the Schema.ini initialization file, contains the information that is necessary for creating the default directory objects and the default security for the directory tree, as well as the Active Directory display specifiers. Although this file is named Schema.ini, the schema itself is actually stored in the Active Directory database, Ntds.dit. Schema.ini is only used by the Active Directory Installation Wizard to build the initial schema structure in the directory during the domain controller promotion process. The Schema.ini file must not be modified. Top of page

Active Directory Schema Processes and Interactions Normally, you do not interact directly with the schema on a daily basis. Active Directory uses the schema to help create objects that are stored in the directory. You interact with those objects, not the schema. You interact directly with the schema when you make modifications to the schema by adding definitions to it or by modifying existing definitions. Schema changes can affect the entire directory. Before you make any changes to the schema, you should thoroughly test those changes in an isolated environment to ensure that the directory continues to function as planned after the changes have been deployed. Only members of the Schema Admins group can make changes to the schema. The two most common reasons for modifying the schema are:

• •

Installation of an application that needs to add customized object definitions so that it can store information in the directory, for example, an e-mail program that stores the user’s e-mail names in the directory Testing of the development of applications that use the directory for data storage in which customized object definitions need to be added to the schema and modified throughout their lifetimes as the development process proceeds

Modifying the Schema When the existing class and attribute definitions in the schema do not meet the needs of your organization, you can add or modify schema objects to extend the schema. You modify an existing attribute or add a new class or attribute to the schema to store a new type of information in the directory. The process of modifying or updating the schema is often referred to as extending the schema. Before you extend the schema, you must take steps to ensure that the extension does not cause problems in the directory. Do not extend the schema in your production forest without testing the extension in a private forest. First, make changes in a test environment, and check that the changes behave as expected and that they meet your needs. After verifying the changes, you can use various utilities, such as Ldifde, and scripts or customized applications to export the extensions from the test environment and import them into the production environment. You perform most schema extensions by using applications or scripts that are written to extend the schema. Note

•

As is true for every object in Active Directory, schema objects are protected by access control lists (ACLs). Therefore, only

authorized users can alter the schema. To add or modify a class definition or attribute definition, you add or modify the corresponding classSchema object or attributeSchema object. This process is similar to adding or modifying any object in Active Directory, except that additional checks are performed to ensure that changes do not cause inconsistencies or problems in the schema.

Adding Information to the Schema Extending the schema is a major change, with implications throughout the directory. Extend the schema only when it is absolutely necessary. Many schema modifications cannot be reversed; therefore, you must thoroughly plan and test changes before you deploy them in your production forest.

Planning to extend the schema Planning to extend the schema involves examining the default schema that comes with Active Directory to verify that there is no way to use the existing classes or attributes for your needs. It also involves understanding the types of modifications that can and cannot be made. For more information about modifying the schema, see “Active Directory Schema” in the Microsoft Platform SDK on MSDN.

Enabling schema extensions After you decide to make changes to the schema and you carefully plan the types of changes that you are going to make, you can proceed by implementing and testing the schema extensions in a test environment that is isolated from your production network. Because extending the schema is a significant operation, Active Directory has the following safety features, or interlocks, that restrict schema modifications:

• •

The Active Directory Schema snap-in must be registered. Active Directory Schema is not listed with the default MMC snapins. It must be registered before it can be made available. This means that Schmmgmt.dll must be registered by using Regsvr32.exe. Changes to the schema must be written only on the schema master. Although all domain controllers have a copy of the schema in their Active Directory database, only the domain controller that holds the schema operations master role (also

• •

known as flexible single master operations (FSMO)) is allowed to write changes to the schema. Administrators must have specific access rights. Only members of the schema administrators group (Schema Admins) or another administrator with explicit permission can make changes to the schema. Schema modifications must be enabled. By default, schema modification is disabled on all domain controllers, including the domain controller that hosts the schema operations master role.

Identifying or transferring the schema operations master role Active Directory performs schema updates in a single-master fashion to prevent conflicts such as conflicts resulting from simultaneous schema updates on two different computers. The one domain controller in the forest that is allowed to perform schema updates at any specific time is referred to as the schema master. The schema master is the domain controller that holds the schema operations master role. After the schema master completes an update, it replicates the changes to all other domain controllers by normal replication channels. In this way, changes to the schema are distributed throughout the forest. Note

•

To update the schema, the domain controller that holds the schema operations master role must be available on the network. All schema modifications must be made to the domain controller that holds the schema operations master role. If you attempt to modify the schema from a domain controller that does not hold that role, the domain controller generates

a referral to the current schema master to process the modifications. Because the schema master must be used to extend the schema, the domain controller that currently holds the schema operations master role in the forest must be identified. As the forest grows and changes, it may also become necessary to assign the schema operations master role to a different domain controller. You can accomplish both of these tasks by using Active Directory Schema or the command-line tool Ntdsutil. You can change the domain controller that serves as the schema master at any time. The current schema master in the enterprise is identified by the value of the FSMORoleOwner attribute on the schema head of the domain. By default, the first domain controller that is installed in the forest is the initial schema master.

Granting access rights to make schema changes To modify the schema, you must use an account that is a member of the Schema Admins group. By default, the only member in the Schema Admins group is the Administrator account in the root domain of the enterprise. You must explicitly add other accounts. You can use Active Directory Users and Computers in MMC to verify that an account is a member of the Schema Admins group. Restrict membership in the Schema Admins group to prevent unauthorized access to the schema. Improper modification of the schema can have serious consequences. By default, only members of the Schema Admins group have permission to write to the schema. You can grant explicit permissions to use Active Directory Schema to specific users. However, this is not recommended.

Enabling schema modifications on a domain controller If you want to allow the domain controller that holds the schema operations master role to modify the schema, use Active Directory Schema to enable schema modifications.

Removing Information from the Schema It is not possible to remove object definitions from the schema. However, object definitions can be rendered unusable through the process of deactivation. When an object definition is deactivated, it can no longer be used to create new objects in the directory. Objects whose definitions have been deactivated in the schema are referred to as defunct.

Deactivating schema objects You cannot deactivate schema objects that are part of the default schema that ships with Active Directory. You can freely deactivate schema objects that have been added to the default schema. As a result of replication latency, it is not possible to accurately determine if any objects have been created by using a given schema definition or to predict if the objects may be restored from backup media. Therefore, Active Directory does not support the actual deletion of schema objects. Rather, it provides a mechanism for deactivating schema objects in such a way that they become unavailable for use in the directory. Although a schema object still physically exists in the directory after it has been deactivated, new instances of it cannot be created in the directory. Any existing instances of data that are

associated with the deactivated schema object continue to exist in the directory; however, there is no way to modify these data instances other than to delete them. This behavior makes the schema object appear to be deleted from the schema. You can use Active Directory Schema or ADSI Edit to deactivate a class or an attribute by setting the attribute isDefunct to the Boolean value of TRUE on the schema object. You can use Active Directory Schema to view defunct schema objects: on the View menu, make sure that Defunct Objects is selected. In addition, you can write programs and scripts to search for all schema objects that have the attribute isDefunct set to TRUE. You can also use the Search function of the Ldp tool to search the schema with a filter that is set to isDefunct=TRUE. As with the addition or modification of classes or attributes, some special validation checks are performed on the deactivation of classes or attributes to ensure consistency of the schema. In particular, when you deactivate a class, Active Directory verifies that the class is not used in the subClassOf, auxiliaryClass, or possSuperiors attributes of any existing active class. Similarly, when you deactivate an attribute, Active Directory checks that the attribute is not used in the mustContain or mayContain attributes of any existing active class.

Deactivating existing classes and attributes Deactivation of schema classes and attributes is subject to the following restrictions:

• • •

You cannot deactivate a class or attribute that appears in the base Active Directory schema. You can only deactivate schema extensions of the base schema. You cannot deactivate an attribute that is referenced in the mustContain, systemMustContain, mayContain,systemMayContain, or rdnAttId properties of an active class. You cannot deactivate a class that is referenced in the subClassOf, auxiliaryClass, orpossibleSuperior properties of an

active class. To deactivate an attribute, set the isDefunctattribute of itsattributeSchema object to TRUE. When an attribute is deactivated, it can no longer be added to new class definitions. To reactivate an attribute, set the isDefunctattribute to FALSE. To deactivate a class, set the isDefunct attribute of its classSchema object to TRUE. When a class is deactivated, new object instances of the class can no longer be created. To reactivate a class, set the isDefunct attribute to FALSE.

Effects of deactivating a schema object on schema updates After a class salesUseris deactivated, any subsequent addition or modification of instances of salesUserfails as if salesUserhas been deleted from the system; the same error codes are returned as if salesUsernever existed at all. For example, creating a new instance of salesUserfails, and trying to modify or rename an existing instance of salesUserfails. Similarly, if an attribute hasPager is deactivated,hasPager is treated as nonexistent for new object creations, and attempting to modify (add or replace) the value of hasPagerin an existing object fails. However, you can still search for and delete existing instances of deactivated schema objects. For example, you can still search for all existing instances of salesUserand delete them, if necessary. Note that what you are doing is searching for and deleting objects that were created in the directory using the deactivated class, salesUser, not deleting the actual class definition from the schema. Similarly, you can search for all instances that have a value for the attribute hasPagerand delete hasPagerfrom the existing objects. This facilitates cleanup after a schema object is deactivated. If you decide that a class is not needed anymore, you can deactivate it so that no one can use it for any modifications. You can then clean up the existing instances of the class by searching for all instances and deleting them. Active Directory does not perform any automatic cleanup of data instances after a schema object is deactivated. Similarly, you can deactivate an attribute and clean up all its instances. Note that, for a deactivated attribute, you can delete only the entire attribute from an object, not certain values of the attribute. For example, ifhasPageris a multivalue attribute and an object has more than one value for hasPager, you cannot delete only one value of hasPagerfrom the object. In addition to affecting instances of the schema object, deactivating a schema object also affects schema updates, because schema object updates are subject to special validation checks. For example, if you deactivate the class salesUser or the attribute hasPager, subsequent schema object updates behave as follows:

•

Deactivated classes and attributes can be renamed in the schema. They can also be modified to make other changes to the corresponding classSchema and attributeSchema objects. Note that this behavior is different from the behavior of the Windows 2000 Active Directory schema, in which no modifications are allowed on defunct classes or attributes, except

•

modifications of the isDefunct attribute to reactivate the deactivated class or attribute. Validation checks that are performed when you add a new class or attribute or when you modify an existing nondefunct

class or attribute treat salesUser as nonexistent. For example, if hasPager is a defunct attribute, trying to modify an existing nondefunct class by adding mayContain=hasPager fails because the validation checks that are performed at schema modification time fail as if hasPager does not exist. Or, in the case of a defunct class salesUser, trying to add a new class with subClassOf=salesUser fails, because salesUser is treated as nonexistent by the validation checks that are performed during the addition of the class. There is an exception to the rule of defunct classes being treated as nonexistent in Windows 2000 Active Directory. When you try to add or modify a class or attribute so that it has the same distinguished name; object identifier (attributeID, governsID); lDAPDisplayName; mAPIID; or schemaIDGUID as the defunct class or attribute, the operation fails. In these cases, the class or attribute is treated as an active schema object from the standpoint of schema consistency checks during schema update operations. In Windows Server 2003, this behavior has changed. Defunct objects are still left in the directory. However, it is possible to create a new object that uses the same identification attribute values (that is, attributeID, governsID, lDAPDisplayName, mAPIID, or schemaIDGUID) as a defunct schema object, as long as the new object’s distinguished name is unique. This makes it possible to deactivate a schema object and then create an entirely new schema object — reusing the same values in its definition as the deactivated object — as if the old object were actually deleted. For example, you can change the canonical name (CN) of a defunct object so that you can reuse its old name in the definition of a new schema object. This is very valuable for developers who must constantly modify various classes and attributes for testing purposes. It is possible now to mark an old version of an object definition as defunct and install a new version of the object that uses the same identifiers, making it much easier to develop and test applications that interact with the directory. This ability to make schema objects defunct can be very useful in different ways in production environments. You can clean up schema objects that are no longer needed by making them defunct. Defunct schema objects are not visible in Active Directory Schema unless you specifically select them on the View menu. Then, you can delete existing instances of those classes or attributes if you want to. At the same time, if you need a schema object later, you can reactivate it by modifying the isDefunct attribute on the object. This also protects against the accidental removal of a schema object by making it defunct. Making a schema object defunct can be reversed easily with no side effects. Note that because Active Directory does not do any cleanup of data instances after a schema object is made defunct, all instances of the schema object that are made defunct by mistake remain and become valid data when the defunct schema object is made active again.

Reactivating schema objects You can reactivate a defunct schema object either by removing the isDefunct attribute from the object or by setting the value of the isDefunctattribute to FALSE. You can perform both operations by using either Active Directory Schema or ADSI Edit. Because reactivating a defunct schema object requires schema updates that are similar to adding a new schema object, Active Directory performs the same validation checks as it does when you add a new schema object. The following validation checks are performed when a defunct schema object is reactivated:

• • •

A defunct class cannot be reactivated unless the attributes that are referenced in its mustContain, systemMustContain, mayContain,systemMayContain, or rdnAttId attributes — as well as the classes that are referenced in its subClassOf, auxiliaryClass, and possibleSuperior attributes — are already active. A defunct class cannot be reactivated if the value of any of the attributeslDAPDisplayName, governsID, orschemaIDGUID is the same as the value that is stored in an already active class or attribute. A defunct attribute cannot be reactivated if the value of any of the attributeslDAPDisplayName, attributeID,

schemaIDGUID, mAPIID is already in use by an active class or attribute. A defunct schema object can be reactivated at any time. The only restriction is that the isDefunct attribute should be the only attribute that is present in the modify call. This helps prevent any ambiguity problems while schema consistency checks are performed.

Updating the Schema Cache When changes are made to Active Directory, they are validated against the schema, which can affect domain controller performance. The schema is stored in the directory database. Because all changes are validated against the schema, they result in queries of the schema in the directory database, which can increase the workload on a domain controller. To make the operation more efficient, domain controllers cache the schema in memory. Anytime the schema is updated, the schema cache is also updated automatically.

After the domain controller is started, the schema cache is loaded from the schema information in the underlying database and updated automatically whenever the schema is updated. When changes are made, the schema cache is updated automatically within five minutes after the first change is applied. During the interval before the schema updates are copied to the schema cache, objects that reference a new or modified class or attribute cannot be added. If another domain controller attempts to use the new schema modifications, a replication interval must pass before the change becomes available. This behavior keeps the cache consistent, but it can be confusing because changes are not apparent until the cache is updated, even though they are applied to the directory database. When a change is replicated to a domain controller from a replication partner, the cache is updated immediately, without the five-minute delay. You can update the schema cache by adding the schemaUpdateNow attribute to rootDSE with a value of 1. The value is not used; it acts as a trigger or operational attribute. You can write this attribute to start a cache reload. Adding the schemaUpdateNow attribute causes a schema cache update to start immediately. The update operation is “blocking,” which means that no other modifications can be made until this operation is complete. This prevents multiple changes from being made to the schema simultaneously. If the operation finishes with no errors, the cache is updated and all schema updates are ready to be used. The return of an error, however, indicates that the cache update is not successful. Applications that add the schemaUpdateNow attribute should be designed to accommodate the blocking write, particularly to provide feedback if the program or script runs interactively. You can also update the schema cache immediately by using Active Directory Schema: in the console tree right-click Schema, and then click Reload the Schema. Note

•

If you must make multiple changes to the schema, complete all changes before forcing an immediate schema cache update, rather than forcing an update after each change. Multiple cache loads can result in increased workload on the server.

Default Security Settings for Active Directory Objects The default security descriptor for an Active Directory object is specified in the schema. When a new object is created, Active Directory configures the default access rights for that new object. The security descriptor contains the settings that are used to configure the default access rights, and the security descriptor is stored in the schema as part of that object types definition. Note

•

There are special cases in which default security is not applied on newly created objects. For more information about access rights, see “Active Directory Schema” in the Microsoft Platform SDK on MSDN.

Default security settings for the domain directory partition The domain directory partition object is derived from the object class domainDNS. Therefore, the default security of the domain directory partition object is equivalent to the default security for domainDNS. The default security descriptor for the domain directory partition includes the following permissions:

• • • • •

Full Control to the Domain Admins group and the System group and Read to the Authenticated Users group. Read on all properties to the Everyone group. This permission provides backward compatibility for application programming interfaces (APIs). Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Enterprise Domain Controllers group. These permissions allow members of the Enterprise Domain Controllers group to manage replication automatically. Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Builtin Administrators group. Administrators of individual domain controllers can use these permissions to troubleshoot replication problems. Inheritable Full Control to the Enterprise Admins group. Enterprise Admins, by definition, have complete control of each domain.

• •

Inheritable List Contents to the Pre–Windows 2000 Compatible Access group.

• •

Inheritable Read on all Group objects.

Inheritable Read Property on Remote Access Service (RAS) Information, General Information, Membership, User Account Restrictions, and User Logon on all User Objects permissions to the Pre–Windows 2000 Compatible Access group. Inheritable Auditing successful/failed writes to the Everyone group. Activating the auditing policy ensures that writes that are performed on any object in the directory are audited immediately, without the need for extra user intervention.

Inheritable access control entries (ACEs) provide a convenient way to remove auditing policy.

Default security settings for the configuration directory partition The default security descriptor for the configuration directory partition includes the following permissions:

• •

Full Control to the Domain Admins group and System and Read to the Authenticated Users group. Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Enterprise Domain Controllers group. These permissions enable domain controllers in the forest to replicate from each other and automatically reconfigure the replication topology on the basis of replication delays and latency for the configuration

• • •

directory partition. Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Builtin Administrators group. These permissions enable administrators from individual domain controllers to synchronize replication and topology management for the configuration directory partition. Enable Inheritable Full Control to the Enterprise Admins group. This permission allows members of the Enterprise Admins group exclusive control over the Configuration container. The Enable Inheritable Full Control permission is required to control the Configuration container throughout the forest. Enable Inheritable Auditing to the Writes by the Everyone group. Activating the auditing policy ensures that writes that are performed on any object in the directory are audited immediately, without the need for extra user intervention. Inheritable ACEs provide a convenient way to remove auditing policy.

Default security settings for the schema directory partition The default security descriptor for the schema directory partition includes the following permissions:

• • • • • • •

Write access to the schema head to the Schema Admins group. Change Schema Master control permission to the Schema Admins group. This permission enables members of the Schema Admins group to change which domain controller holds the schema operations master role. Inheritable Full Control permission to the Schema Admins group. By default, the Schema Admins group is the only group that has Write access to the entire schema head. A schema object does not have any exclusive control over its own security; therefore, the object inherits its security from the schema head. Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology to the Enterprise Domain Controllers group. These permissions enable the members of the Enterprise Domain Controllers group to manage replication of the schema in the forest automatically. Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Builtin Administrators group. These permissions enable the administrators of domain controllers to resolve replication issues. Read permissions to the Authenticated Users group. This permission gives the members of the Authenticated Users group the right to read the schema. Audit successful/failed writes to the Everyone group. Activating the auditing policy ensures that writes that are performed on any object in the directory are audited immediately without the need for extra user intervention. Inheritable ACEs provide a convenient way of removing auditing policy.

Default security settings for attributes and classes All attributes and classes inherit security from the ACLs on the schema head. This ensures that security for the entire schema is consistent. Note

•

The default security settings allow Write access to the schema head only to the Schema Admins group.

Issues Related to Modifying the Schema Three main issues relate to modifying the schema:

• • •

The impact on replication Managing concurrent schema modification operations Handling invalid object instances

Impact on replication

Because the schema is replicated across all domain controllers in the forest, a schema update that is performed at one domain controller is propagated throughout the forest. This guarantees that the schema is consistent across the forest. However, because of replication latencies, there can be temporary inconsistencies. Active Directory solves this problem by explicitly replicating the schema head from the originating server when failures occur. Additionally, the replication of the schema head triggers an immediate schema cache update on the target server. Active Directory then replicates the failed object again.

Managing concurrent schema modification operations Programs that modify the schema should not be run concurrently unless the programs include provisions to check that schema modifications that are made by one program will not conflict with schema modifications that are made by the other programs. Active Directory must ensure that different program threads do not perform simultaneous, conflicting schema updates, such as one thread deleting an attribute when another thread is adding the attribute to the mayContain list of a class. To ensure that different program threads do not perform simultaneous, conflicting schema updates, any thread that attempts to perform a schema update also writes a special attribute on the schema head automatically as part of the transaction. Active Directory automatically causes the thread to write the attribute so that you do not have to do so in your program code. Only one thread can write this attribute at any one time. This method guarantees schema consistency, but it does not guarantee which of the updates is successful. This is an important consideration when schema updates are made in a batch, such as during the installation of directory-enabled applications. For example, consider a scenario in which two programs, program A and program B, are being installed simultaneously. Both programs are designed to create several new schema objects. Because Active Directory creates one thread per object update, it is possible that some of the objects in program A and some of the objects in program B are created (if the internal threads do not overlap). Then, one of the installations fails because a thread for a schema object creation for program A overlaps with a thread for a schema object creation for program B. Assume that program A fails because of the thread conflict and the resulting failure to create some of the needed schema objects. Attempting to reinstall program A again does not work because some of the objects that program A created are already in the schema, and trying to create them again in the second run returns an error.

Handling invalid object instances Schema updates can make an existing instance of an object invalid. For example, suppose a user account object, JohnDoe, is an instance of classSalesEmployee. The classSalesEmployee class has an attribute, POBox, in its mayContain list. Therefore, because JohnDoe is an instance of classSalesEmployee, JohnDoe can have the POBox attribute defined in it. Assume that JohnDoe does have this attribute currently defined in it. A schema update is performed that modifies classSalesEmployee by deactivating the attribute POBox from its mayContain list. Note that this change makes the instance of JohnDoe invalid because JohnDoe now has an attribute, POBox, that it is not allowed to have according to the class definition of classSalesEmployee (of which JohnDoe is an instance). Active Directory allows the now-invalid objects to remain in the directory and ensures that they do not cause problems in the rest of the schema. Active Directory does not automatically clean up invalid objects, but invalid objects and attributes appear in searches and can be deactivated manually.

Interoperating with Other Directories To provide more support for industry standards in Active Directory, the schema supports the inetOrgPerson object class and the use of a standard file format for importing and exporting schema modifications.

inetOrgPerson Object Class The Active Directory schema in Windows Server 2003 supports the inetOrgPerson object class. The inetOrgPerson object class and its associated attributes are defined in RFC 2798. The inetOrgPerson object class is used in several non-Microsoft LDAP and X.500 directory services to represent users in the directory. Support for inetOrgPerson makes migrations from other LDAP directories to Active Directory more efficient. The inetOrgPerson class was added by adding new attributes to the schema and deriving inetOrgPerson from the user class and the new attributes. As a result, inetOrgPerson can be used as a security principal.

inetOrgPerson in Windows Server 2003 To help organizations migrate their applications and directory data to Active Directory, the inetOrgPerson class has been added to the base schema. The definition of the inetOrgPerson class is based on RFC 2798. However, some issues have caused the Active Directory definition of this class to differ from the RFC definition, as follows:

• •

The inetOrgPerson class is derived from the user class, not the organizationalPerson class. This makes it possible for inetOrgPerson to operate as a security principal. Accounts that are created as inetOrgPerson objects can log in to Active Directory. Attributes that are already defined in the base schema are not changed. Several attributes in the base schema are defined as single-value instead of multivalue, or the reverse, as defined in the RFC 2798. The object identifier of some attributes differs from the definition in the RFC. Changing the definition of these attributes in the base schema to match the RFC causes backward compatibility problems with the Windows 2000 Active Directory schema and may result in application problems. For example, Microsoft Outlook will not display the data for attributes that have an unexpected value for the isSingleValued attribute. Active Directory management tools may

•

treat the attributes incorrectly and inadvertently overwrite data or fail to update them at all. The inetOrgPerson class inherits two mandatory attributes:

• •

The cn attribute is used to name a new instance of the class. The samAccountName attribute is the user’s login ID. The objectCategory attribute for inetOrgPerson is set to Person. This has the effect of returning all user, computer, and inetOrgPerson objects when the filter in a query is objectCategory=Person.

Importing and Exporting Directory Information Active Directory supports the use of files that are formatted with LDAP Data Interchange Format (LDIF) for importing and exporting information in the directory. This includes information that is stored in the schema, such as schema modifications. LDIF is an industry-standard, ASCII, text-based file format that can be used to define data in a text file that is used to import information, such as schema modifications, into LDAP-based directories. LDIF is defined in RFC 2849. After an LDIF file is created, a tool such as Ldifde.exe, which is available in Windows Server 2003, performs the import operation using the data file for input. Ldifde.exe can also be used to export data from the directory. Exported data is also stored using the LDIF file format to make it easier to import the data into another LDAP-based directory. For more information about LDAP, see “Data Store Technical Reference.” Top of page

Active Directory Schema Tools and Settings Updated: March 28, 2003

Active Directory Schema Tools and Settings In this section

• •

Active Directory Schema Tools Related Information

When existing class and attribute definitions in the Active Directory schema do not meet the needs of your organization, you can use schema-based administrative tools to modify or add schema objects. You can modify an existing attribute or add a new class or attribute to the schema to store a new type of information in the directory. The process of modifying or updating the schema is often referred to as “extending the schema.” In addition to using schema tools to extend the schema, you can perform most schema extensions by using customized applications or Active Directory Service Interfaces (ADSI) scripts. Note

•

Extending the schema is a major change with implications for the entire directory. Extend the schema only when it is absolutely necessary. Many schema modifications cannot be reversed; therefore, you must thoroughly plan and test

changes in an isolated environment before you deploy them in your production forest. This section contains information about the tools that are associated with the Active Directory schema. Top of page

Active Directory Schema Tools

Normally, you do not interact directly with the schema on a daily basis. Active Directory uses the schema to create objects that are stored in the directory. You interact with those objects, not with the schema. You interact directly with the schema when you make modifications to the schema by adding definitions to it or by modifying existing definitions. Only members of the Schema Admins group can make changes to the schema. The two most common scenarios for modifying the schema are as follows:

• •

You install an application that adds customized object definitions so that it can store information in the directory; for example, you install an e-mail program that stores user e-mail names in the directory. You test the development of applications that use the directory for data storage. In this scenario, you add customized

object definitions to the schema and modify them throughout their lifetimes as the development process proceeds. Note

•

Changes to the schema must be written only on the schema master. Although all domain controllers have a copy of the schema in their Active Directory database, only the domain controller that holds the schema operations master role (also

known as flexible single master operations (FSMO)) is allowed to write changes to the schema. The following tools are associated with the Active Directory schema.

Adsiedit.exe: ADSI Edit Category ADSI Edit is included when you install Support Tools for Windows Server 2003. Version Compatibility

Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional ADSI Edit is a Microsoft Management Console (MMC) snap-in that uses ADSI, which uses the Lightweight Directory Access Protocol (LDAP). You can use ADSI Edit to view and modify directory objects in the Active Directory database. You can also use it to view schema directory partition objects and properties. When you open ADSI Edit, the Schema container is displayed by default. You can expand the container to view schema classes and attributes. To find more information about ADSI Edit, see “Support Tools Help” in Tools and Settings Collection.

Csvde.exe: Csvde Category Csvde is a command-line tool that ships with Windows Server 2003. Version compatibility

Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional The comma-separated value (CSV) file format is a simple format whose primary benefit is ease of use. In the CSV file format, each line represents a discrete object in the directory, and the object’s attributes are separated by commas. The first line of the file always contains all of the attribute names. Each subsequent line represents a different entry in the directory. Values for multivalue attributes can also be specified, and they are delimited by semicolons (;). Because this format is compatible with the Microsoft Excel CSV format, you can use Csvde.exe to export directory information to an Excel spreadsheet or to import data from a spreadsheet into Active Directory. You can use this format only for additions to the directory. Csvde.exe cannot be used to modify or delete objects. Csvde.exe also supports batch operations that are based on CSV. The parameters that are used for the Csvde.exe tool are the same as the parameters that are used for the Ldifde.exe tool. However, unlike Ldifde.exe, Csvde.exe can export data from Active Directory into files that can be read by certain applications. For example, if you want to view all Active Directory users in an Excel report, you can use Csvde.exe to export the directory data into the CSV file format, which you can then read in Excel. To find more information about Csvde.exe, see “Command-Line References” in Tools and Settings Collection.

Dsa.msc: Active Directory Users and Computers Category Active Directory Users and Computers is an MMC snap-in in Administrative Tools that is installed automatically on all domain controllers running Windows Server 2003. Version compatibility

Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition

• Windows 2000 Server • Windows 2000 Advanced Server

Can Be Run From

Can Be Run Against

• Windows Server 2003, Enterprise Edition

• Windows 2000 Datacenter Server

• Windows Server 2003, Datacenter Edition • Windows Server 2003, Web Edition Computers running:

• Windows XP Professional with Adminpak.msi installed Active Directory Users and Computers is a graphical user interface (GUI) tool that you can use to manage users and computers in Active Directory domains. To modify the schema, you must use an account that is a member of the Schema Admins group. By default, the only member in the Schema Admins group is the Administrator account in the root domain of the enterprise. You must explicitly add other accounts. You can use Active Directory Users and Computers to verify that an account is a member of the Schema Admins group. Restrict membership in the Schema Admins group to prevent unauthorized access to the schema. Improper modification of the schema can have serious consequences. By default, only members of the Schema Admins group have permission to write to the schema. You can assign explicit permissions to use the Active Directory Schema snap-in to specific users; however, this is not recommended.

Ldifde.exe: Ldifde Category Ldifde is a command-line tool that ships with Windows Server 2003. Version compatibility

Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

•

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional Active Directory supports the use of files that are formatted with the LDAP Data Interchange Format (LDIF) for importing and exporting information in the directory. This includes information that is stored in the schema, such as schema modifications. After an LDIF file is created, a tool such as Ldifde.exe performs the import operation by using the LDIF file for input. You can also use Ldifde.exe to add, modify, and delete directory objects; export Active Directory user and group information to other applications or services; and populate Active Directory with data from other directory services. To find more information about Ldifde.exe, see “Command-Line References” in Tools and Settings Collection.

Ntdsutil.exe: Ntdsutil Category Ntdsutil is a command-line tool that ships with Windows Server 2003. Version Compatibility

Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Ntdsutil.exe provides advanced management capabilities for Active Directory. For the Active Directory schema, you can use Ntdsutil.exe to identify, transfer, or seize the schema operations master role. This tool is intended for use by experienced administrators. To find more information about Ntdsutil, see “Command-Line References” in Tools and Settings Collection.

Schmmgmt.msc: The Active Directory Schema snap-in Category The Active Directory Schema snap-in is an MMC snap-in in Administrative Tools that is installed automatically on all domain controllers running Windows Server 2003. However, you must register it manually before you use it for the first time. Version compatibility

Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional with Adminpak.msi installed The Active Directory Schema snap-in is a GUI tool that members of the Schema Admins group can use to manage Active Directory objects and their associated attributes. You can use this tool to create and modify classes and attributes. You can also use it to specify what attributes are indexed and what attributes are replicated to the global catalog. The Active Directory Schema snap-in is not one of the default MMC snap-ins that is provided with Windows Server 2003. To make it appear in the list of available snap-ins, install the Windows Server 2003 Administration Tools Pack (Adminpak.msi). To register the Active Directory Schema snap-in, run Regsvr32 Schmmgmt.dll from the command prompt or from the Run command on the Start menu.

ADSI and Visual Basic Scripts Active Directory provides a set of interfaces that you can use programmatically to gain access to directory objects, including schema objects. ADSI conforms to the Component Object Model (COM), and it supports standard COM features. ADSI defines a directory service model and a set of COM interfaces that you can easily use with a variety of programming languages. With Microsoft Visual Basic, Scripting Edition and ADSI, you can write scripts to modify the directory in various ways, including extending the schema. For more information about using ADSI and scripting to modify the schema, see Using Active Directory Service Interfaces in the Microsoft Platform SDK on MSDN. Top of page

Data Store Technical Reference Updated: March 28, 2003

In the Active Directory directory service, the data store contains database files and processes that store and manage directory information for users, services, and applications. A copy of the data store runs on each domain controller in the forest. The data store provides access to directory information through a process called the Directory System Agent (DSA). The data store holds directory information in a database file called Ntds.dit. The Active Directory data store is often referred to as the directory.

What Is the Data Store? Updated: March 28, 2003

In this section

• • • •

The Business Need

• •

Data Store Dependencies

The Data Store Solution Data Store Scenarios Directories and Databases Related Information

In Active Directory, the data store contains database files and processes that store and manage directory information for users, services, and applications. A copy of the data store runs on each domain controller in the forest. The Active Directory data store is often referred to as the directory.

The Business Need Organizations generate and store data about many different kinds of entities (computers, users, services, and so on) that exist in their information technology (IT) infrastructure. Historically, organizations maintain this information in multiple locations and formats. For example, an organization might store employee information in a human resources database, application data in an application-specific database, Quality of Service (QoS) rules on routers, and security information (user name and password) on a network server. Storing, managing, and making available many disparate data sets is expensive and time consuming. Top of page

The Data Store Solution The Active Directory data store solves the problem of managing disparate data sets across an organization. The data store is a single, general-purpose database that can hold many types of data and distribute that data to users anywhere on the network. The following figure illustrates the use of the Active Directory data store as a single, general-purpose database for all of an organization’s data. Data Store

The Active Directory data store achieves the following major design goals:

• • • • • •

To provide distributed access to the directory by users and applications, a copy of the data store resides on all domain controllers in a domain or forest. To provide standard interfaces for accessing data, the data store includes a Lightweight Directory Access Protocol (LDAP) interface and a Messaging API (MAPI) interface. To support quick searches of directory data, the data store includes efficient query and index mechanisms. To ensure scalability, the data store uses a hierarchical, or tree, model that supports partitioning. The data store also ensures scalability by automatically managing database growth and increasing the database file size when necessary. To support both full and incremental restoration of data, the data store uses a transactional model, logging uncommitted transactions in log files. To ensure data consistency, the data store enforces a set of extensible data type and format constraints, called the schema.

Top of page

Data Store Scenarios Active Directory is required for the deployment and operation of Windows Server 2003 domains and forests. The data store is a key and required part of any Active Directory deployment. Therefore, the data store exists in any Windows Server 2003 domain or forest. Use of the data store can be further delineated into two main scenarios, based on the type of data that is stored. These scenarios are the network operating system (NOS) directory scenario and the NOS and application directory scenario.

NOS Directory Scenario In the NOS directory scenario, an organization uses the data store only for storage of NOS-related information, including information about users, computers, services, printers, and so on. This scenario applies to organizations that are not running directory-enabled applications (applications that can communicate with and store data in a directory data store) or to organizations that are using a different directory data store than Active Directory for storing application data. In this scenario, you can manage the data in the data store by using the command-line and graphical user interface (GUI) tools that are provided with Windows Server 2003.

NOS and Application Directory Scenario In the NOS and application directory scenario, directory-enabled applications that are not a part of the NOS use the data store to hold application-specific data. Examples of directory-enabled applications include messaging, customer relationship management (CRM), enterprise resource planning (ERP), and document management applications. In this scenario, the schema (the set of rules that define the type and formatting of data) is generally extended to include data definitions that are specific to the directory-enabled applications that use the data store. Top of page

Directories and Databases In the context of directory services, questions often arise regarding the differences between directories and databases. The Active Directory data store shares many aspects in common with databases, including the storage of data in rows and columns and the use of a hierarchical data model. A directory differs from a database primarily in its intended use. A directory is optimized for read operations, while a database is optimized for write and change operations. Therefore, any data that is read many more times than it is written or modified is a good candidate for storage in a directory.

A directory also typically differs from a database in the protocols that it uses to access information in the data store. A directory, such as Active Directory, is most often accessed with LDAP. A database is most often accessed with an interface such as Structured Query Language (SQL). Top of page

Data Store Dependencies The Active Directory data store depends on several related technologies and resources for its proper functioning. The following sections describe these technologies and resources.

NTFS The data store requires a disk volume that is formatted with the NTFS file system. NTFS is more powerful than FAT16 or FAT32, and NTFS includes features that are required for hosting Active Directory. For more information about NTFS, see “NTFS Technical Reference.”

Network Connectivity So that users and computers can access the data store, and to support replication of the data store between domain controllers, network connectivity with TCP/IP is required. For more information about networking and TCP/IP, see “TCP/IP Technical Reference.”

Active Directory Replication Except for very small networks, directory data must reside in more than one place on the network to be equally useful to all users. Through the process of replication, Active Directory maintains copies, or replicas, of the data store on each domain controller in the forest, which helps to ensure data availability and performance for all users. For more information about replication, see “Active Directory Replication Model Technical Reference.”

FRS The File Replication service (FRS) is a process that is associated with the Distributed File System (DFS). FRS is used by Active Directory to replicate the system volume (SYSVOL) between domain controllers. SYSVOL holds certain kinds of Active Directory information, including Group Policy objects (GPOs) and scripts. For more information about FRS, see “FRS Technical Reference.”

Disk Space There are no practical limits to the number of objects that can be stored in the Active Directory data store. The Active Directory directory database has been tested for up to 40 million objects. Performance tests show logon performance for a single LDAP client to be the same with 10,000 objects, 100,000 objects, and 1 million objects; that is, the directory service does not slow measurably when the size of the database increases. The minimum free disk space requirements for the directory database and log files depend on the size of the database. On partitions that hold the database only (and not the database log files), free disk space must not fall below the greater of 20 percent of the disk space that is consumed by the database or 500 megabytes (MB). On disk volumes that hold the database and the database log files, free disk space must not fall below the greater of 20 percent of the combined size of the Ntds.dit and log files or 1 gigabyte (GB). For more information about the Ntds.dit and log files, see “How the Data Store Works.”

How the Data Store Works Updated: March 28, 2003

In this section

• • • • • •

Data Store Architecture Data Store Protocols Data Store Interfaces Data Store Logical Structure Data Store Physical Structure Data Store Processes and Interactions

• •

Network Ports Used by the Data Store Related Information

In Active Directory, the data store contains database files and processes that store and manage directory information for users, services, and applications. A copy of the data store runs on each domain controller in the forest. The Active Directory data store is often referred to as the directory. The ideal environment for the data store includes the following:

• • • • •

A domain controller running an operating system in the Windows Server 2003 family and containing hardware that meets the minimum hardware requirements of the edition of the operating system (Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition) For environments consisting of multiple domain controllers, the presence of a fully functioning Active Directory replication topology For environments consisting of multiple domain controllers, the presence of a fully functioning File Replication service (FRS) topology A regular backup schedule Regular monitoring of Active Directory, either through manual review of event logs or through an automated monitoring

solution, such as Microsoft Operations Manager (MOM) This section describes the elements of the Active Directory data store, including its architecture, protocols, interfaces, logical structure, physical structure, processes and interactions, and network ports.

Data Store Architecture The Active Directory data store consists of several components that together provide directory services to directory clients and to other directory servers. These components include three service components, four interfaces, and the directory database where data is actually stored. The following figure illustrates the architecture of the data store. Data Store Architecture

The following table describes the components of the data store. Data Store Components

Component

Description

Interfaces: Lightweight Directory Access

The data store interfaces provide a way for directory clients and other directory

Protocol (LDAP), replication (REPL) and

servers to communicate with the data store.

domain controller management interface, Messaging API (MAPI), Security Accounts Manager (SAM)) Directory System Agent (DSA) (Ntdsa.dll)

The DSA, which runs as Ntdsa.dll on each domain controller, provides the interfaces through which directory clients and other directory servers gain access

Component

Description to the directory database. In addition, the DSA enforces directory semantics, maintains the schema, guarantees object identity, and enforces data types on attributes.

Database layer

The database layer is an application programming interface (API) that resides in Ntdsa.dll and provides an interface between applications and the directory database to protect the database from direct interaction with applications. Calls from applications are never made directly to the database; they go through the database layer. In addition, because the directory database is flat, with no hierarchical namespace, the database layer provides the database with the abstraction of an object hierarchy.

Extensible Storage Engine (ESE) (Esent.dll)

The ESE, which runs as Esent.dll, manages the tables of records — each with one or more columns — that make up the directory database.

Database files

The data store stores directory information in a single database file called Ntds.dit. In addition, the data store also uses log files, to which it temporarily writes uncommitted transactions.

The DSA, database layer, and ESE are described in the following sections. For information about the interfaces, see “Data Store Interfaces" later in this section. For information about the database files, see “Data Store Physical Structure” later in this section.

DSA The DSA runs on every domain controller as Ntdsa.dll, and it provides access to the directory database. The DSA runs as part of the Local Security Authority (LSA) process (Lsass.exe), which manages authentication packages and authenticates users and services. Running in Lsass.exe enables Active Directory to securely manage sensitive information, such as account passwords. Clients can use one of the supported interfaces to connect (bind) to the DSA and then search for, read, and write to Active Directory objects and their attributes. A forest-wide object in the directory, the NTDS Settings object (class nTDSDSA), represents the DSA on a domain controller, and this object contains configuration information about the DSA on that domain controller. In addition to providing the interfaces through which directory clients gain access to directory data, the DSA provides the following functionality.

Object identification Every object in Active Directory has a permanent globally unique identifier (GUID), which is associated with several string forms of the object name (SAMAccountName, user principal name, and distinguished name), as well as a security identifier (SID). The object names and the SID are not permanent; that is, they can be changed. All permanent references to the object are kept in terms of the GUID. The object name is used for hierarchy navigation and display purposes, and the SID is used for access control. The DSA maintains the GUID association with an object when the object’s string name or SID changes, for example, when the object is moved to a different folder (the string name changes) or when the object is moved to a different domain (the string name and the SID change).

Schema enforcement The DSA ensures that data in the directory adheres to the data definitions that are provided by the directory schema. The schema is the set of rules that determines what kind of data the directory can hold. Note

•

In Windows 2000 Server and Windows Server 2003 forests, if an update does not produce a conflict with the schema at the originating replica, the update is considered acceptable at all replicas. Therefore, replicated updates do not perform schema checks, and you do not have to wait until the schema replicates before creating instances of a new object or attribute. For more information about replication, see “Active Directory Replication Model Technical Reference”.

Access control enforcement The DSA enforces security limitations in the directory by reading SIDs on the access token.

Support for replication The API that is called to initiate replication is implemented in the DSA.

Referrals The DSA manages the directory hierarchy information (referred to as knowledge), which it receives from the database layer. The DSA is responsible for cross-references of Active Directory domain objects.

Functional levels Beginning with Windows Server 2003 domain controllers, the DSA has a built-in numeric value that identifies its operating system version — and therefore its functional capabilities — to other services. Services that rely on the DSA can use this numeric value to determine which of their service features to enable.

DSA GUID and Invocation ID Both the DSA and the Active Directory database are represented uniquely and have their own respective GUIDS. The DSA GUID is the GUID of the NTDS Settings object (class nTDSDSA). The value of the DSA GUID is stored in the objectGUID attribute of the NTDS Settings object of the given domain controller server object, which resides in the Sites container in the configuration directory partition. Domain controllers use the DSA GUID to locate replication partners. Replication uses a special Domain Name System (DNS) name that contains the DSA GUID. This GUID-based DNS name is an alias for the local computer name. The Net Logon service registers this alias resource record in DNS in the form of the CNAME (canonical name) resource record. The DSA GUID is created when the domain controller is initially promoted, that is, when Active Directory is installed. The DSA GUID is destroyed only if Active Directory is removed from the domain controller. The DSA GUID ensures that the DSA remains recognizable when a domain controller is renamed. The DSA GUID is also not affected by the Active Directory backup and restore process. The Active Directory database has its own GUID, which the DSA uses to identify the database instance (the version of the database). The database GUID is stored in the invocationId attribute on the nTDSDSA object. Unlike the DSA GUID, which never changes for the lifetime of the domain controller, the invocation ID changes during the Active Directory restore process to ensure the consistency of the replication process. On domain controllers running Windows Server 2003, the invocation ID also changes when an application directory partition is removed from or added to the domain controller.

Database Layer The database layer is an API that resides in Ntdsa.dll and provides an object view of the directory database, making the data accessible to the DSA as a set of hierarchical containers. By applying schema semantics to database records, the database layer isolates the upper components of the directory service from the underlying database system. The database layer is an internal interface. No database access calls are made directly to the ESE; instead, all database access is routed through the database layer. In the directory database, each object is identified by its relative distinguished name, which is unique in the object’s parent container. The relative distinguished name and the chain of successive parent object names make up the object’s distinguished name. The database stores the relative distinguished name for each object, as well as a reference to the parent object. The database layer follows these parent references and concatenates the successive relative distinguished names to form distinguished names, thereby defining the object hierarchy. The database layer is also responsible for the creation, retrieval, and deletion of individual records (objects), attributes within records, and values within attributes. To carry out these functions, the database layer uses the schema cache (an in-memory structure in the DSA) to get the information about the attributes that it needs.

ESE The Extensible Storage Engine (ESE) is a Windows component that is used by Active Directory, as well as by several other Windows components, as an interface to the data that is stored in an indexed and sequential access method (ISAM)

database. (The Active Directory database is an ISAM database.) The ESE is responsible for indexing the data in the database file and for transferring the data in and out of the database. Its purpose is to enable applications to store and retrieve data by using the ISAM. The ESE provides applications with a consistent data state by means of transacted data update and retrieval. A crash recovery mechanism maintains data consistency, even in the event of a system crash. Transactions in the ESE are highly concurrent, making the ESE suitable for server applications. The ESE caches data intelligently to ensure highperformance access to data. In addition, the ESE is resource efficient, making it suitable for applications that perform auxiliary roles. The version of the ESE that runs on domain controllers running Windows Server 2003 and Windows 2000 Server is implemented in Esent.dll. The following characteristics of the ESE make it well suited to the storage needs of Active Directory. The ESE:

• • • • • •

Supports databases of up to 16 terabytes (TB) in size, and it can hold many millions of objects per domain.

•

The encrypting file system (EFS) enables users to encrypt individual files, folders, or entire data drives. Because EFS

Supports indexing. Supports multivalued attributes. Supports update operations that are transacted for stability and integrity across system failures. Can be backed up while the domain controller is online. Handles sparsely populated objects well; that is, space in the database is not reserved for attributes that do not have

values. Note initialization and domain controller startup occur in parallel, EFS recovery operations can interfere with the ability of the

ESE to start Active Directory and cause domain controller startup to fail. The Active Directory schema defines all the attributes that are required and allowed for a given object. However, the ESE reserves storage only for the space that is used — that is, only for the attributes that have values, not for all possible attributes. For example, if a user object has 50 attributes defined in the schema and you create a user with values for only 4 attributes, storage space is allocated only for those 4 attributes. If more attributes are added later, more storage is allocated for them. The ESE implements the search and retrieval functionality of the underlying database. Also, the ESE is able to store attributes that can have multiple values. For example, the database can store multiple phone numbers for a single user without requiring a different phone number attribute for each phone number. ESE provides transactional views of the database. The cost of providing these views is that any object that is modified in a transaction has to be temporarily copied so that two views of the object can be provided: one to the thread inside that transaction and one to threads in other transactions. This copy must remain as long as any two transactions in the process have different views of the object. The repository that holds these temporary copies is called the version store. Because the version store requires contiguous virtual address space, it has a size limit. If a transaction is open for a long time while changes are being made (either in that transaction or in others), eventually the version store can be exhausted. At this point, no further database updates are possible. Note

•

The percentage of version store space that is available for processing has been significantly increased in Windows Server 2003.

Top of page

Data Store Protocols The primary protocol that is used by the Active Directory data store is Lightweight Directory Access Protocol (LDAP), which runs on top of TCP/IP. In addition, the data store uses remote procedure call (RPC) for MAPI, replication, domain controller management, and SAM-related operations. And, although it is not widely used, the data store also supports the use of Simple Mail Transfer Protocol (SMTP) for replication between domain controllers where “always on” network connections do not exist. The following figure illustrates the protocols and interfaces that are used by the data store. For more information about the data store protocols, see the table that follows this figure. For more information about the data store interfaces, see “Data Store Interfaces” later in this section. Data Store Protocols

The following table describes the protocols that are used by the data store. Data Store Protocols

Protocol Description LDAP

LDAP is a directory service protocol that specifies directory communications. It runs directly over TCP/IP, and it can also run over User Datagram Protocol (UDP) connectionless transports. Clients can use LDAP to query, create, update, and delete information that is stored in a directory service over a TCP connection through the TCP default port 389. Active Directory supports LDAP v2 (RFC 1777) and LDAP v3 (RFC 2251). LDAP v3 is an industry standard that can be used with any directory service that implements the LDAP protocol. LDAP is the preferred and most common way of interacting with Active Directory. Historically, LDAP is a simplified (“lightweight”) version of Directory Access Protocol (DAP), which is the original protocol that was used to interact with X.500 directories. X.500 defines an earlier set of standards that was developed by the International Organization for Standardization (ISO). LDAP is simpler than DAP in two key ways:

• Rather than using its own protocol stack according to the Open Systems Interconnection (OSI) networking model, LDAP communicates over Internet Protocol (IP) by using either UDP or TCP.

• LDAP syntax is easier to use than DAP syntax. For these reasons, LDAP is widely used and accepted as the standard protocol for directory service access. The following key aspects characterize LDAP:

• The protocol is carried directly over TCP for connection-oriented transport (receipt of data is acknowledged) and over UDP for connectionless transport (sent or received data is not acknowledged).

• Most protocol data elements can be encoded as ordinary strings, for example, as distinguished names. • Referrals to other servers can be returned to the client. • Simple Authentication and Security Layer (SASL) mechanisms can be used with LDAP to provide associated

security services. SASL Digest is supported in Windows Server 2003 as the authentication standard for LDAP.

• Attribute values and distinguished names can be internationalized through the use of the ISO 10646 character set.

• The protocol can be extended to support new operations, and controls can be used to extend existing operations.

• The schema is published through an attribute on the directory root object (rootDSE) for use by clients. RPC

The data store uses RPC for replication (REPL) and domain controller management communications, MAPI communications, and SAM-related communications. RPC is a powerful, robust, efficient, and secure interprocess communication (IPC) mechanism that enables data exchange and invocation of functionality residing in a different process. That different process can be on the same computer, on the local area network (LAN), or across the Internet.

SMTP

The data store can use Internet-standard SMTP as the protocol for replication communications when a permanent,

Protocol Description “always on” network connection does not exist between two domain controllers. SMTP is used to transport and deliver messages based on specifications in Request for Comments (RFC) 821 and RFC 822. SMTP also includes enhancements that build on the basic delivery functions of the protocol. There are SMTP options available that provide control over the routing and delivery of messages and that provide secure communications. Top of page

Data Store Interfaces As shown in the “Data Store Architecture” figure earlier in this section, network clients and other directory servers obtain access to Active Directory through one of the interfaces that are described in the following table. Data Store Interfaces

Interface Description LDAP

LDAP is the primary interface for the data store. Directory clients use LDAP v3 to connect to the DSA through the LDAP interface. The LDAP interface is part of Wldap32.dll. LDAP v3 is backward compatible with LDAP v2.

REPL

The REPL management interface provides functionality for finding data about domain controllers, converting the names of network objects between different formats, manipulating service principal names (SPNs) and DSAs, and managing replication of servers.

MAPI

Messaging clients gain access to the Microsoft Exchange Server directory service by using MAPI address book providers. For compatibility with existing messaging clients, Active Directory supports the MAPI-RPC address book provider, which provides access to Active Directory, for example, to find the telephone number of a user.

SAM

SAM is a proprietary interface for connecting to the DSA on behalf of clients that use Windows NT 4.0 or earlier. These clients use Windows NT 4.0 networking APIs to connect to the DSA through SAM. Replication with Windows NT 4.0 backup domain controllers (BDCs) goes through the SAM interface as well.

Note

•

The MAPI interface is provided only for support of legacy Microsoft Outlook clients. Development against the MAPI interface is no longer supported. Top of page

Data Store Logical Structure The Active Directory data store uses the LDAP information model as its model for organizing data. In addition, the data store is organized into logical partitions that can each be replicated independently, so that individual domain controllers only need to store data that is pertinent to the domain in which they reside.

LDAP Information Model The LDAP information model is based on the entry, which contains information about some object, for example, a person or computer. In Active Directory, an LDAP entry is referred to as an object. Active Directory objects are composed of attributes, which have a type and one or more values. The implementation of the information model is called the schema, which is a set of objects that defines the structure and content of every object that can be created in a directory service.

Directory Tree Active Directory organizes objects into a hierarchical tree structure. The directory tree represents the hierarchy of Active Directory objects for a given forest. The structure of the hierarchy is derived from the schema, and the directory service implements the hierarchy. The hierarchy provides the basis both for using names for navigation and for defining the scope of search requests. Every object in Active Directory has exactly one parent, and a reference to the parent object is stored with the object. As a result of these parent references, the hierarchy of objects that are managed by Active Directory forms a tree structure. The objects that populate the directory create this tree structure according to the rules of the schema. For example, the schema might dictate that a given class of object can be the child of one class but not the child of another class. The architectural restrictions and requirements in the directory tree are as follows:

• •

Domain objects, which are containers, can be children only of other domain objects. For example, a domain cannot be the child of an organizational unit (OU). The root object of the directory tree is called the DSA-specific Entry (DSE), or rootDSE. The rootDSE object has no hierarchical name or schema class, but it does have a set of attributes that identify the contents of the domain controller on which it resides. Therefore, rootDSE constitutes the root of the directory tree from the perspective of the domain

•

controller to which you are connected. Below the rootDSE, every directory has a root domain, which is the first domain that is created in a forest. This domain always has a child container called Configuration, which contains configuration data for the forest.

rootDSE In the LDAP information model, one or more directory servers can jointly provide access to a directory tree. The servers that host directories are known in LDAP terminology as Directory System Agents (DSAs). In Active Directory, the DSAs are always domain controllers. At the root of a directory tree is a DSE, which is not part of any directory partition. TherootDSE represents the top of the logical namespace for one domain controller. The rootDSE attributes contain information about the directory server, including its capabilities and configuration. There is only one root for a given directory, but the information that is stored in the root is specific to the domain controller to which you connect. Among other things, the attributes of rootDSE identify the following key information:

•

The directory partitions (the domain, schema, and configuration directory partitions) that are specific to one domain

•

The forest root domain directory partition.

controller.

In this way, the rootDSE provides a “table of contents” for a given domain controller.

rootDSE operational attributes The rootDSE publishes information through attributes on the rootDSE object. RFC 2251 and RFC 2252 define a set of seven rootDSE operational attributes that LDAP v3 servers are expected to publish, and these attributes are described in the following list. All LDAP servers recognize these attribute names, but when the attribute corresponds to a feature that the server does not implement, the attribute is absent.

supportedLDAPVersion LDAP versions that the server implements. Domain controllers running Windows Server 2003 and Windows 2000 Server support LDAP v2 and LDAP v3.

namingContexts Naming contexts (directory partitions) that this server masters (stores as a writable replica) or shadows (stores as a readonly replica). A client uses this attribute to choose suitable base objects for searching when the client contacts a server.

subschemaSubentry The name of a subschema entry, which is used to administer information about the schema, in particular, the object classes and attribute types that are supported.

altServer Uniform Resource Locators (URLs) of other servers that can be contacted when this server becomes unavailable. If the server does not know of any other servers, this attribute is absent. Clients can cache this information in case their preferred LDAP server becomes unavailable. This attribute is absent by default for Active Directory servers.

supportedExtension Object identifiers that identify the supported extended LDAP operations that the server supports. LDAP extensions include operations such as different query types, paging operations, and sorting methods, which each have a different object identifier. This attribute is absent by default for Active Directory servers. Note

•

A new extended LDAP operation on domain controllers running Windows Server 2003 enables client refresh of a dynamic

entry in the directory. Object identifier = 1.3.6.1.4.1.1466.101.119.1 is defined and published in the supportedExtension attribute of the rootDSE object.

supportedControl Object identifiers that identify the LDAP controls that the server supports. If the server does not support any controls, this attribute is absent. Server controls extend LDAP functionality; examples include a control to move objects across domains and a control to delete an entire subtree of a container object.

supportedSASLMechanisms The names of the SASL mechanisms that the server supports. SASL is a standard for negotiating an authentication mechanism and, optionally, an encryption mechanism to provide client authorization for accessing Active Directory. By default, Generic Security Service API (GSSAPI) is supported.

rootDSE informational attributes In addition to the previous operational attributes, Active Directory also supports the following informational attributes.

currentTime The current time in the generalized time format.

dsServiceName The distinguished name of the NTDS settings object that represents this domain controller in the configuration directory partition.

defaultNamingContext The default naming context (directory partition) for a particular server. This value is the distinguished name of the domain directory partition for which this domain controller is authoritative.

schemaNamingContext The naming context (directory partition) for the forest schema.

configurationNamingContext The naming context (directory partition) for the forest Configuration container.

rootDomainNamingContext The distinguished name for the domain naming context (directory partition) of the first domain that is created in this forest. This domain functions as the forest root domain.

supportedLDAPPolicies Supported LDAP administrative query policies, such as the maximum size of a result set (MaxResultSetSize) and maximum page size (MaxPageSize).

highestCommittedUsn Highest update sequence number (USN) that is committed to the database on this domain controller.

dnsHostName The DNS name of this domain controller.

serverName The fully qualified distinguished name for this domain controller.

supportedCapabilities

The object identifier value (1.2.840.113556.1.4.800) that indicates the additional capabilities of an Active Directory server, such as dynamic update, integrated DNS zones, and LDAP policies.

LdapServiceName The SPN for the LDAP server, which is used for mutual authentication.

isSynchronized A Boolean indicator for whether the domain controller has completed its initial synchronization with replica partners.

isGlobalCatalogReady A Boolean indicator for whether the domain controller is prepared to advertise itself as a global catalog.

domainControllerFunctionality The numeric level of Active Directory functionality for the domain controller.

Distribution of Directory Data So that it can scale to tens of millions of objects, the Active Directory data store is logically partitioned in such a way that each domain controller does not store the entire directory. To accomplish logical partitioning, the data is categorized according to a naming scheme: object names group objects into logical categories so that the objects can be managed and replicated appropriately. In Active Directory, the largest of these logical categories is called a directory partition. Every domain controller holds at least one directory partition that stores domain data, such as users, groups, and OUs. Every domain controller also stores two nondomain directory partitions that store forest-wide data, which includes the schema and configuration data. The data store holds data for a single forest. Although there is a single directory, some directory data is distributed within domains, while other data is distributed throughout the forest without regard for domain boundaries. In Windows Server 2003, data can also be distributed to domain controllers according to applications that use the data, where the scope of distribution is set by the application. The following table describes the three types of data that are stored in the Active Directory data store. Types of Active Directory Data

Data Type Domainwide data

Description

• Domain-specific data is stored in a domain directory partition. • A full, writable replica of the domain directory partition is replicated to every domain controller in the domain.

Forest-wide data

• Forest-wide data is stored in two directory partitions: the configuration directory partition and the schema directory partition. The Configuration container is the topmost object of the configuration directory partition; the Schema container is the topmost object of the schema directory partition.

• A full, writable replica of the configuration directory partition is replicated to every domain controller in the forest.

• A read-only replica of the schema directory partition is replicated to every domain controller in the forest. The schema is writable on only the domain controller that holds the schema operations master role, and writing to the schema requires first adding a registry entry on the schema master. Schema updates replicate to every domain controller in the forest.

• In addition to a full, writable replica of a single domain (the domain for which the domain controller is

authoritative), special domain controllers that are designated as global catalog servers also store partial, read-only replicas of every other domain directory partition in the forest. (The read-only replicas in the global catalog are “partial” because they store only some of the attributes for each object.) A domain controller that is a global catalog server can be queried to find any object in the forest.

Data Type Application data

Description

• Applications can use a new type of directory partition in Windows Server 2003 Active Directory, called an

application directory partition, to store application-specific data that has a scope of interest that is smaller than the entire forest or domain. This data can be characterized as either changing frequently (dynamic) or having a short useful lifetime (volatile). For example, Windows Server 2003 DNS can use application directory partitions to store dynamically updated DNS zone data on only those domain controllers that are DNS servers rather than on all domain controllers in the domain, as is required for Windows 2000 Active Directory–integrated zones.

Directory Partition Hierarchy In Active Directory, a directory partition is a portion of the directory namespace. Each directory partition contains a subtree of the directory objects in the directory tree. The same directory partition can be stored as a replica on many domain controllers, and the replicas are updated through directory replication. There is an important distinction between the physical storage of a directory partition and its logical position in the directory tree. Physically, all objects are stored in a single database table, regardless of the directory partition to which they are assigned because of their object names. Logically, the head of a directory partition appears in the naming hierarchy as the topmost object; that is, the Domain container, the Configuration container, and the Schema container each has a distinguished name that identifies its position in the hierarchy. Every domain controller stores a replica of a domain directory partition, the configuration directory partition, and the schema partition. For more information about these partitions, see “Directory Partitions” later in this section. Note

•

Although the schema directory partition is replicated to every domain controller in the forest, it can be updated only on the

domain controller that holds the schema operations master role. The following figure is a conceptual diagram of the directory tree hierarchy, including the directory root (rootDSE) and the default directory partitions below the directory root. TherootDSE represents the top of the logical namespace for one domain controller and, as such, it represents the top of the LDAP search tree. There is only one root for a given directory, but the information that is stored in the root is specific to the domain controller to which you connect. In any Active Directory forest, the first domain directory partition that is created in the forest (the forest root domain), the configuration directory partition, and the schema directory partition always form the hierarchy that is illustrated in the following figure. Default Active Directory Partitions

Additional directory partitions are possible in the form of application directory partitions, but these partitions are not stored by default on every domain controller.

Directory Partition Cross-Reference Objects When Active Directory is installed to create the first domain controller in a new forest, the three directory partitions that are shown in the previous figure are created on the domain controller. At this time, a cross-reference object (class crossRef) is created for each directory partition in the Partitions container in the configuration directory partition (CN=partitions,CN=configuration,DC=forestRootDomain). Creation of each subsequent directory partition in the forest, either by installing Active Directory to create a new domain or by creating a new application directory partition on an existing domain controller, initiates the creation of an associated cross-reference object in the Partitions container.

Note

•

You can also manually create a cross-reference object for an application directory

partition. A cross-reference object identifies the name and server location of each directory partition in the forest. The replication system uses this information to identify servers that store the same directory partitions. LDAP queries use cross-reference objects to create referrals to different domains.

Forest Root Domain Because the forest root domain is the first domain that is created in a forest, it is the root name in the domain namespace hierarchy. In naming only, the topmost object of the configuration directory partition — the Configuration container — is the child of the forest root domain object in the hierarchy. The LDAP distinguished name of the Configuration container (CN=configuration,DC=forestRootDomain) reflects this naming hierarchy, which links the configuration directory partition to the forest. Similarly, the topmost object in the schema directory partition — the Schema container — is the child of the Configuration container. The distinguished name of the Schema container (CN=schema,CN=configuration,DC=forestRootDomain) links the schema to the forest.

Directory Partitions The Active Directory data store holds three default directory partitions:

• • •

The configuration directory partition The schema directory partition The domain directory partition

Optionally, the data store may also hold one or more application directory partitions.

Configuration Directory Partition The configuration directory partition is created initially when the first domain of a forest is created during the installation of Active Directory. Thereafter, it is replicated to every new domain controller that is added to the forest. The configuration directory partition holds information of global interest, for example, the default configuration and policy information for all instances of a given service in the forest. Note

•

Global information should be stored in one of two places: in a child of the Services container or in a child of a site object.

Contents of the configuration directory partition In Active Directory tools, such as ADSI Edit, the configuration directory partition is represented by a Configuration container. When you open ADSI Edit (Adsiedit.msc) from the Run dialog box, the Configuration container for the forest of the domain to which you are connected is displayed, along with the current domain directory partition and the schema directory partition. Note

•

If you open ADSI Edit with Microsoft Management Console (MMC) (as opposed to opening ADSI Edit from the Run dialog

box), you must connect to the directory partition to view it. The following objects are child containers in the Configuration container.

DisplaySpecifiers Contains the objects that define different user interfaces (UIs) for each object class in the schema that requires a graphical user interface (GUI), for example, context menus and property pages. The display specification system uses the information that is stored in the display specifiers to form different UIs for administrators and end users. One set of elements can be associated with administrative applications, and a different set of elements can be associated with end-user applications. What you see and what the user sees are different, even though in both cases the UI references the same objects. The display specification system stores information for property sheets, context menus, icons, creation wizards, and localized class and attribute names.

This UI specification occurs at the level of each object class as defined in the schema in classSchema objects. Each classSchema object can have UI display specification information that is uniquely associated with it. The DisplaySpecifiers container stores other containers that correspond to each locale that is supported. A locale is either a language or a language in combination with a country/region. Windows supports more than 150 locales, such as French (Belgium), Arabic (Saudi Arabia), and so forth. The names of locale containers are the hexadecimal representations of the locale identifiers (LCIDs). For example, the English (United States) locale container is 409. Display-specifier objects (class displaySpecifier) are named by appending the LDAP Display Name of the class object with the string -“-Display.”. For example, the user class has a corresponding display-specifier object called user-Display. Therefore, when an Active Directory administrative tool displays an object of a particular class, the object is displayed according to information that is contained in the display-specifier object whose name contains the same name as the respective class in the container for the current locale. Because the Active Directory schema can be modified by creating new classes and attributes or by modifying existing classes, display-specifier objects can be modified to reflect any new UI elements that schema modifications require.

Extended-rights Stores objects of the class controlAccessRight that can be used by applications to extend standard access control.

ForestUpdates Stores operation objects that are generated by forest preparation tasks (when you run adprep /forestprep) so that the system can check for the tasks that have and have not been completed when you upgrade the first domain controller in the forest to Windows Server 2003. The child object CN=Operations contains the objects that represent each update operation. These objects are named for the GUID of the operation. The child object CN=Windows2003Update is created to indicate that all adprep operations have run.

LostAndFoundConfig Provides storage for configuration directory partition objects that are being created in containers that are simultaneously being deleted on another domain controller in the same forest. If, before replication, an object is created in or moved to a location that no longer exists after replication, the “lost” object is added to the LostAndFoundConfig container. A LostAndFound container in each domain directory partition serves the same purpose for domain-specific objects.

NTDS Quotas Stores objects (class msDS-QuotaControl) that contain object ownership quota assignments for the configuration directory partition. Quotas limit the number of objects that a user (including inetOrgPerson), group, computer, or service can own in a domain directory partition, configuration directory partition, or application directory partition.

Partitions Stores the cross-references to every directory partition in the forest, including the configuration partition, the schema partition, and all domain directory partitions. These cross-references to directory partitions make referrals to other domains possible during LDAP searches.

Physical locations Not used in this version of Windows but reserved for future use.

Services Stores data for various networking services and applications, such as Message Queuing (MsmqServices), public key services, and Routing and Remote Access. In the Windows NT container, the Directory Service object (nTDSService) has attributes that you can use to manage garbage collection intervals and dynamic object Time to Live (TTL). For the most part, however, objects in the Services container do not require administration. Specifically, do not publish application services in this container. Such services are best published in the Program Data container in the domain directory partition.

Sites

Identifies all of the sites in the network, the domain controllers in those sites, and the replication topology. The contents take the form of replication transports, subnets, and the first site and site link that are created, called Default-First-Site-Name and Default-First-Site-Link, respectively.

Well-known security principals Contains the special identities that are defined by the security system, such as Everyone, Local System, Principal Self, Authenticated User, and Creator Owner.

Schema Directory Partition The Active Directory schema is stored in the Schema container in the schema directory partition. The schema consists of a set of object classes, attributes, and syntaxes. It also defines rules that ensure that objects are created and modified with consistency. Active Directory contains a default set of classes and attributes that cannot be modified. However, if you have Schema Admins credentials and if schema modification is enabled for the domain controller, you can extend the schema by adding new attributes and classes to represent application-specific classes. These changes are targeted at the domain controller that is the schema master for the forest. Only the schema master stores a writable copy of the schema.

Domain Directory Partition When you create a new domain, a domain directory partition is created in Active Directory as an instance of the class domainDns. A cross-reference object is added for the domain in the Partitions container to advertise the domain’s location in the directory.

Contents of a domain directory partition The topmost object in each domain directory partition is a domainDns object that is named with the DNS name of the domain. A domain directory partition is represented by a domain container, and a domain directory partition has the following child containers.

Builtin Default local group accounts, such as Administrators and Users, that are installed whenever a new workstation, server, or domain controller is set up.

Computers A default storage area for “new” computer objects that were originally created through legacy APIs. When a Windows NT 4.0 domain or a Windows NT 3.51 domain is upgraded to Windows 2000, or when a Windows NT 4.0 domain is upgraded to Windows Server 2003, the computer accounts are moved automatically to the Computers container. The Computers container also supports the Windows NT 4.0 tool User Manager (Usrmgr). This container cannot be renamed, but when a Windows Server 2003 domain has a domain functional level of Windows Server 2003, the default location for computer accounts can be specified as an OU to redirect the location of newly created computer objects.

Domain Controllers The default container for new domain controllers. The Domain Controllers container cannot be renamed.

ForeignSecurityPrincipals Proxy objects for security principals that are from Windows NT 4.0 domains or Windows NT 3.51 domains, or that are from different forests, and that have been added to Windows 2000 or Windows Server 2003 groups.

LostAndFound (advanced features) A storage area for new domain objects whose containers were deleted elsewhere at the same time that the object was created. If an object has been created in or moved to a location that is missing after replication, the “lost” object is added to the LostAndFound container. The LostAndFoundConfig container in the configuration directory partition serves the same purpose for forest-wide objects.

NTDS Quotas (advanced features) A storage area for objects of the class msDS-QuotaControl that contain object ownership quotas for the domain directory partition. Quotas limit the number of objects that a user, group, computer, or service can create in a directory partition.

Program Data (advanced features) An empty container that is available for applications to store application-specific data in the domain directory partition.

System (advanced features) Built-in system settings for the various system service containers and objects.

Users A default storage area for new user accounts created through legacy APIs that are not Active Directory–aware. When a Windows NT 4.0 domain or a Windows NT 3.51 domain is upgraded to Windows 2000, or when a Windows NT 4.0 domain is upgraded to Windows Server 2003, the user accounts and groups are moved automatically to the Users container. The Users container also supports the Windows NT 4.0 tool User Manager (Usrmgr). This container cannot be renamed, but when a Windows Server 2003 domain has a domain functional level of Windows Server 2003, the default location for user and group accounts can be specified as an OU to redirect the location of newly created user objects. Note

•

The Users and Computers containers and several other special containers, called “well-known” containers, can be located dependably by applications.

Deleted Objects A special container, which is not visible in the UI, to which objects are moved when they are deleted. The deleted objects are stored as tombstones, which are eventually removed by garbage collection. The contents of the Deleted Objects container are visible if you search by using the 1.2.840.113556.1.4.417 control, which enables you to see deleted objects.

Infrastructure An object of class infrastructureUpdate that identifies the NTDS Settings object of the domain controller that holds the infrastructure operations master role for the domain.

Contents of the System container The System container stores per-domain operational information, which includes the default local security policy, file link tracking, Microsoft NetMeeting network meeting objects, objects representing other trusted domains, and containers for RPC and Windows Sockets (Winsock) connection points. The System container has the following child containers.

AdminSDHolder Administrator security descriptor holder. Windows Server 2003 implements protection of administrative groups through a background task that computes the set of memberships and checks whether their security descriptors are well-known protected security descriptors. If the security descriptor of any administrative account does not match that of AdminSDHolder, the security descriptor is overwritten with the security descriptor of AdminSDHolder. This task is executed only on the domain controller that holds the primary domain controller (PDC) emulator operations master role.

COMPartitions A namespace that is used by Component Services to allow multiple versions of the same COM+ application to exist on the same physical computer.

ComPartitionSets A conceptual collection of COM+ partitions.

Default Domain Policy

The common domain location for the AppCategories container (class classStore), which holds objects of the class categoryRegistration. These objects are managed by the Group Policy Software Installation MMC extension, and they can be associated with applications that are deployed through Group Policy in the domain. Note

•

The Group Policy object (GPO) for the default domain policy is stored in the Policies container.

Dfs-Configuration Lists the fault-tolerant Distributed File System (DFS) configuration and DFS volume information.

DomainUpdates Stores operation objects that are generated by domain preparation tasks (when you run adprep /domainprep) so that the system can check for tasks that have and have not been completed when you upgrade the first domain controller in the domain to Windows Server 2003. The child Operations object contains the objects that represent each update operation. These objects are named for the GUID of the operation. The child Windows2003Update object is created to indicate that all adprep operations have run.

File Replication Service Lists the Domain System Volume (SYSVOL) and provides a replication schedule from Sunday through Saturday, 12:00 A.M. to 12:00 A.M.

FileLinks Used by the Distributed Link Tracking Server service (TrkSvr) to store information about linked files that have moved across NTFS volumes. Includes ObjectMoveTable, which tracks moved files, and VolumeTable, which maps volume IDs to computer IDs.

IP Security Contains the Internet Protocol security (IPSec) policies that are applied to local computers, domain member servers, domains, OUs, or any GPO in Active Directory. Depending on your organization’s guidelines, IPSec policies can store multiple security specifications, called rules, so that one policy can be applied to multiple computers. These rules apply to all users who log on to the computer

Meetings A folder that is used by Microsoft NetMeeting to publish network meeting objects.

MicrosoftDNS A container in which Active Directory–integrated zone database records are created when the scope of replication is all domain controllers in the domain. When DNS data is stored in Active Directory, each DNS zone is an Active Directory container object (dnsZone). The dnsZone object contains a dnsNode object for every unique name in that zone. The dnsNode object has a dnsRecord multivalue attribute that contains a value for every resource record that is associated with an object’s name. When the scope of replication of DNS data is all DNS servers in the domain or all DNS servers in the forest, DNS zone data is stored in application directory partitions, not in the domain directory partition.

Policies Contains GPOs, which specify user and computer configurations for groups of users and computers. This container stores the default domain policy (lists the security groups and default permissions for the domain); default domain controller policy; and policy for passwords, lockouts, Kerberos, EFS data recovery, and trusted root certificates. Each GPO in the Policies container is identified by a GUID, and each GPO includes the following:

•

Version information that is used to ensure that information is synchronized with Group Policy template

• •

Status information that indicates whether the GPO is enabled or disabled

information A list of components, or extensions, that have settings in the GPO

In addition to being stored in the Policies container, GPOs are also stored in a Group Policy template, and they are identified by GUID. The Group Policy template is located in the SYSVOL, and it is used to store file type data for the GPOs.

RAS and IAS Servers Access Check Verifies permissions for the RAS and IAS Servers domain local security group to access user account properties. When Routing and Remote Access (configured for Windows authentication) or Internet Authentication Service (IAS) queries a domain controller to validate user account credentials and receives a failure notification, there is no indication why the failure occurred. It might have occurred because the user’s credentials were invalid or because the server running Routing and Remote Access or IAS did not have the appropriate permissions to access user account properties. Routing and Remote Access and IAS servers obtain access to user account properties by adding the computer account of the server to the RAS and IAS Servers group. The RAS and IAS Servers group has Read permission to the RAS and IAS Servers Access Check container. By attempting access to the RAS and IAS Servers Access Check container, the Routing and Remote Access or IAS server determines whether or not it has permissions to access user account properties.

RpcServices Includes the RPC name service lookup for domains using versions of Windows earlier than Windows 2000.

WinsockServices Winsock services that publish themselves by using the registration and resolution (RnR) APIs are published in this container.

WMIPolicy Stores Windows Management Instrumentation (WMI) filters. A WMI filter is a query based on configuration and event information that is made available by WMI providers. By associating a WMI filter with a specific GPO, that WMI filter determines which computers process policy settings in that GPO. Computers that meet all of the conditions that are specified in the WMI filter return a value of TRUE and then process the GPO.

Application Directory Partitions Application directory partitions are special partitions that can be created on domain controllers running Windows Server 2003 to provide LDAP storage for dynamic and volatile data. In Windows 2000 Server, nondomain data is limited to configuration and schema data, which is replicated to every domain controller in the forest. In a Windows Server 2003 forest, application directory partitions provide storage for nondomain, application-specific data that can be replicated to any arbitrary set of domain controllers in the forest — as few or as many as needed by the application that uses the data. Note

•

Applications must be specifically programmed to use application directory partitions.

Characteristics and requirements Application directory partitions have characteristics that make them suitable for storing dynamic data (data that is updated frequently) or volatile data (data that has a specified useful lifetime), as opposed to more static data that domain directory partitions and other directory partitions store. Although application directory partitions are represented as instances of the domainDNS class, as are domain directory partitions, they have characteristics that differentiate their behavior from domain directory partitions. Note

•

Applications can create application directory partitions on Windows Server 2003–based domain controllers by explicitly creating a domainDNS object. Only Windows Server 2003–based and later domain controllers allow creation of domainDNS objects by means other than Active Directory installation. Because Windows 2000 Server and earlier domain controllers do not recognize the request to create a domainDNS object, no special instance type is required to differentiate between application directory partitions and domain directory partitions.

Similarities to domain directory partitions The following characteristics of application directory partitions are the same as the characteristics of domain directory partitions:

•

Naming: Application directory partitions can be named in the same manner as domains, and they can be attached anywhere in the Active Directory namespace where a domain can be attached. Therefore, an application directory partition can be a child of a domain or of another application directory partition.

• • • • •

DNS location: Application directory partitions can be discovered through DNS. Cross-reference object: A cross-reference object is created in the CN=partitions,CN=configuration,DC=ForestRootDomain container for each application directory partition. Change notification for replication: The time intervals that control the latency of the initiation of an originating change notification to replication partners within a site can be configured. These configuration changes are applied to all directory partitions, but they are most useful for application directory partition replication of dynamic data. Access control: The security and access control model for the application directory partition is the same as that for other partitions in Active Directory. TTL: For objects that are stored in an application directory partition, you can assign a TTL value that is configurable. The only requirement is that the domain controller is running Windows Server 2003. For objects that are stored in a domain directory partition replica on a Windows Server 2003–based domain controller in a forest that has a forest functional level of Windows Server 2003, you can assign a TTL. For all other functional levels, however, TTL values cannot be assigned to objects in domain directory partitions.

Differences from domain directory partitions The following characteristics are different from domain directory partitions and specific to application directory partitions:

• •

Credentials for creation: Creating an application directory partition requires Domain Admins credentials in the forest root domain or Enterprise Admins credentials. Replication scope: Whereas domain directory partitions are replicated to every domain controller in a domain, application directory partitions can be replicated to any selected set of domain controllers in the forest. Because application directory partitions do not have domain or site affiliations, either an administrator or the application that creates the directory partition must explicitly define the scope of replication. Note

• •

It is best to store replicas of dynamic data on domain controllers in the same site because intersite replication latency

might not be acceptable for replica consistency. NetBIOS name: Application directory partition objects do not have network basic input/output system (NetBIOS) names. For this reason, their cross-reference objects, which are usually identified by the unique NetBIOS names of their respective directory partitions, are named by GUIDs.

• • •

Contents: Security principals (users, groups, services, and computers) cannot be stored in application directory partitions. Global catalog: Application directory partitions are not replicated to the global catalog. Volatility: Whereas domain data should be relatively static, application directory partition data can be volatile, such as the real-time data that is used by Microsoft Telephony API (TAPI) voice conferencing applications.

Stored objects Any type of object, with the exception of security principals, can be stored in an application directory partition. In addition, objects that reside in an application directory partition:

• • •

Can maintain distinguished-name references to other objects in the same application directory partition, objects in the configuration and schema directory partitions, and any directory partition root object. Cannot maintain distinguished-name references to objects in other application directory partitions or in domain directory partitions. Cannot be moved to other Active Directory partitions outside the application directory partition in which they were created.

Applications can be programmed to store their dynamic data in application directory partitions. The following are examples of applications and the kinds of dynamic objects that they store:

• •

Real-time communication applications: These types of applications typically maintain rendezvous information about active users (user name, computer, and IP address) and conferences in progress (conference name, description, time, and originator). Network services: Routing and Remote Access, Remote Authentication Dial-In User Service (RADIUS), Dynamic Host Configuration Protocol (DHCP), and Common Open Policy Service (COPS) servers need to store dynamically changing forms of data in a directory so that they can be accessed using one uniform method: LDAP. This data generally does not require global replication, and it is also shared by many applications in the proximity of a single directory. (In this case, the data is shared between RAS, RADIUS, DHCP, and COPS servers in a particular site.) The object types include information about user sessions and bandwidth used.

•

Directory-enabled networking: For implementing policy-based networking, there is a large amount of nonstatic, or volatile, information that must be maintained, including information about the state of network links, the flows that are active through a router, and the data rate for each flow. Policy servers might need access to such information to make a decision

based on policies that are predicated on dynamic network state in addition to static data that is stored in the directory. The application directory partition, with its controlled replication scope, can accommodate transient data needs in Active Directory by providing network applications with uniform and consistent access through LDAP to both static and dynamic data.

Security descriptor reference domains When an object is created in Active Directory, it is assigned a security descriptor that contains default access control entries (ACEs) that are taken from the defaultSecurityDescriptor attribute of the class of which the object is an instance. The default ACEs can include domain-relative, well-known SIDs. In the case of objects in a domain directory partition, the reference domain by which the system interprets the domain-relative SIDs is the domain that is represented by the domain directory partition. In the case of an application directory partition, there is no security association between the application directory partition and the domain of the domain controller on which it is created. In a Windows Server 2003 forest, a new, single-valued attribute on the cross-reference object — msDS-SDReferenceDomain — stores the name of the reference domain that is used to interpret the domain-relative SIDs in default ACEs for new objects in an application directory partition. When an application directory partition is created, the value of msDS-SDReferenceDomain on the respective crossreference object is determined as follows:

•

If the parent object of the application directory partition is another application directory partition, the value of msDSSDReferenceDomain is set to the value of msDS-SDReferenceDomain on the cross-reference object of the parent application directory.

• •

If the parent object is a domain directory partition, the value of msDS-SDReferenceDomain is set to the parent domain. If there is no parent object, the value of msDS-SDReferenceDomain is set to the forest root domain. Note

•

It is recommended that domain local groups not be used in the access control lists (ACLs) of objects in application directory partitions. If an application directory partition has replicas on domain controllers in two different domains, the membership of such domain local groups in ACLs can expand to yield different results, depending on the domain controller to which a user connects.

GUID names for cross-reference objects Domains in Active Directory must have NetBIOS names that are unique in the forest so that they are backward compatible with computers that are running earlier versions of Windows. Domains must also have DNS names that are unique. The relative distinguished name of the cross-reference object for each domain directory partition is taken from its NetBIOS name, which guarantees that each cross-reference object is unique within the Partitions container. For example, if a domain has a NetBIOS name of CONCORP and a fully qualified DNS domain name of concorp.contoso.com, the distinguished name of its cross-reference object is CN=concorp,CN=partitions,CN=configuration,DC=contoso,DC=com. The domain component (DC) of the cross-reference object distinguished name is always the forest root domain, which is always the parent of the configuration directory partition. If there were another domain in the same forest named concorp.avionics.contoso.com, this domain would necessarily be given a NetBIOS name other than CONCORP (for example, CONCORPAV). In the case of application directory partitions, there is no associated NetBIOS name, only the DNS name. Given the nature of DNS hierarchical naming, which allows identical left-most name components, a cross-reference object cannot use the leftmost DNS name component as its relative distinguished name. For this reason, cross-reference objects that reference application directory partitions use their object GUID as their relative distinguished names. To associate a cross-reference object with its application directory partition, you can read the nCName attribute of the cross-reference object, which gives the distinguished name of the directory partition. Top of page

Data Store Physical Structure The physical structure of the data store consists of the Active Directory database file (Ntds.dit) and its associated log and temporary files. The data that is held in the database file includes both static data and dynamic data. The following figure illustrates the physical structure of the data store. Data Store Physical Structure

The following table describes the physical components of the data store. Data Store Physical Structure Components

Component

Description

NTDS.DIT

The physical database file in which all directory data is stored. This file consists of three internal tables: the data table, link table, and security descriptor (SD) table.

EDB.LOG

The log file into which directory transactions are written before being committed to the database file.

EDB.CHK

The file that is used to track the point up to which transactions in the log file have been committed.

RES1.LOG,

Files that are used to reserve space for additional log files if EDB.LOG becomes full.

RES2.LOG

Active Directory Database Active Directory data is stored in the Ntds.dit database file. The Active Directory database (Ntds.dit) contains three internal tables, the data table, link table, and SD table, which are described in the following sections. Two copies of Ntds.dit are present in separate default locations on a domain controller, systemroot\NTDS and systemroot\System32:

• •

systemroot\NTDS\Ntds.dit stores the database that is in use on a domain controller. It contains the values for the domain and a replica of the values for the forest (the Configuration container data). systemroot\System32\Ntds.dit is the distribution copy of the default directory that is used when you install Active Directory on a server running Windows Server 2003 to create a domain controller. Because this file is available, you can run the Active Directory Installation Wizard without having to use the server operating system CD.

Data Table The data table contains all the information in the Active Directory data store: users, groups, application-specific data, and any other data that is stored in Active Directory after its installation. The data table can be thought of as having rows (each representing an instance of an object, such as a user) and columns (each representing an attribute in the schema, such as GivenName). For each attribute in the schema, the table contains a column, called a field. Field sizes can be fixedor variable. Fixed-size fields contain an integer or long integer as the data type. Variable-size fields typically hold string types, for example, Unicode strings. The database allocates only as much space as a variable-size field needs: 16 bits for a 1character Unicode string, 160 bits for a 10-character Unicode string, and so on. The database space that is used to store an object depends on the number of attributes for which values are set and the size of the values. For example, if the administrator creates two user objects (User1 and User2), sets only the minimum attributes on them, and then later adds a 10-character description to User2, the User2 space is approximately 80 bytes bigger than the User1 space (20 bytes for the 10 characters, plus metadata on the newly generated attribute). Database records cannot span database pages; therefore, each object is limited to 8 kilobytes (KB). However, some attribute values of an object do not count fully against this limit. Long, variable-length values can be stored on a different page than

the object record, leaving behind only a 9-byte reference. In this way, an object and all its attribute values can be much larger than 8 KB.

Link Table The link table contains data that represents linked attributes, which contain values that refer to other objects in Active Directory. An example is the MemberOf attribute on a user object, which contains values that reference groups to which the user belongs. The link table is much smaller than the data table.

SD Table The SD Table contains data that represents inherited security descriptors for each object. With the introduction of the SD table in Windows Server 2003, inherited security descriptors no longer have to be duplicated on each object that inherits security descriptors. Instead, inherited security descriptors are stored in the SD table and linked to the appropriate objects.

Log Files The Active Directory data store includes the log files that are described in the following table. For information about how these log files are used, see “Logging Transactions to Enable Log-based Recovery” later in this section. Log Files

File

Description

Edb.log

This file stores directory transactions before they are written to the Ntds.dit directory database file. This file has a fixed size of 10 megabytes (MB).

Edb00001.log, Edb00002.log,

Active Directory creates additional log files as necessary as existing log files fill up. Each

Edb00003.log, and so on

log file has a fixed size of 10 MB.

Edb.chk

This file keeps track of the point up to which transactions in the log file have been committed.

Minimum Space Requirements The minimum space requirements for the directory database and log files — and the requirements for which monitoring is essential — are free disk space on the partition or partitions that store the directory database and logs, as follows:

• •

Ntds.dit partition and log file partition: On either partition, free disk space must not fall below the greater of 500 MB or 20 percent of the combined Ntds.dit and log file sizes. Ntds.dit and log files on the same volume: Free disk space must not fall below the greater of 1 gigabyte (GB) or 20 percent of the combined Ntds.dit and log file sizes.

Objects and Capacity There are no practical limits to the number of objects that can be stored in Active Directory. The Active Directory database has been tested for up to 60 million objects. Performance tests show logon performance for a single LDAP client to be the same with 10,000 objects, 100,000 objects, and 1 million objects; that is, the directory service does not slow measurably when the size of the database increases. Note

•

In a mixed environment in which backup domain controllers (BDCs) are running Windows NT 4.0, the recommended limit for the number of security principal objects per domain is 40,000 (the sum of users, groups, and computers). This limit is based on the Windows NT 4.0 SAM database storage capacity.

Maximum Database Record Size The maximum size of a database record is 8110 bytes, based on an 8-kilobyte (KB) page size. Because of variable overhead requirements and the variable number of attributes that an object might have, it is impossible to provide a precise limit for the maximum number of multivalues that an object can store in its attributes. For all practical purposes, the size of objects is not significant in Windows Server 2003 Active Directory and is not significant in Windows 2000 if you use the recommended guidelines described in "Static Data" later in this chapter.

The only value that can actually be computed is the maximum number of values in a nonlinked, multivalued attribute when the object has only one attribute (which is impossible). In Windows 2000 Active Directory, this number is computed at 1575 values. From this value, taking various overhead estimates into account and generalizing about the other values that the object might store, the practical limit for number of multivalues stored by an object is estimated at 800 nonlinked values per object across all attributes. Note Attributes that represent links do not count in this value. For example, the members linked, multivalued attribute of a group object can store many thousands of values because the values are links only. The practical limit of 800 nonlinked values per object is increased in Windows Server 2003. When the forest has a functional level of Windows Server 2003 or Windows Server 2003 interim, for a theoretical record that has only one attribute with the minimum of overhead, the maximum number of multivalues possible in one record is computed at 3937. Using similar estimates for overhead, a practical limit for nonlinked multivalues in one record is approximately 1200. These numbers are provided only to point out that the maximum size of an object is somewhat larger in Windows Server 2003.

Active Directory Data The key characteristics of data that is stored by any directory service are size and latency. A directory service should store objects that are not so large that they hamper replication. Therefore, large unstructured data sets are not appropriate for storage in Active Directory. Domain data and configuration data are typically static in nature, having a useful lifetime at least as long as a single period of replication latency. In a Windows 2000 Server forest, Active Directory does not support storage of nonstatic (dynamic or volatile) data. In a Windows Server 2003 forest, however, Active Directory can store nonstatic data in application directory partitions, which can be configured for limited replication or used as real-time data stores for data that is too volatile for replication.

Static Data Active Directory is appropriate for the storage of static data that has the following characteristics:

•

The data is globally useful information in the domain that needs to be replicated to each Active Directory domain

• •

The data has well-defined object attributes and semantics.

controller. The data has a useful life that is at least two times the maximum replication latency for the forest, including replication of data that is marked to replicate to the global catalog. In general, if data can become outdated before the completion of a replication cycle or shortly thereafter, it should not be stored in Active Directory. Clients should be able to tolerate the

•

inability to update data for at least as long as it takes for the data to be replicated throughout the domain. The data-per-attribute value is not so large that it affects performance. Most attribute values are replicated as a single block of data; therefore, an attribute that is x MB in size requires an equivalent amount of buffer space in the sending domain controller and in the receiving domain controllers. If the amount of required buffer space is large, the performance of the domain controllers can be affected adversely. Attributes can have large values when the attribute is multivalued and linked. For these attributes, only the values that change are replicated, not the entire attribute.

Dynamic Data An object that has a TTL value is considered to be dynamic data. Windows Server 2003 introduces a new auxiliary class, dynamicObject, that can be attached to object instances for the storage of TTL values. For an object containing a TTL value, when the time that is specified by the TTL value is reached, the object is automatically removed from Active Directory by garbage collection. Dynamic data typically changes faster than the replication latency that is required for propagating the change to all replicas of the data. The following characteristics apply to dynamic data:

• • • •

A dynamic object that is deleted as a result of expiration of its TTL does not leave a tombstone. Dynamic objects are treated in the same manner as nondynamic objects during search, compare, add, delete, and modify (including rename) operations. A nondynamic object, after it is created, cannot be changed to a dynamic object. Likewise, a dynamic object, after it is created, cannot be changed to a nondynamic object. A nondynamic object cannot be added in a subordinate position to a dynamic object.

•

Dynamic objects with TTL values are supported in the following directory partitions:

• •

Domain directory partitions at the Windows Server 2003 forest functional level

•

Dynamic objects are not supported in configuration directory partitions or schema directory partitions.

Application directory partitions on a Windows Server 2003–based domain controller, irrespective of domain or forest functional level

TTL for dynamic objects The TTL for a dynamic object is set when the object is created, and it is automatically decremented thereafter. When its TTL expires, the dynamic object disappears without leaving a tombstone. However, a client application can programmatically cause a dynamic object to remain longer than its current remaining lifetime by refreshing (modifying) its TTL value, as stored in the entryTTL attribute on the object. The Directory Service object (nTDSService) in the Configuration container (CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC= forestRootDomain) stores the default and minimum dynamic object TTL values for the forest in the multivalue attribute msDS-Other-Settings. The default values for the two configurable TTL parameters are as follows:

• •

Default TTL value = 86400 seconds (1 day) Minimum TTL value = 900 seconds

(15 minutes) The default TTL value is assigned to a newly created dynamic object if a TTL is not explicitly specified by the application that creates the object. The minimum TTL overrides any client-specified TTL value that is lower than the configured minimum. No configurable maximum TTL value needs to be provided, because a maximum is imposed by the attributeSchema object. The syntax for the two configurable TTL parameters is as follows, where NNNN is expressed in seconds: DynamicObjectDefaultTTLSeconds=NNNN DynamicObjectMinTTLSeconds=NNNN By configuring these values, you can set TTL values that enforce a low level of refresh traffic or, conversely, provide a highly up-to-date directory. Top of page

Data Store Processes and Interactions The Active Directory data store performs a number of processes and interactions that are important to the functioning of Active Directory. The following sections describe these processes and interactions. These descriptions make the following assumptions regarding the environment in which the Active Directory data store is running:

•

The disk volume on which the directory database is stored contains ample free

•

Network connectivity on the domain controller is functioning properly.

space.

Database Operations Data operations (such add, modify, and delete) are committed to the Active Directory database as transactions, which are the units of work that are performed by a database. Transactions are atomic; that is, they are either completed in full or not applied at all. If for any reason an error occurs and a transaction is unable to complete all of its steps, the system is returned to the state that existed before the transaction began. An example of an atomic transaction is an account transfer transaction in which money is removed from account A and placed into account B. If the system fails after it removes the money from account A and before it places the money into account B, the transaction processing system puts the money back into account A and returns the system to its original state; that is, the transaction processing system rolls back the transaction. In Active Directory, operations on a single object cannot be applied across multiple objects. Active Directory writes a transaction synchronously to the transaction log file and then to the database. First, a change is made to an in-memory copy of the object. Then, the change is written to the log file, which ensures that the change takes effect, even if the database shuts down after that point. The database engine continually updates the database file with recent changes. The database update works from memory — not from the log files — and it keeps pace with the updates, rather than waiting for the server to be available. This method of performing updates is referred to as “advancing the checkpoint,” where the checkpoint is the point in time at which all changes that have been made so far have been fully written to the database.

LDAP Functional Model Database operations in Active Directory are based on the LDAP functional model. The LDAP functional model includes support for common database operations, such as connecting to a directory database, searching for data, and modifying data. An LDAP client connects to Active Directory and requests information or performs an operation. Active Directory performs the operation or provides the information, or it refers the client to another LDAP server that might be able to do so. Nine operations form the LDAP functional model. These operations are grouped into three areas:

•

•

•

Authentication. Enables the client to prove its identity to the DSA:

• • •

Bind Unbind Abandon

Interrogation. Enables the client to interrogate the directory and retrieve information:

• •

Search

• • • •

Add

Compare

Update. Enables the client to update information in the directory tree:

Delete Modify Modify relative distinguished

name A typical LDAP client application interacts with Active Directory through the operations that are described in the following sections. For more information about LDAP, see “Lightweight Directory Access Protocol (LDAP)” in the Microsoft Platform SDK on MSDN.

Establishing a connection When an LDAP client connects to Active Directory, an LDAP session is established. Options are available to affect the way in which the connection is established. These options include setting a time-out value, connecting to a secure LDAP server, and verifying that a server is available. For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope. LDAPMessageis encapsulated in the Protocol Data Unit (PDU) format. LDAPMessage consists of protocol operations, such as LDAP Bind Request, LDAP Bind Response, LDAP Search Request, and LDAP Search Response operations. LDAPMessage PDUs are mapped directly to the TCP data stream. Active Directory clients use the following LDAP ports:

•

Port 389. In accordance with RFC 2251, Active Directory uses port 389 as the default port for domain controller

• •

Port 636. Active Directory supports port 636 for LDAP Secure Sockets Layer (SSL) communications.

communications. Port 3268 and port 3269. The global catalog monitors port 3268 for LDAP communications and port 3269 for LDAP SSL communications.

Modifying a directory object The LDAP API contains functions for adding and deleting directory objects and for comparing and modifying attribute values in existing objects. LDAP v3 provides extensions to add, delete, and modify functions that enable the use of controls to perform these operations. Controls are described in RFC 2251 as a mechanism to extend the functionality of LDAP. Windows Server 2003 supports several extension controls that go beyond the controls that are identified by LDAP v3.

Searching the directory Searching is the most common directory activity, and the LDAP APIs provide a variety of search criteria and result-retrieval methods. The client searches the LDAP server by passing it a set of parameters that describe the information of interest. These parameters describe where and how to search, and they define the search criteria that a client needs. The client uses a search filter to describe the objects that it wants. Search filters are defined in RFC 2254. Extensions to the base LDAP API, in the form of LDAP v3 controls, provide the ability to sort results and set various limits on the search operation. Search

results can be processed by paging and by sorting. Paging and sorting are supported in Windows Server 2003 and Windows 2000 Server as new LDAP v3 control extensions for processing search results on the server.

Closing the connection (unbinding) Unbinding closes the connection between the directory client and the DSA and disposes of the session handle. Applications call the unbind function when an LDAP client finishes communicating with a server. There is no server response to an unbind request.

Logging Transactions to Enable Log-based Recovery To maximize system efficiency and ensure data integrity, Active Directory uses “write ahead” logging. With “write ahead” logging, transactions are written as quickly as possible to a transaction log file, and they are then written to the Ntds.dit database file as the system has time or at system shutdown. The log file that is used by Active Directory to record transactions is called Edb.log, which has a fixed size of 10 MB. When this log file becomes full, Active Directory automatically creates a new log file, for example, Edb00001.log, which also has a fixed size of 10 MB. Active Directory continues to create additional log files as they become necessary. Through circular logging, the oldest log file is purged when all transactions in that log have been written to the Ntds.dit database. In addition to the active log files, two reserve log files exist, called Res1.log and Res2.log, ,also with a fixed size of 10 MB. These files reserve the last 20 MB of disk space on the drive to provide room for a graceful shutdown if all other disk space is consumed. Active Directory also maintains a checkpoint file (Edb.chk) that records which transactions in the log have been committed to the database. In circular logging, log files are deleted when the checkpoint advances past the last transaction that is included in that log file. The checkpoint cannot be advanced past the beginning of any transaction that is still open. If the computer stops responding, the ESE can detect an improper shutdown by checking the last log recorded. If the last record is not a “shutdown” record, the ESE reprocesses the logs from the checkpoint that is stored in Edb.chk. This event occurs at the first reboot after the system is shut down improperly. If the checkpoint file is missing for any reason, every transaction within the log file is reprocessed. The number of log files that exist at any point in time is related to the number and size of transactions that are running in the database. If a system is idle, you can expect to see one log file. If a domain controller is making large changes (for example, replicating a 5,000-member group), you can expect to see several log files. If you just edited the schema to define an index on an attribute that has many large data values, you might see hundreds of log files. (The checkpoint cannot be advanced until the index creation is completed.)

Growth and Space Management The directory database is a self-maintained system in which growth is managed by periodically compacting data and reorganizing free space into contiguous pages. Other than regular backup, the directory database requires no maintenance during ordinary operation. The only requirement is adequate space to accommodate normal growth. The directory database grows when more data is added to it than free space is available to accommodate the new values. Free space, also called “white space,” is managed automatically by the directory database. Conditions under which free space is made available to the database can affect database size, sometimes in ways that are not expected. For this reason, an understanding of how free space is managed can help provide correct interpretation of changes in the size of the directory database file. The following sections describe space allocation and free space reclamation.

Space Allocation Space is allocated hierarchically in the directory database, with the database at the top of the hierarchy. Object tables are children of the database. Each table has a child long-value table, and each table can have child indexes. The long-value table stores values that are too large for the main object table. Security descriptors are examples of values that are often large enough to require storage in the long-value table. As objects are deleted and values are replaced with smaller values, free space is returned to the database. However, there is no optimum or target amount of white space to be maintained. The amount of unused space in the directory database is of concern only when monitoring indicates that free disk space is becoming limited. You can configure a domain controller to log an event that reports the amount of unused space in the directory database that can be reclaimed by offline defragmentation.

Requesting space The database can use free space if the space is available to the table or index that needs it and if the space occurs in blocks that are large enough to accommodate the transaction. When an index or table requires additional space, it can request space only from its parent. For example, the available space in an index cannot be used by another index. If the parent table requires space, it must request space from the database. If space is not available at the database level to complete the request, the database increases its size to accommodate the transaction.

Space consumption by indexes The estimated space that is required for adding an index to an attribute is rarely greater than 1 percent of database size. However, Tuple indexes, which index an attribute in a way that allows users to search the attribute by using partial text strings, can be quite large. To provide partial text string searching, a Tuple index includes one entry for each substring of a Text or Long Text column, with a minimum and maximum length allowed for the substrings that are indexed. Although Tuple indexes can dramatically speed queries of the form “find all records that contain string value,” they can potentially increase database size by as much as 20 percent, and they should be used with caution.

Storing data Objects are stored in records that are written to 8-KB data pages. The maximum record size is 8110 bytes, with the exception of long-value columns, which can be up to 2 GB. As values are deleted, space that is freed by transactions is returned to the table that owns the space. Free space is returned gradually in small segments, and it is periodically reorganized into contiguous pages through an automatic process called online defragmentation. Data pages are filled with records in an ordered fashion. For example, all records beginning with A must be stored in the page that is designated as storing the values that range from A to some other value. For example, given pages A-E and F-J, if a value corresponds to the A-E page and that page is full, the value cannot be stored in the F-J page, even if space is available. Instead, one or more new pages are added. When a table grows, it grows in increments equal to one-fourth its initially allocated size. In this way, Active Directory data storage optimizes lookup speed as opposed to storage space. However, because of the hierarchical means of allocating free space and the order that is required for filling data pages, free space that is present in the database is not always available for use.

Free Space Reclamation The version store is the area of the database that manages version control. When a transaction is committed to the database, a cleanup process returns space that is freed by modify and delete transactions to the database. For each modify or delete operation, the existing version of the record is written to the version store so that the database maintains a copy of the old version until the new version is written to the database. After the transaction is committed to the database, any space that is freed from deleted records and long values is returned to the table or index that owns the space. Until the change is committed to the database, requests for the object continue to access the old version. If the transaction is rolled back, the version store record is used to undo the transaction. The version store has a size limit that is the lesser of the following: one-fourth of total random access memory (RAM) or 100 MB. Because most domain controllers have more than 400 MB of RAM, the most common version store size is the maximum size of 100 MB. If too many large changes or deletions occur simultaneously, it is possible for the version store to run out of processing space. In this event, cleanup of free space is suspended temporarily. On domain controllers running Windows 2000 Server, the most common cause of version store overload is large-scale bulk deletions.

Bulk deletions and database growth in Windows 2000 Delete operations are the most CPU-intensive operations that the version store processes. On domain controllers running Windows 2000 Server, bulk deletions, such as the deletion of an entire tree of objects at one time, can cause a temporary condition in which free space cannot be returned to the database in a timely fashion because the cleanup process cannot keep up with the deletions. Event ID 602 is logged in the Directory Services event log to indicate this condition. During the time that pages are being skipped by the cleanup process, free space is not released to the database, and space is not reclaimed until the next scheduled online defragmentation occurs. In the meantime, processing requirements can

cause the database to grow. In particular, when bulk deletions or other bulk changes coincide with database additions, significant growth can occur. In addition, space from the deletion of long values is not returned to the database by online defragmentation. As a result of these conditions, the directory database on domain controllers running Windows 2000 Server can actually increase in size following a bulk deletion. On domain controllers running Windows Server 2003, the effects of these conditions are greatly reduced by improvements in version store cleanup and online defragmentation. However, if event ID 602 is logged in the Directory Services event log, running online defragmentation manually can alleviate the problem. On domain controllers running Windows 2000 Server, the only way to prompt online defragmentation is to change the garbage collection interval to the minimum value of one hour to force garbage collection and online defragmentation to occur as soon as possible.

Improved space processing in Windows Server 2003 Two improvements in the Windows Server 2003 processing of free space eliminate the database growth problems that can result from large-scale bulk deletions:

•

The threshold at which the database begins skipping cleanup operations is increased from 5 percent to

•

Space is reclaimed from long-value deletions.

90 percent.

The threshold of maximum pages that can be processed by the version store is the limiting factor in whether the cleanup process can keep pace with deletions. The version store cleanup process can take place only as long as the version store has sufficient space. With a maximum version store size of 100 MB, only 5 MB (5 percent) is available in Windows 2000 Server, and this low threshold is responsible for early suspension of the cleanup process. The threshold of 90 MB (90 percent) in Windows Server 2003 eliminates this problem. For this reason, large-scale bulk deletions that can be problematic on domain controllers running Windows 2000 Server present no significant growth concerns on domain controllers running Windows Server 2003. In addition, online defragmentation on domain controllers running Windows Server 2003 returns the space that is freed by long values to the long-value table, which further optimizes the availability of space in the database.

Bulk Changes and Inheritable Security Descriptors In addition to bulk deletions, large-scale bulk changes can cause database growth, particularly on domain controllers running Windows 2000 Server. The most common cause of database growth on domain controllers running Windows 2000 Server is the propagation of inherited security descriptor changes in a large directory tree. Every object in Active Directory has a security descriptor attribute that contains the identification and authorization values that apply to that object. Authorization information takes the form of discretionary access control lists (DACLs) (access information) and system access control lists (SACLs) (auditing information). Because every object has a security descriptor, a security descriptor change that affects every object in a large tree (for example, an entire domain) can significantly affect database size.

How Inheritable Security Descriptors Are Written The value of the security descriptor attribute changes when a new permission, right, or auditing setting is added or an existing permission, right, or auditing setting is removed from an object’s DACL or SACL by adding, removing, or modifying an ACE. When an inheritable ACE is applied to an object in a directory tree, you can specify the type of object that is affected by the ACE. However, the change is written to every object in the tree, not just to the object type to which the permission, right, or auditing setting applies. The ACE applies to all objects, but it is effective only on objects whose object type matches the object GUID that is specified in the ACE. This system ensures that the appropriate security descriptor can always be inherited from a parent object. For example, suppose you apply an inheritable ACE at the domain level that applies to all computers. Computers exist in container objects, to which the ACE does not directly apply. However, when you create a computer object in the container, the computer object receives its inherited security descriptor from its parent container. Every object that is within the scope of the inheritance receives the update to the security descriptor.

Security Descriptors in Windows 2000 Server On domain controllers running Windows 2000 Server, the full security descriptor value is stored for every object. The average size of a security descriptor is 5 KB, and as a result security descriptors can account for 40 percent or more of

database size. On domain controllers running Windows 2000 Server, an ACL change that is inherited by a large directory tree (for example, a domain) that contains hundreds of thousands or millions of objects can cause significant database growth. For example, suppose you add 30 ACEs to an inheritable SACL or DACL on the domain object of a domain that has 1,000,000 objects. At an estimated 52 bytes per ACE, each object grows by approximately 1.5 KB. The propagation of this change to 1 million objects results in database growth of 1.4 GB. In the worst-case scenario, the database grows beyond its storage limits, and Active Directory cannot function. You can use Active Directory administrative tools to manage security settings on Active Directory objects to a high degree of specificity. Significant and unexpected changes to security descriptors can occur during the management of access control and auditing if an administrator does not understand the effects of the changes. The UI provides the ability to select general ACE categories that have prepopulated permissions, but the UI also provides the ability to modify the properties of a general ACE. The effect of editing an existing general ACE on a DACL or SACL by removing one of the properties is the replacement of a single ACE with multiple ACEs, one for each of the permissions that is selected in the modified ACE. On domain controllers running Windows 2000 Server, such a change can cause significant database growth if the modified ACE is inherited to a large tree of objects. For example, if directory services access auditing is enabled and an administrator edits the access to specify only a subset of the activity and objects to be audited, the result is propagation of a separate ACE for each selection to every object in the tree. Given the default settings for the Everyone group in Windows 2000 Server, such a change can result in significant database growth. Default settings in Windows Server 2003 and the storage of only unique security descriptors greatly decrease the likelihood that such a change can cause unmanageable growth.

Single-Instance Security Descriptors in Windows Server 2003 On domain controllers running Windows Server 2003, the potential for database growth as a result of the volume of changes that might be caused by security descriptor inheritance is mitigated by a new method of storing single instances of unique security descriptors. On domain controllers running Windows Server 2003, a unique security descriptor is stored only once rather than being stored for every object that inherits it. For every object that inherits the security descriptor or otherwise stores an identical security descriptor, only a pointer is stored. This change eliminates data redundancy and the database growth that can result from changes to inheritable ACEs. The object itself stores an 8-byte pointer to the appropriate unique security descriptor. Unique security descriptors are stored in memory in a relatively small table. In addition, the information that is required to map these pointers to the respective security descriptor is cached on domain controllers. By using this cached information and the in-memory table of unique security descriptors, domain controllers can match pointers to security descriptors without having to access the database itself. Therefore, checks to establish whether a new security descriptor matches an existing one have no significant impact on domain controller performance. Note

•

When you upgrade a domain controller from Windows 2000 Server to Windows Server 2003, the conversion of duplicate security descriptors to pointers can result in +40 percent of the database size being converted to unused space. Performing offline defragmentation after the upgrade decreases the database size by removing that unused space.

Effect of Object Ownership on Unique Security Descriptors Having different owners causes objects that would otherwise have the same security descriptor to require several unique security descriptors. For example, if a member of the Domain Admins group creates a container object and sets permissions on the container that are inherited by all child objects, all child objects have the same security descriptor. In this case, only one security descriptor is actually stored in Active Directory; the rest of the objects simply reference that unique security descriptor. However, if objects that are created in the parent container are created by individuals who are not members of the Domain Admins group, those objects have security descriptors that are different from the security descriptors of the objects that are created by members of the Domain Admins group. Despite the fact that having different object owners requires unique security descriptors, most Active Directory databases contain a relatively small number of user objects in comparison to the number of nonuser objects. In addition, most objects are created by the system and not by individual users. Because duplication of security descriptors far outweighs the potential for different object owners, the positive effect of single-instance security descriptors is not usually lessened to a noticeable degree by multiple object owners.

Storage and Removal of Object Deletions When data is deleted from Active Directory, the data cannot simply disappear from the directory because the deletion must be replicated. Therefore, instead of deleting an object physically from the database, the directory service removes most of the attributes and then tags the object as a tombstone by setting the isDeleted attribute value to TRUE, which means that the object has been logically deleted from the directory but not yet completely removed. Tombstones are replicated to communicate object deletions. The isDeleted attribute value alerts replication partners that the object has been deleted. Objects that are identified as tombstones are moved to the hidden Deleted Objects container of their respective directory partition. Tombstones remain in the directory for a default period of 60 days, which is referred to as the tombstone lifetime.

Garbage Collection: Permanent Removal of Expired Tombstones Garbage collection is a housekeeping process that runs on every domain controller to permanently remove expired tombstones from the directory database. Although they represent deleted objects, tombstones take up space in every directory partition replica. Eventually, the tombstones themselves must be deleted to keep the directory database from growing without limit. At regular intervals, objects that are no longer needed by the directory service are deleted as “garbage.” The garbage collection process:

• •

Deletes tombstones. Defragments the database file to compact data and optimize free space (triggers online

defragmentation). Garbage collection runs independently on each domain controller. When the garbage collection process occurs, the process finds the set of tombstones whose originating deletion occurred more than a tombstone lifetime ago, and then it deletes each tombstone in that set. Two attributes of the Directory Service object (nTDSService) in the configuration container (CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=forestRootDomain) control how garbage collection runs and what it removes, as follows:

•

The tombstone lifetime determines the amount of time that a deleted object lives as a tombstone in the directory before being collected as garbage. This amount of time is set in the tombstoneLifetime attribute. The minimum setting is 2 days. The default setting for this attribute varies according to operating system and forest creation or upgrade, as follows:

• •

Forests that were created on a domain controller running Windows Server 2003 with no service pack installed or any version of Windows 2000 Server: 60 days. Forests that were upgraded from Windows Server 2003 with no service pack installed or any version of Windows 2000 Server: 60 days.

•

Forests that were created on a domain controller running Windows Server 2003 with Service Pack 1 (SP1): 180 days.

•

You cannot purge tombstones before the expiration of the tombstone

Note

•

lifetime. The garbage collection interval determines how often a domain controller examines its database for expired tombstones that can be collected. This interval is set in the garbageCollPeriod attribute. The default setting is 12 hours, and the minimum setting is 1 hour. Note

•

The default value for each of these two attributes applies if the attribute is not set (which is the initial state of the system). The minimum value applies if the attribute is set to a value that is below the minimum (that is, if the minimum

is not declared in the schema). The maximum garbage collection interval is one-third of the tombstone lifetime (in hours). For example, if you set tombstoneLifetime to 30 days and garbageCollPeriod to 300 hours, the actual garbage collection period is only 10 days or 240 hours.

Tombstone Lifetime and Active Directory Backup and Restore Active Directory does not allow a restore from a directory backup that is older than the tombstone lifetime. A restore from backup creates a directory partition replica that has not performed replication since the time of backup (or earlier). If the backup is taken more than a tombstone lifetime before the restore, objects that are deleted in the meantime have no tombstones; therefore, a new directory partition replica that is created by the restore operation never receives these

deletions. For this reason, a restore procedure will not restore a backup that is taken more than one tombstone lifetime before the time of the restore. Therefore, it is a recommended best practice to back up Active Directory at least twice during a tombstone lifetime. On domain controllers running Windows Server 2003 with SP1, event ID 2089 in the Directory Service event log provides notification when any directory partition, including application directory partitions and Active Directory Application Mode (ADAM) partitions, has not been backed up since the beginning of a specified time period. By default, this period is half the tombstone lifetime interval, as defined in the registry entry Backup latency interval (days) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. It is likewise important that the tombstone lifetime be substantially longer than the expected replication latency. The default setting of 60 days or 180 days for the tombstone lifetime is generous enough to accommodate unforeseen circumstances. However, monitoring domain controller operation is essential for ensuring that a domain controller does not remain offline without detection. Because the expiration of a tombstone lifetime is based on the time when an object is deleted logically — rather than the time when a particular server receives that tombstone through replication — an object’s tombstone is collected as garbage on all servers at approximately the same time. If the tombstone has not yet replicated to a particular server, that server never records the deletion. A domain controller that becomes outdated by being disconnected from the replication topology for longer than a tombstone lifetime cannot be restored from backup. However, an object that remains on an outdated domain controller is retained if the domain controller is reconnected to the replication topology. An object that remains after its tombstone is deleted is called a lingering object. Such objects create inconsistency in Active Directory and should be removed. For information about removing lingering objects, see "Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)" in "Troubleshooting Active Directory Replication Problems" in the Windows Server 2003 Operations Guide at http://go.microsoft.com/fwlink/?LinkId=44131.

Garbage Collection Scheduling Enhancements The process for completing garbage collection has changed in Windows Server 2003 to improve storage conditions in the directory database. Garbage collection removes a maximum of 5,000 objects per pass to avoid indefinitely delaying other directory service tasks. However, the rate at which remaining tombstones are deleted when more than 5,000 tombstones have expired has increased from Windows 2000 Server to Windows Server 2003, as follows:

•

Windows 2000 Server: If collection stops because of the 5,000-object limit (rather than by running out of objects to collect), the next garbage collection pass is scheduled for half the normal garbage collection interval (by default, every 6 hours instead of 12 hours). Garbage collection continues running at this accelerated pace until all objects have been

•

collected. Windows Server 2003: Rather than waiting a set time to remove a subsequent set of 5,000 tombstones, a domain controller continues deleting tombstones according to CPU availability. If no other process is using the CPU, garbage collection proceeds. Removing tombstones in this way keeps the database size from increasing inordinately as a result of the inability of garbage collection to fully complete removal of all tombstones during a garbage collection interval.

Garbage Collection and Linked Attributes When an object that has a linked attribute is deleted, although the object itself becomes a tombstone (for example, when a user object is deleted), the referent object (for example, a group object to which the user belonged) does not reference the tombstone of the deleted object. Rather, the group-user link value is simply deleted from the database, and the group object shows no evidence of the former user’s membership. However, when an object to which a link refers is removed as a referent (for example, when a user is removed from a group), the user value is treated differently by Active Directory in Windows 2000 Server and in Windows Server 2003. In Windows 2000 Server, the entire group member attribute is replicated. In Windows Server 2003, the link value for the removed user is marked “absent” and then replicated, much like a tombstone.

Reanimating Tombstones — Restoring Individual Objects Online The Windows Server 2003 directory database supports an LDAP API that reanimates the tombstone of a single object (undeletes the object) to avoid the necessity for an offline restore process in the event that an object is deleted unintentionally. This API is available for creating applications to restore the attributes that are preserved on tombstones, which include the object SID, GUID, and security descriptor, as well as any indexed attributes. Note

When the deletion is performed on a domain controller that is running Windows Server 2003 with SP1, the sIDHistory attribute is also retained. Only attributes that are retained on the tombstone are restored; all other data must be recreated. Therefore, to restore an entire deleted container or a set of multiple objects, authoritative restore is still the best option.

Stale Account Detection Stale account detection is required so that unused computer and user accounts can be removed from Active Directory. On domain controllers running Windows Server 2003 and Windows Server 2003 with SP1, these accounts can be identified by the value in the lastLogonTimeStamp attribute of user and computer objects. This attribute identifies the last time that a user or computer successfully logged on to a domain. The attribute value is replicated to all domain controllers in the domain. lastLogonTimeStamp is new in Windows Server 2003, and its use is enhanced in Windows Server 2003 with SP1.

Scenarios that generate stale accounts The following common scenarios result in the proliferation of computer and user accounts that are often abandoned by the users who create the accounts:

•

Delegated computer account creation, which is common in corporate environments, provides the freedom to create

• •

Web applications allow external partners to create and manage user accounts that are provided by the host company.

multiple accounts but no requirement for deleting them. Employees leave the company.

Detection of successful password verification In earlier versions of Windows, the pwdLstSet attribute was used to identify stale accounts. However, many conditions interfere with the accuracy of this method, such as users who are on sabbatical or otherwise temporarily not using an account. In addition, password time limits can vary throughout an organization. The most efficient way to identify an account that is stale is by evaluating the last time that the user successfully logged on to the domain, rather than the last time the password was reset. The introduction of the lastLogonTimeStamp attribute in Windows Server 2003 provides the ability to mark an account each time that the system is asked to validate the account password (that is, at logon) for NTLM and Kerberos authentication. These two security protocols update the lastLogonTimeStamp attribute during successful authentication.

Implementation in the domain Updates to lastLogonTimeStamp are replicated in the domain directory partition. Therefore, the value of this attribute can be checked on any domain controller in the domain. To minimize the effect of domain-wide replication every time that a user or computer logs on, lastLogonTimeStamp is updated only periodically. The period of update is configurable, as follows:

• • •

Object: DC=DomainName Attribute: msDS-LogonTimeSyncInterval Default value: 14 days

Because the lastLogonTimeStamp attribute is available only when the Windows Server 2003 schema is in effect on all domain controllers in the domain, the feature is activated when the domain functional level is raised to Windows Server 2003. After the domain functional level increase, the first time that a successful logon occurs, the lastLogonTimeStamp attribute is activated on the user or computer object. This method of activation can result in loopholes for certain accounts, as follows:

•

Accounts that are created before the domain functional level increase but that are not used

•

Accounts that are created after the domain functional level increase but that are not used

subsequently

In these cases, lastLogonTimeStamp is not present on the account object. To identify these accounts, you can query for user and computer objects that have no lastLogonTimeStamp attribute and that have a value in the whenCreated attribute that is earlier than or equal to a specified date. For example, suppose a user account is created on 1/1/2005. The user leaves the company on 5/1/2005. The domain functional level is raised on 6/1/2005. On 9/1/2005, you query for accounts that do not have the lastLogonTimeStamp attribute. The query returns the account of the user who left the company before the raising of the functional level. However,

you need to know if the account was created recently and has not yet been used or if the account was created before the functional level increase and is legitimately out of use. To answer this question, you query for accounts that do not have the lastLogonTimeStamp and that have a whenCreated value of 8/15/2005 or earlier. You select this date on the assumption that any account that was created within the last two weeks will have been used and any account that was created between June 1 and August 15 will certainly have been used. Accounts that are returned by the query are therefore legitimately out of use and can be deleted.

Randomization mechanism for initial use of lastLogonTimeStamp To avoid network overloads due to thousands of concurrent lastLogonTimeStamp updates when the domain functional level is raised, a five-day window is used to calculate whether the lastLogonTimeStamp value should be updated. The following randomization mechanism is applied to control updates after the domain functional level is raised: 1.

At the time that the functional level is raised, the default value of 14 days for msDS-LogonTimeSyncInterval is used,

2. 3. 4.

regardless of whether a different value is set in the attribute. The value in lastLogonTimeStamp is used to determine the number of days since the last valid logon of the account. A random percentage of the value 5 is taken and then subtracted from the value in msDS-LogonTimeSyncInterval. If the result is greater than or equal to the value in lastLogonTimeStamp, the value in lastLogonTimeStamp is

updated. For example, suppose that the value in lastLogonTimeStamp indicates 12 days since the last successful logon. Suppose also that the random percentage is 80 percent of 5 = 4. With the default value of 14 days in effect for msDSLogonTimeSyncInterval, the calculation is 14 - 4 = 10. Because 12 > 10, lastLogonTimeStamp is updated. In this example, in all cases where the value is less than 10, lastLogonTimeStamp is not updated until the first successful logon that occurs after the msDS-LogonTimeSyncInterval value is reached. Note If the value in msDS-LogonTimeSyncInterval is set to 0, the stale account detection feature is disabled and lastLogonTimeStamp is not updated.

Security protocols that update lastLogonTimeStamp in Windows Server 2003 In the initial implementation of lastLogonTimeStamp in Windows Server 2003, lastLogonTimeStamp is updated by the following authentication protocols:

• •

NTLM Kerberos

Security protocols notify the directory database of a successful logon so that the account can be marked appropriately in the lastLogon and lastLogonTimeStamp attributes. Therefore, to use stale account detection effectively, it is important that administrators are aware of the security protocols that are in use in their environments. For example, in Windows Server 2003 environments, the following security protocols request that the system validate a user password:

• • • • •

Secure channel setup (computer accounts only)

• • •

Schannel, when mapped to an account

NTLM authentication (both interactive and network) Kerberos authentication Digest authentication Third-party Security Support Provider Interfaces (SSPIs) when using the LSA APIs

The following security protocols can reference an account for a security operation:

Kerberos Service-for-User (S4U) logons AuthZ APIs in non-S4U mode

The obvious problem is that some accounts might be authenticated without updating the lastLogonTimeStamp, and if this detection method is relied on for stale account cleanup, accounts might be deleted that are still in use. For example, the following issues occur in Windows Server 2003 implementations:

• •

The NTLM authentication protocol does not update the lastLogonTimeStamp attribute for all network logons. NTLM is therefore not reliable for stale account detection. The Kerberos S4U authentication protocol, which is used for Web single sign on (SSO) provisioning, does not update lastLogonTimeStamp. Specifically, when extranet users log on to servers running Microsoft Internet Information

Services (IIS), Active Directory user accounts are mapped to certificates that are trusted by the IIS server. These certificates are distributed to the client computer so that users do not have to specify credentials. (That is, they are not directly authenticated by a security protocol.)

lastLogonTimeStamp improvements in Windows Server 2003 SP1 Windows Server 2003 SP1 corrects the problems of some protocols not updating lastLogonTimeStamp, as follows:

• •

The inconsistency of NTLM updates of lastLogonTimeStamp is corrected. Updates to the Key Distribution Center (KDC) ensure that lastLogonTimeStamp is updated in Active Directory when a user logs on to a protected IIS Web site.

Scripting stale account detection You can implement a scripting solution for managing stale account detection and cleanup. For more information about lastLogonTimeStamp and instructions for creating scripts, see "Dandelions, VCR Clocks, and Last Logon Times: These are a Few of Our Least Favorite Things" on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=47965.

Database Defragmentation As described earlier in this section, the database system uses the quickest way to fill database pages. Although this system is efficient in searching and updating the database quickly, it does not make the most efficient use of space in the database. As write operations occur and data pages fill, a certain amount of space often remains in a page that cannot be used by other transactions because the space is not large enough. In addition, space that is freed by version store cleanup is returned to the owning indexes or tables in noncontiguous chunks. Therefore, free space that exists in the database is not always available for use because it is fragmented. Defragmentation rearranges how the data is stored in the database, compressing the data and making free space available in contiguous pages. Free space is managed automatically during database defragmentation. Database defragmentation can take place online (while the computer is running as a domain controller) or offline (while the computer is running in Directory Services Restore Mode). Defragmentation has different effects on database size, depending on whether defragmentation is run while the domain controller is online or offline:

• •

Online defragmentation: Occurs automatically by default. Online defragmentation compacts data and optimizes free space for database use, thereby maintaining the file size of the database. Offline defragmentation: Occurs only manually in Directory Services Restore Mode. Offline defragmentation compacts data and returns free space to the file system, thereby decreasing the file size of the database.

Online Defragmentation During online defragmentation, space in partially filled data pages is reorganized to consolidate it into full 8-KB pages. In addition, any pages that have been skipped by version store cleanup are reclaimed for use by the database. Online defragmentation returns a freed page directly to the part of the tree (database, object table, index, or long-value table) that owns the page that is being freed. When a sufficient number of contiguous free pages (approximately 16) exist in a given child tree, the space is released to the parent tree. Note

•

On domain controllers running Windows 2000 Server, online defragmentation does not reclaim free space that is deleted from long-value tables.

Automatic online defragmentation Both Windows 2000 Server–based and Windows Server 2003–based domain controllers perform online defragmentation automatically. The ESE invokes online defragmentation after each garbage collection, which occurs every 12 hours by default.

Manual online defragmentation On domain controllers running Windows Server 2003, you can prompt online defragmentation to run manually. Although online defragmentation occurs automatically following garbage collection and the garbage collection interval is known and configurable, the duration of the garbage collection process is variable, depending on how many tombstones have expired and the load requirements of the domain controller at the time of garbage collection. The variable nature of garbage

collection can cause unpredictable performance between the time garbage collection begins and online defragmentation completes. By performing online defragmentation during off-peak hours, you can ensure more-even directory performance during peak hours. To control when online defragmentation occurs, you can configure domain controllers running Windows Server 2003 as follows:

•

To start online defragmentation manually at any time, irrespective of garbage collection intervals, you can add the operational attribute doOnlineDefrag to the rootDSE object. The value of this attribute dictates the duration (in seconds) for which online defragmentation runs. After setting this attribute value, you can create a script that takes the duration as

•

input so that online defragmentation can be triggered by the script at any time for any duration of runtime. If you want online defragmentation to always occur only on demand, you can configure the registry so that automatic online defragmentation is disabled. Note

•

The information here is provided as a reference for use in troubleshooting or verifying that the required settings are applied. It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry

directly. If you must edit the registry, use extreme caution. You do not have to disable automatic online defragmentation to manually start online defragmentation. After you add the doOnlineDefrag attribute, you can start manual online defragmentation at any time that conditions warrant it, while allowing automatic online defragmentation to continue as well.

Offline Defragmentation Offline defragmentation rebuilds the directory database and releases unneeded space back to the file system. Offline defragmentation must be performed in Directory Services Restore Mode, which restarts the computer as a stand-alone server, that is, as a computer that is not acting as a domain controller. In Directory Services Restore Mode, you can use the ntdsutil command-line tool to defragment the Ntds.dit file. Offline defragmentation produces a defragmented version of the database file in a separate directory. You can archive the original Ntds.dit file and move the defragmented file into the current directory. Only offline defragmentation provides a clear picture of the amount of space that is consumed by the database file. You can use offline defragmentation to test database growth by comparing the defragmented version of the file with the fragmented version. For example, on a newly installed domain controller, if you perform a bulk load of objects and then defragment the database file offline, the difference between the two files is the space that is occupied by the new objects. There is no standard or optimal value for the percentage of free space that might exist in the database at any given time. If you are concerned about database size, set the DSA to log a message in the Directory Service event log during garbage collection that states how much disk space could be freed up through offline defragmentation.

Linked Attribute Management Attributes of certain objects can be linked in the directory database to attributes of other objects to provide interobject references from one object back to the other object for either usability or administrative purposes. For example, a user object can be a member of a group, and a group can have users and groups as members. To define this relationship, the group object has a member attribute that can have multiple values of the distinguished names of every user, computer, or group that has membership in the group. Similarly, the user, computer, and group objects have a multivalued memberOf attribute that identifies all the groups to which a user, computer, or group belongs. These attributes are “linked” in the Active Directory database so that you can, for example, look at the member attribute on the object GroupA and determine that UserB is a member of GroupA. Likewise, you can look at the memberOf attribute on the object UserB and determine that UserB belongs to GroupA. The GUID of an object unambiguously indicates which object the linked value applies to, even if the object has been renamed, deleted, or garbage-collected (permanently removed from the database). Individual values of multivalued attributes do not have an associated GUID. Instead, a link-value identifier serves the purpose of distinguishing existing values (including value tombstones) from values that have been garbage-collected and then recreated. This identifier, called

the link ID, remains fixed from the creation of the value until the value is garbage-collected. When the originating server creates a new value, an ID is assigned to the value. Linked values replicate with the GUID of the object that contains them.

Effect of Moving Linked Objects Active Directory maintains referential integrity between objects that reference each other by distinguished name so that when one object is moved in the directory tree, the referencing object can track the referenced object. For example, an object UserB is a member of GroupA. If you move the object UserB from the CN=Users,DC=concorp,DC=contoso,DC=com container to the OU=Sales,DC=concorp,DC=contoso,DC=com OU, the distinguished name value for UserB in the member attribute on the GroupA object automatically changes as follows:

• •

Before the move: CN=UserB,CN=users,DC=concorp,DC=contoso,DC=com After the move: CN=UserB,OU=sales,DC=concorp,DC=contoso,DC=com

This change occurs as soon as the move occurs. In this way, linked attributes effectively share their values.

Identifying Link Pairs The sharing of values by linked attributes is achieved when two attributes are marked in the schema as having the same link-pair identifier — one is marked as the forward link (it points to another object in the directory) and the other as the back-link (it points back to the object that has a forward link to it). Changing the forward link attribute on one object affects the back-link on the referenced object. In the current example, the member attribute is the forward link and the memberOf attribute points back to the value in member. For reasons that relate to security and replication, only the forward-linked attribute can be modified. Note

•

The decision to link two objects must be made at the time that the objects are added to the

schema. To find all the objects that are members of GroupA, links are examined for all records in which the link pair is member/memberOf and the back-linked attribute identifies GroupA. The link pairs of those records provide the database identifiers of all the records (objects) that are members of GroupA. The member and memberOf example uses a multivalued forward link and a multivalued back-link, but there is no requirement that the forward link be a multivalued link. For example, each group has one manager, but a manager can manage multiple groups. This relationship is identified in the database by the manager/directReports link pair, where manager is a single-valued attribute of a user object and directReports (common name Reports) is a multivalued attribute of a user object. The back-linked attribute must always be multivalued because it is impossible to restrict who creates links to various objects.

Deleting Linked Objects When an object that is linked through a multivalued attribute is deleted, all of its linked attribute values are removed from the respective linked objects. In the preceding example, if a user manages multiple users and one of the users is deleted, the directReports multivalued attribute on the user object of the user that is the manager suddenly (and with no change to any replication-related metadata) loses a value. Similarly, if the user object for the manager is deleted, the value of the manager attribute on the user object of the user who was a direct report is suddenly blank. Nothing about the nondeleted object changes in either case, except that the attribute value is gone.

Restoring Linked Objects and Their Back-Links When objects are deleted by mistake, you can restore them in Active Directory by performing an authoritative restore of the deleted objects. You perform authoritative restore by restoring the domain controller from its latest backup and then marking the deleted objects as authoritative so that they are not removed by replication. However, when an object that has back-links is restored on a domain controller running Windows 2000 Server, its back-links are not restored as part of the authoritative restore process. For example, when user objects or group objects are deleted and then authoritatively restored, the memberOf values must be restored manually. You must add a restored user or group back to the groups to which it belonged at the time that its account was deleted.

On domain controllers running Windows Server 2003 in a forest that has a forest functional level of Windows Server 2003 or Windows Server 2003 interim, back-links are restored automatically for authoritatively restored objects under the following conditions:

• •

The link was added after the forest functional level was raised to Windows Server 2003 or Windows Server 2003 interim (linked-value replication was in effect). Replication of a restored user object precedes replication of a restored group to which it belongs when the user and group

are both authoritatively restored at the same time. If the domain controller on which you are authoritatively restoring objects is running Windows Server 2003 with SP1, you can use the Windows Server 2003 SP1 version of Ntdsutil to restore back-links for any authoritatively restored objects that have links, including objects in different domains. For more information about how to restore back-links on domain controllers running Windows Server 2003 with SP1, see "Performing an Authoritative Restore of Active Directory Objects" in "Administering Active Directory Backup and Restore" in the Windows Server 2003 Operations Guide at http://go.microsoft.com/fwlink/?LinkId=44194. For more information about replication of deleted linked objects, see “Active Directory Replication Model Technical Reference”.

Phantom Records for Interdomain Object References An attribute that has a distinguished name as a value references (points to) the named object. When the referenced object does not actually exist in the local directory database because it is in a different domain, a placeholder record called a phantom is created in that database as the object reference. Because there is a reference to it, the referenced object must exist in some form, either as the full object (if the domain controller stores the respective domain directory partition) or as an object reference (when the domain controller does not store that domain). A phantom record contains the GUID and the distinguished name of the object that is being referenced. In the case of references to security principals, the phantom also contains the SID. A common example of a distinguished name value that references an object in a different domain is the nCName attribute of a cross-reference (crossRef) object. Every domain controller stores a cross-reference object (in the configuration directory partition) for every other domain directory partition in the forest. Therefore, the nCName attribute value for every cross-reference object necessarily references a phantom in the local directory database.

Infrastructure Master and Phantom Records The infrastructure master is a single domain controller in each domain that tracks name changes of referenced objects and updates the references on the referencing object. When a referenced object is moved to a different domain (which effectively renames the object), the infrastructure master updates the distinguished name of the phantom. (The infrastructure master finds phantom records by using a database index that is created only on domain controllers that hold the infrastructure operations master role.) When the reference count of the phantom falls to zero (no objects are referencing the object that the phantom represents), garbage collection on each domain controller removes the phantom. Note

•

Because objects can reference objects in different domains, the infrastructure operations master role is not compatible with global catalog server status if there is more than one domain in the forest. If a global catalog server holds the infrastructure operations master role, phantom records are never created because the referenced object is always located in the directory database on the global catalog server.

Ownership Quotas on Directory Objects On domain controllers running Windows Server 2003, you can specify quotas that limit the number of objects that a security principal (user, group, computer, or service) can own in a domain, configuration, or application directory partition. By default, the security principal (or administrative group in some cases) that creates an object is the object owner, although ownership can be transferred. With Active Directory quotas, no one can create unlimited numbers of objects in a directory partition, which is a method that can be used to launch denial-of-service attacks. Note

•

The term “user” in this discussion of security principals indicates both the user and inetOrgPerson classes of objects.

By default, quotas are not set, so there are no limits to the number of objects that can be owned by any security principal. For each target directory partition, you can set different limits for different security principals or you can set limits that apply to all security principals, or you can do both. Quotas can be set per directory partition, except for the schema directory partition, which does not support quotas. You can set quotas to apply to security principals for a directory partition by using the command line. Use the following commands to manage quotas:

• • • •

dsadd quota to set quotas for a directory partition dsmod quota to modify existing quotas dsmod partition to modify default quota settings for a partition dsquery quota to search for quota assignments and quota

consumption For more information about directory quotas and how to use dsadd, dsmod, and dsquery commands to manage directory quotas, see “Data Store Tools and Settings”.

Quota Assignment Objects Quota assignments for security principals are represented in a directory partition as instances of the object class msDSQuotaControl. Each object in this class has the following attributes:

•

Common-Name: The relative distinguished name (RDN) of the security principal object. This mandatory value should be

• •

msDS-QuotaTrustee: The SID of the security principal (user, computer, or group) for which the quota is being assigned.

•

Flags: This optional attribute is reserved for future use.

a friendly name (or sAMAccountName) of the security principal whose quota is being specified. msDS-QuotaAmount: The mandatory value of the assigned quota (number of objects owned in the database) for the security principal. A value of -1 for this attribute denotes an unlimited quota.

Instances of msDS-QuotaControl objects are stored in a well-known container called NTDS Quotas in the directory partition to which the quota applies.

Quota Containers The NTDS Quotas container (class msDS-QuotaContainer) is a special system container that the quota system uses. The NTDS Quotas container has the following characteristics:

•

It is a child object of the root of a parent directory partition (including domain, configuration, and application directory

• •

It cannot be deleted, but it can be renamed.

partitions). It is tracked by the parent container through the wellKnownObjects attribute on the parent container.

Each directory partition has exactly one well-known NTDS Quotas container that stores explicit quota assignment objects for the partition. Two attributes of this well-known container specify a default quota value and how quotas are computed for that directory partition:

•

msDS-DefaultQuota: A default quota that applies to any security principal that creates objects in the directory partition and for which no explicit quota assignment exists. If no value is set for this attribute or if the attribute has the value -1, there is no default quota for the directory partition. In this case, security principals that do not have explicit quotas assigned have the ability to create unlimited objects in that directory partition, subject to access control. The default value for msDS-DefaultQuota on a directory partition is unlimited (not set). To manage this value, use the dsmod partition

•

command. msDS-TombstoneQuotaFactor: The percentage factor by which tombstone object count should be reduced for the purpose of quota accounting. By default, the setting is 100, which means that a tombstone (a deleted object) that was originally created by a security principal is equal to 1 object of that user’s quota. If the percentage factor were set to 50, each tombstone would represent only half an object rather than an entire object. Likewise, a tombstone quota factor of 25 means that four tombstones are the equivalent of 1 owned object. In this way, the quota for a security principal is computed relative to objects and tombstones. To manage this value, use the dsmod partition command.

Tracking Object Ownership To enforce compliance with Active Directory quotas, object ownership is tracked by each domain controller running Windows Server 2003. After a domain controller is upgraded to Windows Server 2003, the system determines the number of objects that are owned by each security principal and for each directory partition that the domain controller hosts, and the system generates a tracking table for internal object ownership to track quota consumption. Thereafter, when objects are created, deleted, or reanimated or their ownership is transferred in a directory partition that the domain controller hosts, the quota tracking data is suitably updated.

Enforcing Quotas Quotas are enforced only on originating updates and only by domain controllers running Windows Server 2003. When an update originates on a Windows Server 2003 domain controller, quotas are enforced. At the time of the operation, if the requestor is not exempt from quotas, the effective quota limit for the requestor is computed on the basis of the default quota setting for the directory partition or any explicit quota assignments. Further, the requestor’s current quota consumption is computed using the object ownership tracking data and the tombstone quota factor. If the pending object transaction (create, delete, reanimate, or transfer of ownership) causes the quota limit to be exceeded, the transaction fails. If an originating update occurs on a domain controller running Windows 2000 Server, quotas are not enforced. However, as Windows Server 2003 domain controllers receive replicated updates, regardless of their origin, they update object ownership tracking data for the respective security principal. Thus, although Windows Server 2003 domain controllers can always update quota tracking data, quotas are effectively enforced at the domain level only when all domain controllers in the domain are running Windows Server 2003 and at the forest level (for the configuration directory partition) only when all domain controllers in the forest are running Windows Server 2003.

Effective quota Multiple quota assignments can exist for a given security principal through an individual quota assignment or through quota assignments for one or more security groups of which the principal is a member, or both. When multiple quota assignments exist for a security principal, the effective quota is computed to be the maximum of the applicable quota assignments that are specified. For example, if a user belongs to two groups that have different quotas specified for the same directory partition, the higher of the two quota values applies to the user. If no quota assignments are specified for a security principal or for any of the security groups of which the security principal is a member, the effective quota is the default quota that is specified for the directory partition in the msDS-DefaultQuota attribute on the NTDS Quotas container.

Quota exemptions Members of the Domain Admins and Enterprise Admins groups are exempted from all quota-imposed limits.

Using Quotas You can use quotas in combination with security groups to manage objects that are created in Active Directory. The following examples illustrate using a default quota, with exceptions to set explicit quota assignments for those groups that need the ability to create large numbers of objects.

Managing DNS data in application directory partitions When you use Active Directory–integrated DNS, zone data can be stored in the domain directory partition, if you want DNS data to replicate to all domain controllers, or in application directory partitions, if you want DNS data to replicate only to domain controllers that are DNS servers. To decrease domain-wide replication and avoid replicating zone data to the global catalog, you can take advantage of application directory partitions on DNS servers running Windows Server 2003. By default, members of the Authenticated Users group have the ability to create resource records on DNS servers that are in the domain of the client computer. This ability is required to allow all computers to dynamically update DNS zone data. A typical authenticated user needs to register a maximum of 10 records in DNS. To ensure that malicious users or applications do not create inappropriate resource records, you can set a default quota on the application directory partitions ForestDnsZones and DomainDnsZones, which are

replicated to every DNS server in the forest and domain, respectively. A default limit of 10 objects ensures that all computers can update DNS appropriately but cannot launch denial-of-service attacks.

Explicit quotas for domain controllers and other servers The number of resource records that must be registered in DNS is significantly greater for domain controllers and for multihomed computers that register adapter-specific records for all of their connections. To accommodate the resource record requirements of atypical authenticated users such as domain controllers, multihomed computers, and multiadapter servers, you can create special groups for these specific types of computers. For example, you might create the Enterprise Domain Controllers group that has all domain controllers as members. To ensure that this group can create the maximum DNS resource records that might be required, set a quota of 300 to 400 objects for this group on the DomainDnsZones and ForestDnsZones application directory partitions. The same rule applies to servers such as virtual private network (VPN) or Web servers, which are required to register a large number of resource records in DNS. Depending on how many adapter-specific resource records your VPN or Web server must register, you can create a group for those servers and assign the appropriate quota to ensure that the Authenticated Users default quota does not apply.

Explicit quotas for DHCP servers To allow DHCP servers to have essentially unlimited ability to create resource records when clients depend on DHCP-assigned IP addresses, you can create a group that contains all DHCP servers in the domain or forest and then set an explicit quota assignment for that group on the DomainDnsZones and ForestDnsZones application directory partitions, respectively. Set a quota that is appropriate to the number of clients for which your DHCP server registers records, multiplied by the upper limit of the number of records registered per computer. In this way, DHCP servers can update DNS with client resource records as needed.

Managing print objects in domain directory partitions When Active Directory is used to publish shared printing resources, print servers require the ability to create potentially large numbers of objects in Active Directory. Print servers publish printers in Active Directory as print queue objects (class printQueue), which are child objects of the print server computer object and which contain a subset of the information that is stored on the print server for a printer. When print servers go offline for any reason, they must republish their print queues when they return to service. For this reason, print servers require the ability to create large numbers of objects in the domain directory partition. To ensure that print servers can create appropriate numbers of objects in the domain, you can create a group that contains all print servers in the domain and then specify an explicit quota assignment on the domain that is higher than the default assignment. Top of page

Network Ports Used by the Data Store The network ports that are used by the data store are listed in the following table. Port Assignments for the Data Store

Service Name

UDP

TCP

LDAP

None 389

LDAP SSL

None 636

RPC Endpoint Mapper

135

Global Catalog LDAP

None 3268

135

Global Catalog LDAP SSL None 3269 Top of page

Data Store Tools and Settings Updated: March 28, 2003

In this section

• • • • •

Data Store Tools Data Store Registry Entries Data Store Group Policy Settings Data Store WMI Classes Network Ports Used by the Data

Store This section contains information about the tools, registry entries, Group Policy settings, Windows Management Instrumentation (WMI) classes, and network ports that are associated with the data store.

Data Store Tools The following tools are associated with the data store.

Adsiedit.msc: ADSI Edit Category This tool ships with Support Tools for Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition •

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional ADSI Edit is a Microsoft Management Console (MMC) tool that you can use to view and modify directory objects. To find more information about ADSI Edit, see Support Tools Help in Tools and Settings Collection.

Csvde.exe: Csvde Category This tool ships with Windows Server 2003.

Version compatibility

Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Csvde to import and export data from Active Directory by using files that store data in the comma-separated value (CSV) file format standard. Csvde also supports batch operations that are based on CSV. To find more information about Csvde, see “Command-Line References” in Tools and Settings Collection.

Dsadd.exe: Dsadd Category This tool ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsadd to add specific types of objects to the directory. To find more information about Dsadd, see “Command-Line References” in Tools and Settings Collection.

Dsget.exe: Dsget Category This tool ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

•

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsget to display the selected properties of a specific object in the directory. To find more information about Dsget, see “Command-Line References” in Tools and Settings Collection.

Dsmod.exe: Dsmod Category This tool ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition • Windows Server 2003, Web Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

Can Be Run From

Can Be Run Against

Computers running:

• Windows XP Professional You can use Dsmod to modify an existing object of a specific type in the directory. To find more information about Dsmod, see “Command-Line References” in Tools and Settings Collection.

Dsmove.exe: Dsmove Category This tool ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsmove to move a single object, within a domain, from its current location in the directory to a new location. You can also use Dsmove to rename a single object without moving it in the directory tree. To find more information about Dsmove, see “Command-Line References” in Tools and Settings Collection.

Dsquery.exe: Dsquery Category This tool ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

Can Be Run From

• Windows Server 2003, Datacenter Edition Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

Can Be Run Against

• Windows Server 2003, Datacenter Edition • Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsquery to query Active Directory according to specified criteria. To find more information about Dsquery, see “Command-Line References” in Tools and Settings Collection.

Dsrm.exe: Dsrm Category This tool ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Dsrm to delete an object of a specific type, or any general object, from the directory. To find more information about Dsrm, see “Command-Line References” in Tools and Settings Collection.

Ldifde.exe: Ldifde Category This tool ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

•

Windows Server 2003, Standard Edition

•

Windows Server 2003, Enterprise Edition

•

Windows Server 2003, Datacenter Edition

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition Computers running:

• Windows XP Professional You can use Ldifde to create, modify, and delete directory objects on domain controllers. You can also use Ldifde to extend the schema, export Active Directory user and group information to other applications or services, and populate Active Directory with data from other directory services. To find more information about Ldifde, see “Command-Line References” in Tools and Settings Collection.

Ldp.exe: Ldp Category This tool ships with Support Tools for Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

Servers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition • Windows Server 2003, Web Edition Computers running:

• Windows XP Professional

• Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server

Ldp is a Lightweight Directory Access Protocol (LDAP) graphical user interface (GUI) tool that you can use to perform operations such as connect, bind, search, modify, add, and delete against any LDAP-compatible directory, such as Active Directory. You can also use Ldp to view objects that are stored in Active Directory, along with their metadata, for example, security descriptors and replication metadata. You can use the online dbdump feature in Ldp to view values that are stored in the database while the domain controller is running. You can trigger dbdump by modifying the dumpDatabase attribute on the rootDSE. To find more information about Ldp, see “Support Tools Help” in Tools and Settings Collection.

Ntdsutil.exe: Ntdsutil Category This tool ships with Windows Server 2003.

Version compatibility Can Be Run From

Can Be Run Against

Domain controllers running:

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Datacenter Edition

You can use Ntdsutil to perform Active Directory database maintenance, manage and control single master operations, and remove metadata left behind by domain controllers that are removed from the network without being properly uninstalled. This tool is intended for use by experienced administrators. To find more information about Ntdsutil, see “Command-Line References” in Tools and Settings Collection. Top of page

Data Store Registry Entries The following registry entries are associated with the data store. The registry entries under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics control the logging level for the component or process that is specified in the entry name. The value for each entry is set to an integer from and including 0 (no logging) through 5 (most verbose logging). The registry entries under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters control or contain information about the configuration of the data store. The information here is provided as a reference for use in troubleshooting or verifying that the required settings are applied. It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics The following registry entries are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.

3 ExDS Interface Events Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version

Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that result from communication between Active Directory and Microsoft Exchange clients.

4 MAPI Interface Events Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that result from communication between Active Directory and Microsoft Exchange clients.

6 Garbage Collection Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are generated when objects that are marked for deletion are actually deleted.

7 Internal Configuration Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of internal operations.

8 Directory Access Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of read and write operations to directory objects from all sources.

9 Internal Processing Registry path

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are related to internal directory service operations.

11 Initialization/Termination Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are generated by starting and stopping Active Directory.

12 Service Control Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of Active Directory service events.

13 Name Resolution Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are generated by the resolution of addresses and Active Directory names.

14 Backup Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are related to backing up Active Directory. Specifically, controls the logging of events that occur when Extensible Storage Engine (ESE) database records are read or written during backup.

16 LDAP Interface Events Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are related to LDAP.

18 Global Catalog Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are related to the global catalog.

22 DS RPC Client Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are related to communication between Directory System Agents (DSAs). Examples of such communication include replication and the forwarding of look-ups to a global catalog. Examples of logged events include remote procedure call (RPC) errors, canceled calls, Domain Name System (DNS) resolution failures, and service principal name (SPN)–related operations.

23 DS RPC Server Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are related to a DSA acting as an RPC server. A DSA acts as an RPC server, for example, during outbound replication, replication setup operations, cross-domain moves, and membership queries or when a client makes a look-up call.

24 DS Schema Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls the logging of events that are related to schema errors and operations. Such errors and operations include schema additions, deletions, modifications, look-up errors, look-up failures, and caching errors.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters The following registry entries are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

Configuration NC Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Contains the distinguished name of the configuration directory partition.

Database Backup Path Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Determines the directory that is used as the target directory when online backups of the directory database are performed.

Database Log Files Path Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Determines the directory path that is used to store Active Directory log files.

Database Logging/Recovery Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Controls a Microsoft Jet database engine parameter called JET_paramRecovery that determines whether database operations are logged.

DS Drive Mappings Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Used to track local drive mapping names, so that the database file can be located if drive mappings are modified.

DSA Database File Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Determines the file that is used by the domain controller for storing Active Directory objects.

DSA Working Directory Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Determines the working directory of Active Directory.

Hierarchy Table Recalculation Interval (minutes) Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version

Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Determines how frequently the hierarchy table for the directory database is built. The hierarchy table is used only by the Messaging API (MAPI) interface.

Ldapserverintegrity Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Determines whether connection integrity is required (by means of checksum-signed packets) for LDAP connections.

Machine DN Name Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Contains the distinguished name of the computer on which the domain controller is running.

Root Domain Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Contains the distinguished name of the root domain of the Active Directory forest to which the domain controller is connected.

Schema Version Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Contains the schema version for which a particular operating system is configured.

System Schema Version Registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version Domain controllers running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Contains the version of the schema at the time that a backup is taken. This value is used to prevent an incompatible schema version from being restored from backup. Top of page

Data Store Group Policy Settings The following table lists and describes the Group Policy settings that are associated with the data store. Group Policy Settings Associated with the Data Store

Group Policy Setting

Description

Audit Directory

When it is enabled, this Group Policy setting causes successful and failed directory access events to

Services Access

be logged in the Directory Service event log.

Top of page

Data Store WMI Classes The following table lists and describes the WMI classes that are associated with the data store. WMI Classes Associated with the Data Store

Class Name

Namespace

Version Compatibility

rootDSE

root\directory\LDAP Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition • Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server DS_LDAP_Class_Containment

root\directory\LDAP Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition • Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server DS_LDAP_Instance_Containment root\directory\LDAP Domain controllers running:

• Windows Server 2003, Standard Edition

Class Name

Namespace

Version Compatibility

• Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition • Windows 2000 Server • Windows 2000 Advanced Server • Windows 2000 Datacenter Server For more information about these WMI classes, see “Mapping Active Directory to WMI” in the WMI SDK documentation on MSDN. Top of page

Network Ports Used by the Data Store The network ports that are used by the data store are listed in the following table. Port Assignments for the Data Store

Service Name

UDP

TCP

LDAP

None 389

LDAP SSL

None 636

RPC Endpoint Mapper

135

Global Catalog LDAP

None 3268

135

Global Catalog LDAP SSL None 3269 Top of page