•  
• AD functional levels

All companies working with servers in Microsoft environment use Active Directory Domain Services available on Windows Server.

But, what is an Active Directory ? This is what you will find out in this article.
Thanks to our article, you will have all the information you need to get started with these Active Directory Domain Services and know what domain controllers, forests, domains, Active Directory sites, ... mean and represent.

1. Domain controllers
   1. Domain Controller (DC)
   2. Read-Only Domain Controller (RODC)
   3. Global Catalog (GC)
2. Active Directory components
   1. Active Directory domain
   2. Active Directory domain tree
   3. Active Directory forest
   4. Active Directory schema
   5. Partitions
   6. Active Directory sites
3. FSMO roles (Operations master)
   1. FSMO roles uniques for the forest
      1. Schema master
      2. Domain naming master
   2. FSMO roles uniques for the domain
      1. RID master
      2. PDC emulator (Primary Domain Controller emulator)
      3. Infrastructure master
4. Trust relationships
   1. One-way and two-way trusts
      1. One-way trusts
      2. Two-way trusts
   2. Transitives and non transitives trusts
      1. Transitive trusts
      2. Non-transitive trusts
   3. Forest trusts
      1. How forest trusts work
      2. Conditions for creating forest trusts
   4. External trusts (domain trusts)

1. Domain controllers

To create an Active Directory environment on Windows Server, the first thing you will install is a domain controller.
Note that at least one domain controller is required per Active Directory domain (domain, subdomain, ...).

A domain controller can be installed in 3 ways :

1. as a domain controller (DC)
2. as a read-only domain controller (RODC)
3. as a global catalog server (GC)

1.1. Domain Controller (DC)

A domain controller is a server that contains a complete copy of the Active Directory configuration of the domain in which it's located, as well as the "SYSVOL" system folder.
Note that in the case of a DC, this copy can be used for reading and writing, unlike that of the RODC which is only accessible for reading.

For the SYSVOL folder, it contains, for example :

• all files related to group policies (also called GPOs for Group Policy Objects)
• any startup scripts, logon scripts, ... that you may have created and added to your group policies

Source : Microsoft TechNet

1.2. Read-Only Domain Controller (RODC)

A read-only domain controller (RODC) is the same as a domain controller (DC) except that this time it contains a read-only copy of the Active Directory configuration of the domain in which it's located.

The use of a read-only domain controller (RODC) allows, for example :

• to improve security : since the copy it contains is only available read-only, it cannot be modified.
• speed up session openings
• improve access to network resources

Source : AD DS: Read-Only Domain Controllers

1.3. Global Catalog (GC)

If the domain controller is configured as a global catalog, this domain controller contains a partial read-only copy of the attributes of all objects in the forest. What is also called "PAS" for Partial Attribute Set.

Global catalogs are useful for reducing access times to an Active Directory infrastructure.
However, this is only necessary if :

• an application requires the presence of a global catalog. This is particularly the case for Microsoft Exchange and Microsoft Message Queuing (MSMQ).
• you have more than 100 users to reduce the use of WAN bandwidth
• the logon is slow on your client workstations

Using a global catalog can speed up searches on the attributes of an object for a domain other than the forest where you are located. What is needed, for example, to speed up queries made by Microsoft Exchange.

Sources :

• Active Directory: Attributes in the Partial Attribute Set
• Planning Global Catalog Server Placement

2. Active Directory components

An Active Directory environment is made up of several things that are contained within each other.

2.1. Active Directory domain

To begin, an Active Directory domain contains a series of objects, such as :

• computer objects that identify a computer on the network that has joined your domain
• users
• groups
• organizational units or containers (which you can compare to folders at the moment)
• and more

This notion of domain makes it possible to create an administrative limit for the management of the various objects.
Indeed, by default, the administrator of an Active Directory domain (for example : corp.informatiweb.lan) doesn't have access to the management of other domains (for example : rh.informatiweb.lan).
However, you will see a little later that this is still possible if desired thanks to Active Directory delegations of control.

Note that at least 1 Active Directory domain controller is required per domain, as you can see in the diagram below.

2.2. Active Directory domain tree

A domain tree is a collection of domains that share a common namespace.
For example, "corp.informatiweb.lan" and "rh.informatiweb.lan" are part of the same domain tree and the common namespace is "informatiweb.lan".

Source : Microsoft support.

2.3. Active Directory forest

As you might have guessed, an Active Directory forest is a collection of Active Directory trees.

2.4. Active Directory schema

The Active Directory is a database in which you can create many objects (of computer, user, ... type).
To create these objects, the Active Directory is based on a system of classes and attributes that allows you to create these different types of objects and to define many properties on them.
For example : the name of a user, the group in which he is located, ...

Source : Active Directory Schema (AD Schema)

