Do new users created on one domain controller (DC) of an Active Directory (AD) environment, ever get erroneously deleted only after a few minutes by DCs of other sites within an AD forest?
Do changes made in a particular AD site ever get rewritten by DCs in other sites? Can AD objects be erroneously identified?
Can more than one AD user account, for example, with all its associated attributes, be a replica of another user account?
Do such conflicting scenarios ever come up in a well-functioning AD set up?
With the above questions in mind, let us dig deeper.
Part 6 of this blog series on Active Directory Domain Services (AD DS), is all about flexible single master operation (FSMO) roles. The FSMO model in AD enables you to avoid conflicting scenarios of the type we considered above.
FSMO roles are a set of services and processes, that are handled by DCs in a multi-model AD set up. These roles ensure the smooth functioning of all AD capabilities, including timely AD replication and consistent AD information across the entirety of the AD forest in any organization.
The history of FSMO roles
When Microsoft first introduced AD in the Windows 2000 edition and organizations began adopting AD services as their preferred directory service, the creation of multiple AD domains with domain controllers (DCs) in each domain resulted in a host of logistical challenges. This was before the FSMO model was adopted.
Multiple DCs attempted to authenticate and handle the same requests within each domain. Every DC in the defined AD site did not have a clear process in place to determine if it was to be chosen for the authentication and subsequent modification process. Because of this, conflicting situations arose, such as authentication errors, and erroneous replication.
These issues required a new solution, and Microsoft provided that.
The single-master model that was introduced ensured that one DC, or the master DC, was solely responsible for handling change requests in each domain, while the other DCs were responsible for authentications only. Although this new functionality helped better manage the change requests and conflicts, there were still scenarios where the continuous and seamless functioning of AD was affected. For example, when the master DC was down and unable to process any requests, delays resulted in the changes that had to be made to AD objects.
There was also the last writer wins concept that was designed to be a built-in conflict resolution mechanism in AD. This ensured that the changes made to AD data by the final DC that handles it, are considered valid. But the single-master model of preventing replication conflicts was hard to monitor. With all the AD data confined to one domain with no object grouping, and no transitive trust relationships defined for domains in the AD forest, the tracking of changes was difficult.
And, so…
The FSMO, which is a multi-master model, came into existence in 2003. And it is still being used today.
In this model, the roles held by any DC are transferable or distributed. If a DC that is responsible for processing a service and change request is offline or unreachable, and as a result the DC is unable to process it, the other DCs can step in to ensure continuity and timely execution of requests. This is the essence of the multi-model mechanism or the FSMO roles in AD.
A deep dive into FSMO now…
There are five FSMO roles that we need to know about. Some of the FSMO roles are applicable to the entire forest, while others are applicable to only the domain. (See Table 1).
|
FSMO roles that have forest wide applicability |
FSMO roles that have domain wide applicability |
|
Schema master |
Relative ID or RID Master |
|
Domain naming master |
Primary Domain Controller or PDC Emulator |
|
|
Infrastructure Master |
Table 1. FSMO roles and their scope of applicability
Schema master
➤ This role is assigned to only one DC throughout the entire AD forest.
➤ It handles and manages changes to be made to the AD schema data, or the schema partition, which is essentially the changes made to the definition of AD objects and their associated attributes.
➤ Once the changes have been made by this designated DC, AD replication ensures that all other DCs of the forest have this updated data.
Domain naming master
➤ When the configuration partition of AD is to be modified, the designated DC with the domain naming master role is contacted. This includes instances when additional domains have to be created or removed from within the AD forest.
➤ This role ensures that all domains created within the forest are uniquely identifiable. It accepts domain names with unique NetBIOS names, to guarantee that no naming conflicts arise in the domain namespace.
➤ This DC is also used when and if the application partition is to be modified, i.e., if a DNS server is to be added in the domains being created.
➤ This role is also used to connect with other external directory services apart from Microsoft’s AD services, if applicable.
Relative ID or RID Master
➤ This role is assigned to a single DC within each domain, and is responsible for allocating blocks of Security IDs or SIDs, to each DC. This, in turn, ensures the assigning of unique identifiers called relative IDs or RIDs, for each security principal object that is created in each domain.
➤ This DC role addresses the request made by other DCs in the domain, and assigns blocks of RIDs to the requesting DC. This pool of RIDs is the RID master’s response to the change requests it receives from other DCs.
➤ This role also manages the modification to AD data when AD objects are moved between domains.
PDC emulator
➤ Maintaining consistency across all connected resources is crucial for effective and timely AD replication. The DC with the PDC emulator role ensures this consistency.
➤ In addition, the DC with this role is the authoritative DC to process all account lockout instances to ensure built-in security for AD services and other password change requests in the case of non-verification at any individual DC.
➤ Group Policy management is also authorized by the PDC emulator DC.
Infrastructure Master
➤ This role assumes importance in multi-domain environments when objects in each domain are referenced by another domain.
➤ The Globally Unique Identifier or GUID, the Security Identifier or SID and Distinguished Names or DN, are updated and maintained by the DC with this role, to ensure that the cross-referencing between domains occurs seamlessly.
➤ This role works closely with the global catalog server to maintain updated information across the domain and helps in error-free name resolution when cross-referencing of AD objects between domains occurs.
Understanding the different roles that DCs can take on, helps to assimilate the concepts of AD operations.
Having an in-depth grasp on AD should help you examine and appreciate how security can, and should be achieved constantly in any AD infrastructure. It also helps to gain new insight into how security risks to the AD setup can be mitigated. In Part 7 of this blog series, we will examine how AD can be designed for security and also study the concepts of AD and cybersecurity at length.
