Vous êtes sur la page 1sur 4

FSMO Flexible Single Master Operation Roles

Active Directory (AD) has been the de facto standard for enterprise domain authentication services ever since
it first appeared in late 1999 (in Windows Server 2000). There have been several enhancements and updates
since then to make it the stable and secure authentication system in use today.

In its infancy, AD had some rather glaring flaws. If you had multiple Domain Controllers (DC) in your domain,
they would fight over which DC gets to make changes – and sometimes your changes would stick, and
sometimes they wouldn’t. To level up AD and keep the DCs from fighting all the time, Microsoft implemented
“last writer wins” – which can be a good thing, or it’s the last mistake that breaks all the permissions.

Then Microsoft took a left turn at Albuquerque and introduced a “Single Master Model” for AD. One DC that
could make changes to the domain, while the rest simply fulfilled authentication requests. However, when the
single master DC goes down, no changes can be made to the domain until it’s back up.

To resolve that fundamental flaw, Microsoft separated the responsibilities of a DC into multipleroles. Admins
distribute these roles across several DCs, and if one of those DCs goes out to lunch, another will take over any
missing roles! This means domain services have intelligent clustering with built-in redundancy and resilience.

Microsoft calls this paradigm Flexible Single Master Operation (FSMO).

FSMO Roles: What are They?

Microsoft split the responsibilities of a DC into 5 separate roles that together make a full AD system.

The 5 FSMO roles are:

 Schema Master – one per forest


 Domain Naming Master – one per forest
 Relative ID (RID) Master – one per domain
 Primary Domain Controller (PDC) Emulator – one per domain
 Infrastructure Master – one per domain
FSMO Roles: What do They do?

Schema Master: The Schema Master role manages the read-write copy of your Active Directory schema. The
AD Schema defines all the attributes – things like employee ID, phone number, email address, and login name
– that you can apply to an object in your AD database.

Domain Naming Master: The Domain Naming Master makes sure that you don’t create a second domain in the
same forest with the same name as another. It is the master of your domain names. Creating new domains
isn’t something that happens often, so of all the roles, this one is most likely to live on the same DC with
another role.

RID Master: The Relative ID Master assigns blocks of Security Identifiers (SID) to different DCs they can use
for newly created objects. Each object in AD has an SID, and the last few digits of the SID are the Relative
portion. In order to keep multiple objects from having the same SID, the RID Master grants each DC the
privilege of assigning certain SIDs.

PDC Emulator: The DC with the Primary Domain Controller Emulator role is the authoritative DC in the domain.
The PDC Emulator responds to authentication requests, changes passwords, and manages Group Policy
Objects. And the PDC Emulator tells everyone else what time it is! It’s good to be the PDC.

Infrastructure Master: The Infrastructure Master role translates Globally Unique Identifiers (GUID), SIDs, and
Distinguished Names (DN) between domains. If you have multiple domains in your forest, the Infrastructure
Master is the Babelfish that lives between them. If the Infrastructure Master doesn’t do its job correctly you will
see SIDs in place of resolved names in your Access Control Lists (ACL).

FSMO gives you confidence that your domain will be able to perform the primary function of authenticating
users and permissions without interruption (with standard caveats, like the network staying up).

It’s important to monitor AD in order to prevent brute force attacks or privilege elevation attempts –
two common attack vectors for data theft. Want to see how to do it? We can show you. Get a demo
to see how Varonis protects AD from both insider and external threats.
Windows 2000/2003 Multi-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, but it also introduces the possibility of conflicts that can potentially lead to
problems once the data is replicated to the rest of the enterprise. One way Windows 2000/2003 deals with
conflicting updates is by having a conflict resolution algorithm handle discrepancies in values by resolving to
the DC to which changes were written last (that is, “the last writer wins”), while discarding the changes in all
other DCs. Although this resolution method may be acceptable in some cases, there are times when conflicts
are just too difficult to resolve using the “last writer wins” approach. In such cases, it is best to prevent the
conflict from occurring rather than to try to resolve it after the fact.

For certain types of changes, Windows 2000/2003 incorporates methods to prevent conflicting Active Directory
updates from occurring.

Windows 2000/2003 Single-Master Model

To prevent conflicting updates in Windows 2000/2003, the Active Directory performs updates to certain objects
in a single-master fashion.
In a single-master model, only one DC in the entire directory is allowed to process updates. This is similar to
the role given to a primary domain controller (PDC) in earlier versions of Windows (such as Microsoft Windows
NT 4.0), in which the PDC is responsible for processing all updates in a given domain.

In a forest, there are five FSMO roles that are assigned to one or more domain controllers. The five FSMO
roles are:

Schema Master:

The schema master domain controller controls all updates and modifications to the schema. Once the Schema
update is complete, it is replicated from the schema master to all other DCs in the directory. To update the
schema of a forest, you must have access to the schema master. There can be only one schema master in the
whole forest.

Domain naming master:

The domain naming master domain controller controls the addition or removal of domains in the forest. This
DC is the only one that can add or remove a domain from the directory. It can also add or remove cross
references to domains in external directories. There can be only one domain naming master in the whole
forest.

Infrastructure Master:

When an object in one domain is referenced by another object in another domain, it represents the reference
by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The
infrastructure FSMO role holder is the DC responsible for updating an object’s SID and distinguished name in a
cross-domain object reference. At any one time, there can be only one domain controller acting as the
infrastructure master in each domain.

Note: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog
server (GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information
because it does not contain any references to objects that it does not hold. This is because a Global Catalog
server holds a partial replica of every object in the forest. As a result, cross-domain object references in that
domain will not be updated and a warning to that effect will be logged on that DC’s event log. If all the domain
controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is
not important which domain controller holds the infrastructure master role.

Relative ID (RID) Master:


The RID master is responsible for processing RID pool requests from all domain controllers in a particular
domain. When a DC creates a security principal object such as a user or group, it attaches a unique Security
ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a
relative ID (RID) that is unique for each security principal SID created in a domain. Each DC in a domain is
allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC’s allocated
RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain’s RID master. The
domain RID master responds to the request by retrieving RIDs from the domain’s unallocated RID pool and
assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting
as the RID master in the domain.

PDC Emulator:

The PDC emulator is necessary to synchronize time in an enterprise. Windows 2000/2003 includes the
W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows
2000/2003-based computers within an enterprise use a common time. The purpose of the time service is to
ensure that the Windows Time service uses a hierarchical relationship that controls authority and does not
permit loops to ensure appropriate common time usage.

The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest
becomes authoritative for the enterprise, and should be configured to gather the time from an external source.
All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner.

In a Windows 2000/2003 domain, the PDC emulator role holder retains the following functions:

 Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.
 Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to
the PDC emulator before a bad password failure message is reported to the user.
 Account lockout is processed on the PDC emulator.
 Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC
Emulator’s SYSVOL share, unless configured not to do so by the administrator.
 The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or
earlier PDC performs for Windows NT 4.0-based or earlier clients.

This part of the PDC emulator role becomes unnecessary when all workstations, member servers, and domain
controllers that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000/2003. The PDC
emulator still performs the other functions as described in a Windows 2000/2003 environment.

At any one time, there can be only one domain controller acting as the PDC emulator master in each domain in
the forest.