2.5. Partitions

When you create an Active Directory domain controller, its configuration is stored in different partitions :

• configuration : this partition contains all the configuration objects for the forest.
  Configuration objects contain information about Active Directory sites, directory services (domains, list of controllers, ...) and the partitions themselves.
  To view the contents of this "configuration" partition, you can use the ADSI Edit program available on Windows Server.
• schema : this partition contains the Active Directory schema (explained previously).
  To view its contents, you must use the "Active Directory Schema" mmc console. However, this console is not enabled by default.
• domain : this partition contains the computers, users, ... objects for the domain concerned by this domain controller.
  To view its contents, use the "Active Directory Users and Computers" console.

Thanks to this Active Directory partition system, you can benefit in particular from the Active Directory replication system for other services. Such as DNS which, once integrated, allows you to automatically replicate your DNS zones thanks to the "ForestDnsZones" and "DomainDnsZones" partitions which will be created there.

For the replication of these Active Directory partitions :

• changes made to the "configuration" and "schema" partitions are replicated to all domain controllers in the affected forest.
• changes made to the "domain" partition are replicated only to domain controllers in the same domain.
• for application partitions, you can don't replicate them or replicate them to different domains of the forest if you wish.

This means that the content of the "domain" partition is therefore different from one domain to another, unlike the content of the 2 other partitions which is identical (because replicated) on all the domain controllers in the same forest.

Finally, be aware that these partitions are all in the database stored in the form of a file named "NTDS.DIT" in the "C:\Windows\NTDS" folder of your Active Directory server.

Source :

• Directory Partitions
• Application Directory Partitions
• About Application Directory Partitions

2.6. Active Directory sites

Active Directory sites are used to manage data replication between different Active Directory domain controllers.
From the "Active Directory Sites and Services" console, you can manage the network and geographic location of your various domain controllers.

3. FSMO roles (Operations master)

When you implement multiple domain controllers in an Active Directory infrastructure, you must designate an operations master for the various existing FSMO (Flexible Single Master Operation) roles.

An Active Directory infrastructure is always based on 5 FSMO roles (although there is one which may become unnecessary in some cases).
Some of these FSMO roles are unique per forest, and others are unique per domain, and allow you to designate specific types of domain controllers.

Source : Planning Operations Master Role Placement

3.1. FSMO roles uniques for the forest

3.1.1. Schema master

The domain controller with the "Schema master" role will be the server dealing with changes and updates made to the Active Directory schema.
For this to be possible, the server must be part of the "Schema administrator" security group.

3.1.2. Domain naming master

The domain controller with the "Domain naming master" role will be responsible for adding and removing domains and partitions in the Active Directory forest.

3.2. FSMO roles uniques for the domain

3.2.1. RID master

The domain controller with the "RID master" role will be responsible for allocating (or assigning) RID (Relative ID) pools to each Active Directory object that needs a security ID (SID), such as computer, user, ... objects.
This RID master acts only on domain controllers in the domain in which it's located and thus ensures that every object and every domain controller in the current domain has an unique security identifier (SID).

These security IDs are structured with :

• a revision number
• the domain security identifier (also called "domain SID")
• a RID (which means : relative ID)

3.2.2. PDC emulator (Primary Domain Controller emulator)

For the "PDC Emulator" role, the domain controller with this role will be responsible for updating and replicating passwords.

To synchronize the clock of your different domain controllers and your different client PCs, Active Directory needs a trusted source to synchronize with.
In an Active Directory forest, if a domain controller has this PDC emulator role, it will be considered the best source of time (the most reliable source).
This synchronization of the clocks is very important for authentication (of users in particular), because each Kerberos packet is time stamped and if there is too much time difference, authentication can no longer work correctly.

The PDC emulator is also used to support NT4 clients and those lower than Windows 2000, as it can be configured to emulate a NT4 domain controller and thus support these old clients.

As you will understand, without this "PDC Emulator" role :

• clock synchronization may no longer work properly. This could cause authentication problems via Kerberos.
• users of client PCs under Windows NT4 or lower than Windows 2000 will no longer be able to connect
• and more

Sources :

• Domain Hierarchy-Based Synchronization
• Guide de découverte technique de la famille Microsoft Windows Server 2003 (PDF - page 29) (in French)

3.2.3. Infrastructure master

The domain controller designated as "infrastructure master" takes care of updating the references (also called "security principals") of objects between the different domains.
Thus, if a user of a domain "A" is added to a group of a domain "B", then we modify this user (on domain "A"), the domain controllers of domain B don't will never be aware of this change.

This is where the infrastructure master comes in handy, as it will check if any updates are needed and it will update the username on domain "B".
Then, this change will be replicated to the other domain controllers of the domain B.

