Chapter 4. Active Directory Architecture: The Fundamentals
Active Directory is an extensible directory service that enables you to manage network resources efficiently. A directory service does this by storing detailed information about each network resource, which makes it easier to provide basic lookup and authentication. Being able to store large amounts of information is a key objective of a directory service, but the information must also be organized so that it’s easily searched and retrieved.
Active Directory enables authenticated search and retrieval of information by dividing the physical and logical structures of the directory into separate layers. Understanding the physical structure of Active Directory is important for understanding how a directory service works. Understanding the logical structure of Active Directory is important for implementing and managing a directory service.
The physical layer of Active Directory controls the following features:
From a physical or machine perspective, Active Directory is part of the security subsystem. The security subsystem runs in user mode. User-mode applications do not have direct access to the operating system or hardware. This means that requests from user-mode applications have to pass through the executive services layer and must be validated before being executed.
NOTE Being part of the security subsystem makes Active Directory an integrated part of the access-control and authentication mechanism built into Microsoft Windows Server. Access control and authentication protect the resources in the directory.
Each resource in Active Directory is represented as an object. Anyone who tries to gain access to an object must be granted permission. Lists of permissions that describe who or what can access an object are referred to as access control lists (ACLs). Each object in the directory has an associated ACL.
You can restrict permissions across a broader scope by using Group Policy. The security infrastructure of Active Directory uses policy to enforce security models on several objects that are grouped logically. You can also set up trust relationships between groups of objects to allow for an even broader scope for security controls between trusted groups of objects that need to interact. From a top-level perspective, that’s how Active Directory works, but to really understand Active Directory, you need to delve into the security subsystem.
Within the security subsystem, Active Directory is a subcomponent of the Local Security Authority (LSA) . The LSA consists of many components that provide the security features of Windows Server and ensure that access control and authentication function as they should. Not only does the LSA manage local security policy, but it also performs the following functions:
When you work through the security subsystem as it is used with Active Directory, you’ll find the three following key areas:
Authentication mechanisms
NTLM (Msv1_0.dll) Used for Windows NT LAN Manager (NTLM) authentication
Kerberos (Kerberos.dll) and Key Distribution Center (Kdcsvc.dll) Used for Kerberos V5 authentication
SSL (Schannel.dll) Used for Secure Sockets Layer (SSL) authentication
Authentication provider (Secur32.dll) Used to manage authentication
Logon/access-control mechanisms
NET LOGON (Netlogon.dll) Used for interactive logon through NTLM. For NTLM authentication, NET LOGON passes logon credentials to the directory service module and returns the SIDs for objects to clients making requests.
LSA Server (Lsasrv.dll) Used to enforce security policies for Kerberos and SSL. For Kerberos and SSL authentication, LSA Server passes logon credentials to the directory service module and returns the SIDs for objects to clients making requests.
Security Accounts Manager (Samsrv.dll) Used to enforce security policies for NTLM.
As you can see, users are authenticated before they can work with the directory service component. Authentication is handled by passing a user’s security credentials to a domain controller. After the user is authenticated on the network, the user can work with resources and perform actions according to the permissions and rights the user has been granted in the directory. At least, this is how the Windows Server security subsystem works with Active Directory.
When you are on a network that doesn’t use Active Directory, or when you log on locally to a machine other than a domain controller, the security subsystem works as shown in the next figure. Here, the directory service is not used. Instead, authentication and access control are handled through the Security Accounts Manager (SAM). Here, information about resources is stored in the SAM, which itself is stored in the registry.
As you’ve seen, incoming requests are passed through the security subsystem to the directory service component. The directory service component is designed to accept requests from many kinds of clients, each of which use specific protocols to interact with Active Directory.
The primary protocol for Active Directory access is Lightweight Directory Access Protocol (LDAP). LDAP is an industry-standard protocol for directory access that runs over Transmission Control Protocol/Internet Protocol (TCP/IP). Active Directory supports LDAP versions 2 and 3. Clients can use LDAP to query and manage directory information, depending on the level of permissions they have been granted, by establishing a TCP connection to a domain controller. The default TCP port used by LDAP clients is 389 for standard communications and 636 for SSL.
Active Directory supports intersite and intrasite replication through the REPL interface, which uses either remote procedure calls (RPCs) or Simple Mail Transfer Protocol over Internet Protocol (SMTP over IP), depending on how replication is configured. Each domain controller is responsible for replicating changes to the directory to other domain controllers, using a multimaster approach. The multimaster approach used in Active Directory allows updates to be made to the directory by any domain controller and then replicated to other domain controllers.
For older messaging clients, Active Directory supports the Messaging Application Programming Interface (MAPI). MAPI allows messaging clients to access Active Directory (which Microsoft Exchange uses for storing information), primarily for address book lookups. Messaging clients use RPCs to establish a connection with the directory service. The RPC Endpoint Mapper uses UDP port 135 and TCP port 135. Current messaging clients use LDAP instead of RPC.
For legacy clients, Active Directory supports the SAM interface, which also uses RPCs. This allows legacy clients to access the Active Directory data store the same way they would access the SAM database. The SAM interface is also used during certain replication activities.
Clients and other servers use the LDAP, REPL, MAPI, and SAM interfaces to communicate with the directory service component (Ntdsa.dll) on a domain controller. From an abstract perspective, the directory service component consists of the following:
From a physical perspective, the DSA is really the directory-service component and the database layer resides within it. The reason for separating the two is that the database layer performs a vital abstraction. Without this abstraction, the physical database on the disk would not be protected from the applications the DSA interacts with. Furthermore, the object-based hierarchy used by Active Directory would not be possible. Why? Because the data store is in a single data file using a flat (record-based) structure, while the database layer is used to represent the flat file records as objects within a hierarchy of containers. Like a folder that can contain files as well as other folders, a container is simply a type of object that can contain other objects, as well as other containers.
Each object in the data store has a name relative to the container in which it’s stored. This name is aptly called the object’s relative distinguished name (RDN). An object’s full name, also referred to as an object’s distinguished name (DN), describes the series of containers, from the highest to the lowest, of which the object is a part.
To make sure every object stored in Active Directory is truly unique, each object also has a globally unique identifier (GUID), which is generated when the object is created. Unlike an object’s RDN or DN, which can be changed by renaming an object or moving it to another container, the GUID can never be changed. The DSA assigns it to an object, and it never changes.
The DSA is responsible for ensuring that the type of information associated with an object adheres to a specific set of rules. This set of rules is referred to as the schema. The schema is stored in the directory and contains the definitions of all object classes and describes their attributes. In Active Directory the schema is the set of rules that determine the kind of data that can be stored in the database, the type of information that can be associated with a particular object, the naming conventions for objects, and so on.
IMPORTANT The schema serves to separate an object’s definition from its actual values. Thanks to the schema, Active Directory doesn’t have to write information about all of an object’s possible attributes when it creates the object. When you create an object, only the defined attributes are stored in the object’s record. This saves a lot of space in the database. Furthermore, because the schema not only specifies the valid attributes but also the valid values for those attributes, Active Directory uses the schema both to validate the attributes that have been set on an object and to keep track of what other possible attributes are available.
The DSA is also responsible for enforcing security limitations. It does this by reading the SIDs on a client’s access token and comparing them to the SIDs for an object. If a client has appropriate access permissions, it is granted access to an object. If a client doesn’t have appropriate access permissions, it’s denied access.
Finally, the DSA is used to initiate replication. Replication is the essential functionality that ensures that the information stored on domain controllers is accurate and consistent with changes that have been made. Without proper replication, the data on servers would become stale and outdated.
Active Directory uses the Extensible Storage Engine (ESE) to retrieve information from, and write information to, the data store. The ESE uses indexed and sequential storage with transactional processing, as follows:
Any data that is modified in a transaction is copied to a temporary database file. This gives two views of the data that’s being changed: one view for the process changing the data and one view of the original data that’s available to other processes until the transaction is finalized. A transaction remains open as long as changes are being processed. If an error occurs during processing, the transaction can be rolled back to return the object being modified to its original state. If Active Directory finishes processing changes without errors occurring, the transaction can be committed.
As with most databases that use transactional processing, Active Directory maintains a transaction log. A record of the transaction is written first to an in-memory copy of an object, then to the transaction log, and finally to the database. The in-memory copy of an object is stored in the version store. The version store is an area of physical memory (RAM) used for processing changes. Typically, the version store is 25 percent of the physical RAM.
The transaction log serves as a record of all changes that have yet to be committed to the database file. The transaction is written first to the transaction log to ensure that even if the database shuts down immediately afterward, the change is not lost and can take effect. To ensure this, Active Directory uses a checkpoint file to track the point up to which transactions in the log file have been committed to the database file. After a transaction is committed to the database file, it can be cleared out of the transaction log.
The actual update of the database is written from the in-memory copy of the object in the version store and not from the transaction log. This reduces the number of disk I/O operations and helps ensure that updates can keep pace with changes. When many updates are made, however, the version store can reach a point where it’s overwhelmed. This happens when the version store reaches 90 percent of its maximum size. When this happens, the ESE temporarily stops processing cleanup operations that are used to return space after an object is modified or deleted from the database.
Although index creation could affect domain controller performance in earlier releases of Windows Server, Windows Server 2012 and later allow you to defer index creation to a time when it’s more convenient. By deferring index creation to a designated point in time, rather than creating indexes as needed, you can ensure that domain controllers can perform related tasks during off-peak hours, thereby reducing the impact of index creation. Any attribute that is in a deferred index state will be logged in the Event log every 24 hours. Look for event IDs 2944 and 2945. When indexes are created, event ID 1137 is logged.
In large Active Directory environments, deferring index creation is useful to prevent domain controllers from becoming unavailable due to building indexes after schema updates. Before you can use deferred index creation, you must enable the feature in the forest root domain. You do this using the DSHeuristics attribute of the Directory Services object for the domain. Set the 18th bit of this attribute to 1. Because the 10th bit of this attribute typically also is set to 1 (if the attribute is set to a value), the attribute normally is set to the following: 000000000100000001. You can modify the DSHeuristics attribute using ADSI Edit or Ldp.exe.
96. You can modify the DSHeuristics attribute by completing the following steps: Open ADSI Edit by selecting the related option on the Tools menu in Server Manager.
97. Right-click the root node in the left pane and then select Connect To. In the Connection Settings dialog box, choose the Select A Well Known Naming Context option. On the related selection list, select Configuration (because you want to connect to the Configuration naming context for the domain) and then click OK.
98. In ADSI Edit, work your way down to the CN=Directory Service container by expanding the Configuration naming context, the CN=Configuration container, the CN=Services container, and the CN=Windows NT container.
99. Next, right-click CN=Directory Service and then select Properties. In the Properties dialog box, select the dsHeuristics property and then click Edit.
100. In the String Attribute Editor dialog box, type the desired value, such as 000000000100000001, and then click OK twice.
NOTE The value 000000000100000001 is nine zeros with a 1 in the 10th position followed by seven zeros with a 1 in the 18th position.
Once the change is replicated to all domain controllers in the forest, they will defer index creation automatically. You must then trigger index creation manually by either restarting domain controllers, which rebuilds the schema cache and deferred indexes, or by triggering a schema update for the RootDSE.
In ADSI Edit, you can initiate an update by connecting to the RootDSE. To do this, right-click the root node and then select Connect To. In the Connection Settings dialog box, choose the Select A Well Known Naming Context option. On the related selection list, select RootDSE and then click OK. In ADSI Edit, right-click the RootDSE node and then select Update Schema Now.
To allow for object recovery and for the replication of object deletions, an object that is deleted from the database is logically removed rather than physically deleted. The way deletion works depends on whether Active Directory Recycle Bin is enabled or disabled.
When Active Directory Recycle Bin is disabled, as with standard deployments prior to Windows Server 2008 R2, most of the object’s attributes are removed and the object’s Deleted attribute is set to TRUE to indicate that it has been deleted. The object is then moved to a hidden Deleted Objects container where its deletion can be replicated to other domain controllers. In this state, the object is said to be tombstoned. To allow the tombstoned state to be replicated to all domain controllers, and thus removed from all copies of the database, an attribute called tombstoneLifetime is also set on the object. The tombstoneLifetime attribute specifies how long the tombstoned object should remain in the Deleted Objects container. The default lifetime is 180 days.
IMPORTANT When an object is tombstoned, Active Directory changes the distinguished name so that the object name can’t be recognized. Next, Active Directory deletes all of the object’s link-valued attributes and most of the object’s non-link-valued attributes are cleared. Finally, the object is moved to the Deleted Objects container.
You can recover tombstoned objects using tombstone reanimation. However, attribute values that were removed are not recovered. This means the link-valued attributes, which include group memberships of user accounts, and the non-link-valued attributes are not recovered.
The ESE uses a garbage-collection process to clear out tombstoned objects after the tombstone lifetime has expired, and it performs automatic online defragmentation of the database after garbage collection. The interval at which garbage collection occurs is a factor of the value set for the garbageCollPeriod attribute and the tombstone lifetime. By default, garbage collection occurs every 12 hours. When there are more than 5000 tombstoned objects to be garbage-collected, the ESE removes the first 5000 tombstoned objects and then uses the CPU availability to determine if garbage collection can continue. If no other process is waiting for the CPU, garbage collection continues for up to the next 5000 tombstoned objects whose tombstone lifetime has expired, and the CPU availability is again checked to determine if garbage collection can continue. This process continues until all the tombstoned objects whose tombstone lifetime has expired are deleted or another process needs access to the CPU.
When Active Directory Recycle Bin is enabled as an option with Windows Server 2008 R2 and later, objects aren’t tombstoned when they are initially deleted, nor are their attributes removed. Instead, the deletion process occurs in stages.
In the first stage of the deletion, the object is said to be logically deleted. Here, the object’s Deleted attribute is set to TRUE to indicate that it has been deleted. The object is then moved, with its attributes and name preserved, to a hidden Deleted Objects container where its deletion can be replicated to other domain controllers. To allow the logically deleted state to be replicated to all domain controllers, and thus removed from all copies of the database, an attribute called ms-DeletedObjectLifetime is also set on the object. The ms-DeletedObjectLifetime attribute specifies how long the logically deleted object should remain in the Deleted Objects container. The default deleted object lifetime is 180 days.
When the deleted object lifetime expires, Active Directory removes most of the object’s attributes, changes the distinguished name so that the object name can’t be recognized, and sets the object’s tombstoneLifetime attribute. This effectively tombstones the object (and the process is the same as the legacy tombstone process).
The recycled object remains in the Deleted Objects container until the recycled object lifetime expires, and it’s said to be in the recycled state. The default tombstone lifetime is 180 days.
As with deletion without the Recycle Bin, the ESE uses a garbage-collection process to clear out tombstoned objects after the tombstone lifetime has expired. This garbage-collection process is the same as discussed previously.
After you examine the operating-system components that support Active Directory, the next step is to see how directory data is stored on a domain controller’s hard disks. The data store has a primary data file and several other types of related files, including working files and transaction logs.
These files are used as follows:
The primary data file contains three indexed tables:
Think of the data table as having rows and columns; the intersection of a row and a column is a field. The table’s rows correspond to individual instances of an object. The table’s columns correspond to attributes defined in the schema. The table’s fields are populated only if an attribute contains a value. Fields can be a fixed or a variable length. If you create an object and define only 10 attributes, only these 10 attributes will contain values. Although some of those values might be fixed length, others might be variable length.
Records in the data table are stored in data pages that have a fixed size of 8 kilobytes (KBs, or 8192 bytes). Each data page has a page header, data rows, and free space that can contain row offsets. The page header uses the first 96 bytes of each page, leaving 8096 bytes for data and row offsets.
Row offsets indicate the logical order of rows on a page, which means that offset 0 refers to the first row in the index, offset 1 refers to the second row, and so on. If a row contains long, variable-length data, the data might not be stored with the rest of the data for that row. Instead, Active Directory can store an 8-byte pointer to the actual data, which is stored in a collection of 8-KB pages that aren’t necessarily written contiguously. In this way, an object and all its attribute values can be much larger than 8 KBs.
The primary log file has a fixed size of 10 megabytes (MBs). When this log fills up, Active Directory creates additional (secondary) log files as necessary. The secondary log files are also limited to a fixed size of 10 MBs. Active Directory uses the reserve log files to reserve space on disk for log files that might need to be created. Because several reserve files are already created, this speeds up the transactional logging process when additional logs are needed.
By default, the primary data file, the working files, and the transaction logs are all stored in the same location. On a domain controller’s system volume, you’ll find these files in the %SystemRoot%\NTDS folder. Although these are the only files used for the data store, Active Directory uses other files. For example, policy files and other files, such as startup and shutdown scripts used by the DSA, are stored in the %SystemRoot%\Sysvol folder.
NOTE A distribution copy of Ntds.dit is also placed in the %SystemRoot%\System32 folder. This is used to create a domain controller when you install Active Directory on a server running Windows Server. If the file doesn’t exist, the Active Directory Installation Wizard will need the installation media to promote a member server to be a domain controller.
TIP When you stop Active Directory Domain Services, you can use the Extensible Storage Engine Utility (esentutl.exe) to examine log file properties. At an administrator command prompt, type esentutl.exe –ml LogName, where LogName is the name of the log file to examine, such as edb.log, to obtain detailed information on the log file, including the base name, creation time, format version, log sector sizes, and logging parameters. While Active Directory Domain Services is offline, you can also use esentutl.exe to perform defragmentation and integrity checks, as well as copy, repair, and recovery operations. To learn more about this utility, type esentutl.exe at an administrator command prompt. Following the prompts, you can then type the letter corresponding to the operation you want to learn more about. For example, type esentutl.exe and then press the D key to learn the defragmentation options.
The logical layer of Active Directory determines how you see the information contained in the data store and also controls access to that information. The logical layer does this by defining the namespaces and naming schemes used to access resources stored in the directory. This provides a consistent way to access directory-stored information regardless of type. For example, you can obtain information about a printer resource stored in the directory in much the same way that you can obtain information about a user resource.
To better understand the logical architecture of Active Directory, you need to understand the following topics:
Because so many types of resources can be stored in the directory, a standard storage mechanism was needed and Microsoft developers decided to use the LDAP model for organizing data. In this model, each resource that you want to represent in the directory is created as an object with attributes that define information you want to store about the resource. For example, the user object in Active Directory has attributes for a user’s first name, middle initial, last name, and logon name.
An object that holds other objects is referred to as a container object or simply a container. The data store itself is a container that contains other containers and objects. An object that can’t contain other objects is a leaf object. Each object created within the directory is of a particular type or class. The object classes are defined in the schema. Some of the object types include:
When you create an object in the directory, you must comply with the schema rules for that object class. Not only do the schema rules dictate the available attributes for an object class, they also dictate which attributes are mandatory and which attributes are optional. When you create an object, mandatory attributes must be defined. For example, you can’t create a user object without specifying the user’s full name and logon name. The reason is that these attributes are mandatory.
Some rules for attributes are defined in policy as well. For example, the default security policy for Windows Server specifies that a user account must have a password and that the password must meet certain complexity requirements. If you try to create a user account without a password or with a password that doesn’t meet these complexity requirements, the account creation will fail because of the security policy.
The schema can be extended or changed as well. This allows administrators to define new object classes, add attributes to existing objects, and change the way attributes are used. However, you need special access permissions and privileges to work directly with the schema. Specifically, you must be a member of the Schema Admins group.
Within the directory, objects are organized using a hierarchical tree structure called a directory tree. The structure of the hierarchy is derived from the schema and is used to define the parent–child relationships of objects stored in the directory.
A logical grouping of objects that allows central management of those objects is called a domain. In the directory tree, a domain is itself represented as an object. In fact, it’s the parent object of all the objects it contains. An Active Directory domain can contain millions of objects. You can create a single domain that contains all the resources you want to manage centrally. In the figure that follows, a domain object is represented by a large triangle and the objects it contains are as shown.
Domains are only one of several building blocks for implementing Active Directory structures. Other building blocks include the following:
As described, a directory tree is used to represent a hierarchy of objects, showing the parent–child relationships between those objects. Thus, when we’re talking about a domain tree, we’re looking at the relationship between parent and child domains. The domain at the top of the domain tree is referred to as the root domain (think of this as an upside-down tree). More specifically, the root domain is the first domain created in a new tree within Active Directory. When talking about forests and domains, there is an important distinction made between the first domain created in a new forest—a forest root domain—and the first domain created in each additional tree within a forest—a root domain.
In the example shown next, tvpress.com is the root domain in an Active Directory forest with a single tree—that is, it’s the forest root domain. As such, tvpress.com is the parent of the sales.tvpress.com domain and the tech.tvpress.com domain. The tech.tvpress.com domain itself has a related subdomain: it.tech.tvpress.com. This makes tech.tvpress.com the parent of the child domain it.tech.tvpress.com.
The most important thing to note about this and all domain trees is that the namespace is contiguous. Here, all the domains are part of the tvpress.com namespace. If a domain is a part of a different namespace, it can be added as part of a new tree in the forest. In the next example, a second tree is added to the forest. The root domain of the second tree is imaginedlands.com, and this domain has cs.imaginedlands.com as a child domain.
You create a forest root domain by installing Active Directory on a stand-alone server and establishing the server as the first domain controller in a new forest. To add a tree to an existing forest, you install Active Directory on a stand-alone server and configure the server as a member of the forest, but with a domain name that is not part of the current namespace being used. You make the new domain part of the same forest to allow associations called trusts to be made between domains that belong to different namespaces.
In Active Directory, two-way transitive trusts are established automatically between domains that are members of the same forest. Trusts join parent and child domains in the same domain tree and join the roots of domain trees. Trusts are transitive, which means that if domain A trusts domain B and domain B trusts domain C, domain A trusts domain C as well. Because all trusts in Active Directory are two-way and transitive, by default every domain in a forest implicitly trusts every other domain. It also means that resources in any domain are available to users in every domain in the forest. For example, with the trust relationships in place, a user in the sales.tvpress.com domain could access a printer or other resources in the tvpress.com domain—or even the cs.imaginedlands.com domain.
However, the creation of a trust doesn’t imply any specific permission. Instead, it implies only the ability to grant permissions. No privileges are automatically implied or inherited by the establishment of a trust relationship. The trust doesn’t grant or deny any permission. It exists only to allow administrators to be able to grant permissions.
Several key terms are used to describe trusts, including the following:
To make it easier for administrators to grant access throughout a forest, Active Directory allows you to designate two types of administrators:
Going back to the example, Tom, an enterprise administrator in this forest, could grant access to resources in any domain in the forest. If Jim, in the sales.tvpress.com domain, needed access to a printer in the us.imaginedlands.com domain, Tom could grant this access. Because in this example us.imaginedlands.com is the trusting domain and sales.tvpress.com is the trusted domain, Sarah, a domain administrator in the us.imaginedlands.com domain, could grant permission to use the printer as well. Bob, a domain administrator for sales.tvpress.com, could not grant such permissions, however, because the printer resource exists in a domain other than the one he controls.
In the trust relationship example, take a look at the arrows that designate the trust relationships. For a user in the sales.tvpress.com domain to access a printer in the us.imaginedlands.com domain, the request must pass through the following series of trust relationships:
101. The trust between sales.tvpress.com and tvpress.com
102. The trust between tvpress.com and imaginedlands.com
103. The trust between imaginedlands.com and us.imaginedlands.com
The trust path defines the path that an authentication request must take between the two domains. Here, a domain controller in the user’s local domain (sales.tvpress.com) would pass the request to a domain controller in the tvpress.com domain. This domain controller, in turn, would pass the request to a domain controller in the imaginedlands.com domain. Finally, the request would be passed to a domain controller in the us.imaginedlands.com domain, which would ultimately grant or deny access.
In all, the user’s request has to pass through four domain controllers—one for each domain between the user and the resource. Because the domain structure is separate from the network’s physical structure, the printer could actually be located right beside the user’s desk and the user’s request would still have to go through this process. If you expand this scenario to include all the users in the sales.tvpress.com domain, you could potentially have hundreds of users whose requests have to go through a similar process to access resources in the us.imaginedlands.com domain.
Omitting the fact that the domain design in this scenario is very poor—because if many users are working with resources, those resources are ideally in their own domain or in a domain closer in the tree—one solution for this problem would be to establish a shortcut trust between the user’s domain and the resource’s domain. With a shortcut trust, you could specify that us.imaginedlands.com explicitly trusts sales.tvpress.com. Now when a user in the sales.tvpress.com requests a resource in the us.imaginedlands.com domain, the local domain controller knows about cs.imaginedlands.com and can directly submit the request for authentication. This means that the sales.tvpress.com domain controller sends the request directly to a us.imaginedlands.com domain controller.
Shortcut trusts are designed to help make more efficient use of resources on a busy network. On a network with a lot of activity, the explicit trust can reduce the overhead on servers and on the network as a whole. You shouldn’t implement shortcut trusts without careful planning. You should use them only when resources in one domain will be regularly accessed by users in another domain. They don’t need to be used between two domains that have a parent–child relationship because a default trust already exists explicitly between a parent domain and a child domain.
With Active Directory, you can also make use of external trusts. External trusts are manually configured and are always nontransitive. External trusts can be either one-way or two-way. When you establish a trust between a domain in one forest and a domain in another forest, security principals from the external domain can access resources in the internal domain. In the internal domain, Active Directory creates a foreign security principal to represent each security principal in the external domain. Foreign security principals can be added to domain local groups in the internal domain.
Any data stored in the Active Directory database is represented logically as an object. Every object in the directory has a relative distinguished name (RDN). That is, every object has a name relative to the parent container in which it’s stored. The relative name is the name of the object itself, and it’s also referred to as an object’s common name (CN) . This relative name is stored as an attribute of the object and must be unique for the container in which it’s located. Following this, no two objects in a container can have the same common name, but two objects in different containers could have the same name.
In addition to an RDN, objects also have a distinguished name (DN) . An object’s DN describes the object’s place in the directory tree and is logically the series of containers from the highest to the lowest of which the object is a part. It’s called a distinguished name because it serves to distinguish like-named objects and, as such, must be unique in the directory. No two objects in the directory will have the same distinguished name.
Every object in the directory has a parent, except the root of the directory tree, which is referred to as the rootDSE. The rootDSE represents the top of the logical namespace for a directory. It has no name per se. Although there is only one rootDSE, the information stored in the rootDSE specifically relates to the domain controller on which the directory is stored. In a domain with multiple domain controllers, the rootDSE will have a slightly different representation on each domain controller. The representation relates to the capability and configuration of the domain controller in question. In this way, Active Directory clients can determine the capabilities and configuration of a particular domain controller.
Below the rootDSE, every directory tree has a root domain. The root domain is the first domain created in an Active Directory forest and is also referred to as the forest root domain. After it’s established, the forest root domain never changes, even if you add new trees to the forest. The LDAP distinguished name of the forest root domain is DC=ForestRootDomainName, where DC is an LDAP identifier for a domain component and ForestRootDomainName is the actual name of the forest root domain. Each level within the domain tree is broken out as a separate domain component. For example, if the forest root domain is tvpress.com, the domain’s distinguished name is DC=tvpress,DC=com.
When Active Directory is installed on the first domain controller in a new forest, three containers are created below the rootDSE:
From a logical perspective, these containers are organized as shown in the next figure. The LDAP identifier for an object’s common name is CN. The DN for the Configuration container is CN=configuration,DC=ForestRootDomainName, and the DN for the Schema container is CN=schema, CN=configuration, DC=ForestRootDomainName. In the tvpress.com domain, the DNs for the Configuration and Schema containers are CN=configuration, DC=tvpress,DC=com and CN=schema, CN=configuration, DC=tvpress,DC=com, respectively. As you can see, the distinguished name allows you to walk the directory tree from the relative name of the object you are working with to the forest root.
As shown in the figure, the Forest Root Domain and the Configuration and Schema containers exist within their own individual partitions. Active Directory uses partitions to logically apportion the directory so that each domain controller does not have to store a complete copy of the entire directory. To do this, object names are used to group objects into logical categories so that the objects can be managed and replicated as appropriate. The largest logical category is a directory partition. All directory partitions are created as instances of the domainDNS object class.
As far as Active Directory is concerned, a domain is a container of objects that is logically partitioned from other container objects. When you create a new domain in Active Directory, you create a new container object in the directory tree, and that container, in turn, is contained by a domain directory partition for the purposes of management and replication.
Active Directory uses partitions to help distribute three general types of data:
Every domain controller stores at least one domain directory partition, as well as two forestwide data partitions: the schema partition and the configuration partition. Data in a domain directory partition is replicated to every domain controller in the domain as a writeable replica.
Forestwide data partitions are replicated to every domain controller in the forest. The configuration partition is replicated as a writeable replica. The schema partition is replicated as a read-only replica, and the only writeable replica is stored on a domain controller that is designated as having the schema operations master role. Other operations master roles are defined as well.
Active Directory can replicate application-specific data that is stored in an application partition, such as the default application partitions used with zones in Domain Name System (DNS) that are integrated with Active Directory. Application partition data is replicated on a forestwide, domainwide, or other basis to domain controllers that have a particular application partition. If a domain controller doesn’t have an application partition, it doesn’t receive a replica of the application partition.
In addition to full replicas that are distributed for domains, Active Directory distributes partial replicas of every domain in the forest to special domain controllers designated as global catalog servers. The partial replicas stored on global catalog servers contain information on every object in the forest and are used to facilitate searches and queries for objects in the forest. Because only a subset of an object’s attributes is stored, the amount of data replicated to and maintained by a global catalog server is significantly smaller than the total size of all object data stored in all the domains in the forest.
Every domain must have at least one global catalog server. By default, the first domain controller installed in a domain is set as that domain’s global catalog server. You can change the global catalog server, and you can designate additional servers as global catalog servers as necessary.