About FSMO roles

An Active Directory infrastructure works by default in multi-master mode. The main advantage is that it is possible to make a change to the Active Directory infrastructure from any domain controller.

This type of architecture leads to a risk of conflict when replicating between different domain controllers. The Active Directory replication system has several strategies for resolving potential conflicts, but there are some critical tasks that cannot be shared.

There are FSMO roles that are unique in the same domain, and there are roles that are unique in the Active Directory forest. Since Samba does not currently support multi-domain forests, in practice there is only one server that has the role in question in the Samba single-domain forest.

For these tasks, a single-master mode is used. These single masters are divided into 5 main FSMO roles plus 2 other smaller roles:

  • Schema controller.

  • Domain name master.

  • RID master.

  • Domain controller emulator.

  • Infrastructure master.

In Microsoft’s Active Directory documentation, only the above five roles are mentioned. The owner of each of these roles is defined in the Active Directory LDAP through the fSMORoleOwner’ attributes. For completeness, there are two fSMORoleOwner attributes on the DC=DomainDNSZones and DC=ForestDNSZones partitions. Samba also mentions these two additional roles in the different interfaces:

  • Infrastructure master (DomainDnsZones).

  • Infrastructure master (ForestDnsZones).

The following sections will explain in more detail the function of each of these roles, in order of practical importance.

The literature usually gives much emphasis to these FSMO roles, with recommendations for balancing the roles and many other esoteric actions. In practice, they can be left on a central server in the Samba-AD domain, and not bothered about. In a star replication topology, we will put the FSMO roles on one of the servers in the center of the star.

Roles should only be considered if the server that holds all FSMO roles is going to be decommissioned or shut down for an extended period of time.

In case the server with the FSMO roles is going to be shut down or put out of order, you have to perform a transfer of the roles to another of the servers. If the server with the FSMO roles is down and cannot be restarted, you must transfer the roles to another server. Seizing does the same thing as transferring, but in this second case it takes over the roles without asking the server who had them before.

The transfer of roles is a simple action that does not pose any particular problems.

Role of RID Master

Each user, group and machine object in the domain is identified by a RID (see the Winbind section). The RID must be unique across a domain, whereas a new object can be created on any of the domain controllers.

To avoid conflicts, Microsoft has devised a separate RID pool system on each of the domain controllers. Thus the first controller will have pool 1000-1499 (500 RIDs). When the second domain controller is joined, it will have the next available pool (1500-1999). The third domain controller will have the next available pool (2000-2499, or another slice if this slice has already been assigned to another domain controller).

The server that is responsible for providing the RID pools holds the FSMO RID role.

When a domain controller reaches 80% utilization of its pool (i.e. 400 RIDs used), it contacts the FSMO RID Master to obtain a new pool. The FSMO RID Master will then give him the next available pool, and register that the pool has been assigned.

This means that user RIDs do not follow each other if they were not created on the same domain controller. For example, on the first controller, a new user will have RID 1001, while on the second controller, a new user will have RID 1501, even though they were created one after the other.

If a domain controller has exhausted its RID pool and cannot contact the server with the FSMO RID role, it will not be able to create a new object. The pool exhaustion error message is not explicit on the RSAT tools (“the server refuses to execute the request”), but it is very explicit on the command line samba-tool (no RID left).

Note

There is only one RID master in an Active Directory forest.

PDC role (Domain Controller emulator)

When designing Active Directory 2000, Microsoft designed a simple method for migrating NT4 domains to Active Directory technology. When migrating an NT4 domain with multiple domain controllers, the procedure was to update the PDC server before updating the BDCs.

In the intermediate phase where the PDC was migrated to Active Directory, but the BDCs were still in NT4 mode, it was necessary to ensure replication of the new AD to the NT4 BDCs. The first domain controller that was migrated, the PDC, therefore retained the PDC role of replication to the BDCs.

Nowadays, domain controllers, be they Microsoft or Samba, no longer support this PDC-BDC NT4 synchronization function. Nevertheless, the name has remained.

The domain controller whose role is domain controller emulator has several functions:

  • It handles password change. When a password change occurs, the server with the FSMO PDC role will receive the password change first. If a Domain Controller handles an authentication that fails, it will ask the server with the PDC role if it has not had a password update in the meantime, as it may not yet have replicated the password change because the password change request may have been initiated from another geographically remote site.

  • It manages time synchronization with the workstations: it is the NTP master.

  • It manages the locking of user accounts.

Note

There is only one domain controller emulator in any Active Directory domain.

Schema controller role

The domain controller holding this role is the only one who can update Active Directory schema. Once these schema have been updated, it replicates them to all domain controllers. These schema are found in each DC and are located in the LDAP in CN=schema,CN=configuration,DC=<domain>.

Note

There is only one Schema Controller in any Active Directory forest.

Domain name master role

The Domain Controller holding this role is the only one to manage the creation/deletion of domains within the forest.

This role supposes that it also manages the creation/suppression of trust relationships between different domains, and that it replicates these informations to all the domain controller of the forest.

These informations are stored in the LDAP of each domain controller in a partition named Configuration Naming Context found in CN=Partitions,CN=Configuration,DC=<domain>.

Note

There is only one Domain name master in any Active Directory forest.

Infrastructure master role

The domain controller whose role is Infrastructure master is responsible for updating SID objects and distinguished names referring to an object in an inter-domain situation, for example if a user in domain A is added to a group in a domain B.

Note

The infrastructure role should not be on a domain controller that also has the Global Catalog (see LDAP doc) in a multi-domain forest. Since Samba only supports single-domain forests, this is not a concern.

Note

There is only one infrastructure master in any Active Directory domain.