Active Directory (AD) is a Microsoft proprietary directory service developed for Windows domain networks
It is included in most Windows Server operating systems, enabling network administrators to create and manage domains, users, objects, privileges, and access within a network. AD is a hierarchical, multi-master-enabled database that can store millions of things.
The AD layout follows a tiered structure made up of domains, trees, and forests. A domain is a group of objects (such as users or devices) sharing the same AD database. A tree is a collection of domains, and a forest is a collection of trees. Thus, any changes to the AD database can be processed at any given domain controller (DC) in the enterprise, irrespective of its network connection status (i.e., whether it is connected or disconnected from the network). Now, let’s examine the two standard models used for database update and replication in Active Directory: Multi-master and Single-master replication.
Understanding Multi-master and Single-master Model
A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise. The multi-master database model will allow data to be stored by multiple DCs, and updated by any. All members are responsible for client data queries, propagating each member’s data modifications to the rest of the group, and resolving any conflicts between concurrent changes made by different members. However, there are times when conflicts become too difficult to determine. In such cases, it’s best to prevent the war from happening rather than attempt to resolve it after the fact.
The Active Directory performs updates to particular objects using the single-master approach to prevent conflicting updates in Windows. This is referred to as the single-master model. In this model, one DC acts as the master (authoritative source) and controls one or more synchronized to it. Only one DC in the entire directory is allowed to process updates. Active Directory extends the single-master model to include multiple roles and transfer roles to any DC in the enterprise. Since Active Directory roles are not tied to a single DC, such a model offers a lot of flexibility. This is referred to as Flexible Single Master Operation (FSMO) Roles.
Understanding FSMO Role Assignment
FSMO is a specialized domain controller (DC) set of tasks used where standard data transfer and update methods are inadequate. FSMO plays an essential role in Microsoft Active Directory, which generally relies on multiple peer DCs. Each DC has a copy of the AD database and is synchronized by multi-master replication. The FSMO kicks in when other tasks are not suited to multi-master replication. These tasks are carried out using the single-master database replication approach.
Before discussing how to query FSMO roles in AD, let’s first examine each FSMO role and its relation to the Active Directory. For example, in Windows, there are five FSMO roles, which are described in detail below:
Schema master: The Schema master is a forest-specific FSMO role located in the forest root domain. The purpose of this role is to replicate schema changes to all other domain controllers in the forest. The schema master FSMO role holder is the DC responsible for performing updates to the directory schema. This DC is the only one that can process updates to the directory schema. Once the Schema update is complete, it’s replicated from the schema master to all other DCs in the directory. Thus, there’s only one schema master per directory. This role is typically involved in situations requiring changes to the Active Directory schema, such as the deployment of Skype for the business server and exchange server.
Domain naming master: This is another forest-specific FSMO role that also resides in the forest root domain. The domain naming master FSMO role holder is the DC responsible for making changes to the forest-wide domain name space of the directory. This DC is the only one that can add or remove a domain from the directory and add or remove cross-references to domains in external directories. Failure of this role to function correctly can prevent the addition of a new child domain or new domain tree.
RID master: The RID master is a domain-specific FSMO role. There’s one RID master per domain in a directory. The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible for moving an object from one domain to another during an interdomain object move. When a DC creates a principal security object such as a user or group, it attaches a unique SID to the object. This SID consists of:
- A domain SID that’s the same for all SIDs created in a domain.
- A relative ID (RID) that’s unique for each security principal SID created in a domain.
PDC emulator: The PDC emulator is another domain-specific FSMO role, and there is one PDC emulator for each domain in a forest. This role has the broadest range of functions and is the most used of all FSMO roles. The PDC emulator is the domain source for time synchronization for all other domain controllers. For example, in a Windows domain, the PDC emulator role holder retains the following functions:
- Password changes done by other DCs in the domain are replicated preferentially to the PDC emulator.
- When authentication failures occur at a given DC because of an incorrect password, the losses are forwarded to the PDC emulator before a wrong password failure message is reported to the user.
- Account lockout is processed on the PDC emulator.
In a multi-domain forest, the PDC emulator in each domain synchronizes to the forest root PDC emulator. All other domain member computers synchronize to their respective domain controllers.
Infrastructure master: This is another domain-specific FSMO role, and there is only one Infrastructure master for each domain in a forest. The infrastructure FSMO role holder is the DC responsible for updating an object’s SID and distinguished name in a cross-domain object reference. The purpose of this role is to ensure that cross-domain object references are properly handled. For example, if a user from one domain is added to a security group from a different domain, the Infrastructure Master ensures this is done correctly. However, if the AD deployment has only a single domain, the Infrastructure Master role does not work.
Those are the various FSMO roles in Active Directory as described above. It is best practice to have the FSMO parts divided so that standby DCs can be ready to take over each role. The PDC emulator and the RID master should be on the same DC, if possible. The Schema Master and Domain Naming Master should also be on the same DC. When an FSMO role is transferred to a different DC, the original FSMO holder and the new FSMO holder communicate to ensure no data is lost during the transfer. If the original FSMO holder experienced an unrecoverable failure, another DC could be made to take over (seize) the lost roles. This prevents the domain controller from hosting that FSMO role again, except for the PDC Emulator and Infrastructure Master Operation roles.
How to Query FSMO Roles
As a domain administrator, it’s essential to know where the roles are installed in your AD environment. This prepares you to respond better when a disaster occurs. In this article, we will show you two simple methods for querying FSMO roles. The first method uses the Netdom query tool, and the second uses Windows PowerShell.
Method 1— Netdom query FSMO command-line tool: Netdom is a command-line tool that allows management of Windows domains and trust relationships. The tool has been built into Windows Server OS since 2003 and later editions. It is available if you have the Active Directory Domain Services (AD DS) server role installed. We are going to use the Netdom tool to check the FSMO roles. The steps are as follows:
- Open and run the command prompt as admin on your domain controller.
- Enter the command: netdom query fsmo
- The output will show all of the FSMO roles and which domain controller holds them.
Method 2— PowerShell Get FSMO Roles: The PowerShell method for getting FSMO roles requires you to check the domain-wide and forest-wide roles separately. This involves two lines of commands, one to return the forest roles and another to produce the domain roles as shown below:
- Open and run PowerShell as admin on your domain controller
- Enter the command below to return the forest FSMO roles:
Get-ADForest domainname | Format-Table SchemaMaster,DomainNamingMaster
- For the other roles, open and run PowerShell as admin on your domain controller
- Enter the command below to return the domain FSMO roles:
Get-ADDomain yourdomain | format-table PDCEmulator, RIDMaster,InfrastructureMaster
This will return the rest of the FSMO roles and their holder as shown in the output screenshot below:
Conclusion
As you can see, FSMO roles prevent conflicts in an Active Directory and, at the same time, give you the flexibility to handle different operations within the Active Directory. As noted earlier, it’s essential that you know which domain controllers hold which roles in your environment, what these roles are, and the DC’s that hold them in case a disaster occurs or you have a specific reason to move them. If a catastrophe eventually occurs and you need to recover quickly, it is recommended that you only restore the FSMO role holder to prevent unnecessary issues.
L’article How to Query FSMO Roles in Active Directory est apparu en premier sur Comparitech.
0 Commentaires