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.
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 :
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 :
Source : Microsoft TechNet
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 :
Source : AD DS: Read-Only Domain Controllers
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 :
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.
An Active Directory environment is made up of several things that are contained within each other.
To begin, an Active Directory domain contains a series of objects, such as :
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.
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.
As you might have guessed, an Active Directory forest is a collection of Active Directory trees.
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)
When you create an Active Directory domain controller, its configuration is stored in different partitions :
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 :
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.
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.
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.
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.
The domain controller with the "Domain naming master" role will be responsible for adding and removing domains and partitions in the Active Directory forest.
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 :
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 :
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.
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 :
The trust relationships that provide access to resources can be one-way and two-way.
As their names suggest :
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.
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.
Trust relationships between 2 domains can be transitive and non-transitive.
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.
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 :
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.
To be able to create forest trusts, your DNS infrastructure must correspond to one of these situations :
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.
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)
Windows Server 4/16/2021
Windows Server 4/30/2021
Windows Server 5/21/2021
Windows Server 6/4/2021
® InformatiWeb-Pro.net - InformatiWeb.net 2008-2022 - © Lionel Eppe - All rights reserved.
Total or partial reproduction of this site is prohibited and constitutes an infringement punishable by articles L.335-2 and following of the intellectual property Code.