Although, by default, domain controllers are not aware of this kind of change, but those configured as a "global catalog" are always aware of this kind of change. Indeed, in this case, the information is updated, whatever the domain to which it belongs.
This role is therefore not useful if all of your domain controllers are configured as a "global catalog".

The other exception to this rule is simply when you have only one domain in your Active Directory infrastructure.
Since you have only one Active Directory domain, this kind of problem does not happen.

Source : Requirements for infrastructure master placement

4. Trust relationships

The security of an Active Directory infrastructure is based on trust relationships that you can create between domains or forests.
However, before creating trust relationships between domains or forests, it's important to understand how they work and what they imply transparently.

By default, a secure channel is used to check security information, including security identifiers (SIDs) of users and groups.
This secure channel can be extended to other Active Directory domains by creating trust relationships between multiple domains or multiple forests.

These trust relationships can be :

• one-way or two-way
• transitive or non-transitive

Source : How trust relationships work for resource forests in Azure Active Directory Domain Services

4.1. One-way and two-way trusts

The trust relationships that provide access to resources can be one-way and two-way.

As their names suggest :

• one-way trust relationships are only valid in one direction
• two-way trust relationships are valid in both directions

4.1.1. One-way trusts

If you create a one-way trust relationship between domain A and domain B, users in domain A will be able to access resources in domain B.
However, those in domain B will not be able to access the resources of domain A.

Authentication can therefore also work from domain A to domain B, but not in the other direction.

In this case, we say that domain A trusts domain B. But on the other hand, domain B doesn't trust domain A.

4.1.2. Two-way trusts

If you create a two-way trust relationship between domain A and domain B, users in domain A will be able to access resources in domain B (and vice versa).

Authentication can therefore also work from domain A to domain B (and vice versa).

In this case, domain A trusts domain B. And domain B also trusts domain A.

In an Active Directory forest, domain trusts are all bidirectional and transitive.
Additionally, each child domain automatically trusts its parent when created.

4.2. Transitives and non transitives trusts

Trust relationships between 2 domains can be transitive and non-transitive.

4.2.1. Transitive trusts

In the case of a transitive trust, this indicates that the trust can be extended to other domains.
This is the default behavior used when you create a new child Active Directory domain.

In this case, the users of a child domain can access the resources of the parent domain, of the parent of the parent, ... as long as transitivity is enabled.

Example : if domain A trusts domain B, and domain B trusts domain C, then given that transitivity is enabled, users of domain A will be able to access resources in domain B, but also to those in domain C. It's the same for authentication requests, as they follow these trust paths.

4.2.2. Non-transitive trusts

In the case of a non-transitive trust, this indicates that the trust is only applied between the 2 desired domains.
Therefore, the user can't move up the trust path through the trust relationships that you have defined.

To continue with the previous example, if domain A trusts domain B, and domain B trusts domain C :

• users of domain A will be able to access resources in domain B
• users of domain B will be able to access resources of domain C
• but, users of domain A will NOT be able to access resources in domain C

4.3. Forest trusts

4.3.1. How forest trusts work

Unlike domain trusts, which allow you to create a trust relationship between domain A and domain B (or more by enabling transitivity), there are also forest trusts.
These forest trust relationships allow you to link 2 forests with a one-way or two-way relationship.

Forest trust relationships are interesting in some cases and especially when acquiring one or more companies, for example, which therefore use their own Active Directory forests and their own namespaces (company-a.lan and company-b.lan, for example).

However, unlike trust relationships between domains which can be transitive, this is not possible with forest trust relationships.
These can only be non-transitive.

This means that if you create a trust relationship between Forest A and Forest B, as well as between Forest B and Forest C, users in Forest A will not have access to Forest C.
If you want this to be possible, you will need to create an additional trust relationship between Forest A and Forest C.

Note that the creation of forest trust relationships can only be done between the root domain of each affected forest.

4.3.2. Conditions for creating forest trusts

To be able to create forest trusts, your DNS infrastructure must correspond to one of these situations :

• a single root DNS server contains the DNS zones of the 2 forests that you want to join with a forest trust relationship.
• a root DNS server uses conditional forwarders to redirect queries from each namespace to the primary DNS server containing it.
• a root DNS server uses secondary DNS zones so that queries are redirected to the primary DNS server affected by the desired namespace.

Then, to be authorized to create a trust relationship between 2 forests, you must be part of the "Domain admins" group (in the root domain of the forest concerned) or of the "Enterprise Admins" group in your Active Directory infrastructure.

4.4. External trusts (domain trusts)

In a large Active Directory infrastructure with several domains and several Active Directory forests, it may be interesting to create a trust relationship between 2 domains (rather than between 2 forests).

Domain trusts (or external trusts) first appeared with Windows NT Server and can be one-way or two-way.

Source : Approbations externes (in French)