How Domains and Forests Work

Artikel
11/19/2014

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

How Domains and Forests Work

In this section

Domain and Forest Structure
Active Directory Objects
Domain and Forest Protocols and Programming Interfaces
Domain and Forest 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.

Note

In Windows 2000 Server and Windows Server 2003, the directory service is named Active Directory. In Windows Server 2008 and Windows Server 2008 R2, the directory service is named Active Directory Domain Services (AD DS). The rest of this topic refers to Active Directory, but the information is also applicable to Active Directory Domain Services.

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.

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 intra-forest 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 two-way, 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
Trust Relationships
Forest Root
Domain Trees and Child Domains
Domain Names

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

Transitive Trusts Facilitate Cross-Domain Access

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 or higher, 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. There is no interoperability between Windows Server 2008 and higher domains and Windows NT 4.0 domains.

Note

WINS and NetBIOS are not required in an environment where computers run only Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 or Windows Server 2008 R2, 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. There is no interoperability between Windows Server 2008 based domains and Windows NT 4.0 domains.

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, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2–based computers in general and Windows 2000 Server,Windows Server 2003, Windows Server 2008 and Windows Server 2008 R2–based domain controllers in particular.

For more information about domain names, see “How DNS Support for Active Directory Works.”

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 and later 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.

Active Directory is a Lightweight Directory Access Protocol (LDAP)-compliant directory service. In Windows Server 2003 and higher 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.

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.

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.

Canonical Name

By default, the user interface in Windows 2000 and higher operating systems, 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 Windows 2000 and higher 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 uppercase or lowercase characters except for the following:" / \ [ ] : ; | = , + * ? <>
A user name, computer name, or group name cannot consist solely of periods (.) or spaces.

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 FMiller@Wingtiptoys.com. 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 user@sales.westcoast.microsoft.com. 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 — userName@microsoft.com. This gives the user in the example the UPN name of user@microsoft.com.

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 user@sales.westcoast.microsoft.com), you provide a single UPN suffix for all users (so that the user then becomes simply user@microsoft.com), 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 first)
Root domain
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 or higher operating systems, refers to the SAM account name as User logon name (pre-Windows 2000). There is no interoperability between Windows Server 2008 or higher domains and Winows NT 3 and Windows NT 4.0 domains.

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 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.

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 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 as the authentication standard for LDAP.
Attribute values and distinguished names can be internationalized using 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.

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 version 2 (NTLMv2) authentication protocol is a challenge/response authentication protocol. It is supported in Windows Server 2008, Windows Vista, Windows Server 2003, Windows 2000, and Windows XP, but it is not the default authentication protocol. Kerberos v5 is the default for these versions except when exchanging communications with a computer running Windows NT Server 4.0 or earlier. Networks with this configuration are referred to as mixed-mode. NTLM is also the authentication protocol for computers that are not participating in a domain, such as stand-alone servers and workgroups.

In Windows 7 and Windows Server 2008 R2, you can restrict the usage of NTLM. For more information see, Introducing the Restriction of NTLM Authentication (https://technet.microsoft.com/en-us/library/dd560653(WS.10).aspx)

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 or later operating system versions. 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 has an operating system that is Windows 2000 or later.
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 Interfaces (ADSI)
LDAP C API
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 provider-based 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.

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 a Windows 2000 or later operating system, the logon request is processed in three stages:

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 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 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, Windows Server 2003, Windows Server 2008, and Window Server R2, process referrals for authentication to a domain differently, as do other authentication protocols, such as Digest and SChannel, that Windows 2000 Server, Windows Server 2003, Windows Server 2008, and Window Server R2 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 2000 or later, 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 or later, 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 local group membership is changed to add members of the Domain Admins group to the Local Accounts Administrators group.
The Net Logon trusted domain cache is initialized to the trusted domains domain list.
For clients running Windows 2000 or later, the Windows Time Service is enabled and started.
The Net Logon service is 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 2000 Server, Windows Server 2003, Windows Server 2008 and Window Server 2008 R@:

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 later versions of Microsoft Server operating systems–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 and later versions of Microsoft Server operating systems –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, 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 domain- and forest-wide Active Directory features available when all domain controllers in a domain or forest are running Windows Server 2003. This also holds true for Windows Server 2008 and Windows Server 2008 R2.

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. The same is true for Windows Server 2008 and Windows Server 2008 R2.

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 Windows Server 2008 and Windows Server 2008 R2 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.”

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	Inbound Ports	From–To
Set up trusts on both sides from the internal forest	LDAP (389 UDP and TCP) Microsoft SMB (445 TCP) Kerberos (88 UDP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port	N/A	Internal domain domain controllers–External domain domain controllers (all ports)
Trust validation from the internal forest domain controller to the external forest domain controller (outgoing trust only)	LDAP (389 UDP) Microsoft SMB (445 TCP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port	N/A	Internal domain domain controllers–External domain domain controllers (all ports)
Use Object picker on the external forest to add objects that are in an internal forest to groups and DACLs	N/A	LDAP (389 UDP and TCP) Windows NT Server 4.0 directory service fixed port Net Logon fixed port Kerberos (88 UDP) Endpoint resolution portmapper (135 TCP)	External server–Internal domain PDCs (Kerberos) External domain domain controllers–Internal domain domain controllers (Net Logon)
Set up trust on the external forest from the external forest	N/A	LDAP (389 UDP and TCP) Microsoft SMB (445 TCP) Kerberos (88 UDP)	External domain domain controllers–Internal domain domain controllers (all ports)
Use Kerberos authentication (internal forest client to external forest)	Kerberos (88 UDP)	N/A	Internal client–External domain domain controllers (all ports)
Use NTLM authentication (internal forest client to external forest)	N/A	Endpoint resolution – portmapper (135 TCP) Net Logon fixed port	External domain domain controllers–Internal domain domain controllers (all ports)
Join a domain from a computer in the internal network to an external domain	LDAP (389 UDP and TCP) 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	N/A	Internal client–External domain domain controllers (all ports)

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

Freigeben über

How Domains and Forests Work