Export (0) Print
Expand All

3.1.1.1.11 FSMO Roles

Each DC accepts originating updates for most attributes of most objects within its writable NC replicas. But certain updates are only accepted if the DC is the single designated "master" DC for the update, as specified in this section. The mechanism is called FSMO roles, which stands for flexible single master operation (FSMO) roles.

If some or all of the updates to an object are single-mastered, that object belongs to a defined set of objects. [MS-DRSR] section 4.1.10.5.3 (GetReplScope) specifies these sets, which are called FSMO roles. Each FSMO role is contained within a single NC. Each domain NC contains three FSMO roles called InfrastructureMasterRole, RidAllocationMasterRole, and PdcEmulationMasterRole. A config NC contains one FSMO role called DomainNamingMasterRole. A schema NC contains one FSMO role called SchemaMasterRole. An application NC has no FSMO roles.

Since a DC operating as AD LDS does not host domain NCs, it cannot own any of the three roles contained by domain NCs. It can own the Schema Master and Domain Naming FSMO roles.

In a given NC, each FSMO role is represented by an object. [MS-DRSR] section 4.1.10.5.3 (GetReplScope) specifies these objects, which are called FSMO role objects.

The fSMORoleOwner attribute of each FSMO role object is an object reference to the nTDSDSA object of the DC that owns the role; that is, the DC that performs updates to objects in the role. nTDSDSA objects and how they represent DCs are specified in section 6.1.

An originating update to an object within a FSMO role generates an LDAP referral if the DC that receives the request cannot perform the update; the referral is to the DC represented by the nTDSDSA object referenced by the FSMO role object's fSMORoleOwner attribute on the DC that received the request.

The processing of updates affected by FSMO roles is fully specified in section 3.1.1.5.

The IDL_DRSGetNCChanges method ([MS-DRSR] section 4.1.10) makes an originating update to the fSMORoleOwner attribute of a FSMO role object while preserving single-mastering of updates to the FSMO role. The ability to update the fSMORoleOwner attribute in this way is exposed through LDAP as the root DSE updates becomeDomainMaster, becomeInfrastructureMaster, becomePdc, becomePdcWithCheckPoint, becomeRidMaster, and becomeSchemaMaster specified in section 3.1.1.3.

Reading the rootDSE attribute validFSMOs on a DC returns the set of all FSMO roles (represented as FSMO role objects) that the DC will update; this is specified in section 3.1.1.3.

Show:
© 2016 Microsoft