AD Domain Services supports five Operations Master roles:
1 Domain Naming Master;
2 Schema Master;
3 Owner of relative identifiers (Relative ID Master);
4 Domain infrastructure owner (Infrastructure Master);
5 Primary Domain Controller Emulator (PDC Emulator).
Domain Naming Master.
The role is designed to add and remove domains in the forest. If a controller with this role is not available when adding or removing domains in the forest, the operation will fail.
There is only one domain controller in the forest with the role of Domain Naming Master.
In order to see which domain controller you have as Domain Name Owner, you need to run the snap-in Active Directory - Domains and Trust click right click to the root node and select " Owner of the operation"
In the Domain Naming Master line, you will see which domain controller performs this role.
Schema Master.
A controller with the Schema Owner role is responsible for making all changes to the forest schema. All other domains contain read-only replicas of the schema.
The Schema Owner role is unique across the forest and can only be defined on one domain controller.
In order to view the domain controller acting as the schema owner, you need to run the snap-in Active Directory Schema, but in order to do this you need to register this equipment. To do this, launch the command line and enter the command
regsvr32 schmmgmt.dll
After that, click " Start"select a team" Execute"and enter" mmc" and click the " button OK". Next in the menu, click " File"let's choose a team" Add or remove a snap-in". In Group Available accessories select " Active Directory Schema", press the button " Add" and then the " button OK".
Right-click the root node of the snap-in and select " Owner of the operation".
In the Current schema owner (online) line, you will see the name of the domain controller that performs this role.
Owner of relative identifiers (Relative ID Master).
This role provides all users, computers and groups with a unique SID (Security Identifier - a variable length data structure that identifies a user, group, domain or computer account)
The RID Master role is unique within a domain.
To see which controller in the domain acts as the owner of the identifier, you need to run the " Owner of the operation".
In the RID tab you will see the name of the server performing the RID role
The owner of the domain infrastructure (Infrastructure Master).
This role is relevant when using multiple domains in a forest. Its main task is to manage phantom objects. A phantom object is an object that is created in another domain to provide some resources.
The role of domain infrastructure is unique to a domain.
To see which controller in the domain acts as the owner of the domain infrastructure, you need to run the " Active Directory - Users and Computers", right-click on the domain and select " Owner of the operation".
In the "tab" Infrastructure"you will see the controller performing this role in the domain.
Primary Domain Controller Emulator (PDC Emulator).
The role of the PDC emulator is several important functions (not all are listed here, only the main ones):
Participates in password update replication. Every time a user changes their password, this information is stored on a domain controller with the PDC role. On user input incorrect password authentication is sent to the PDC emulator to obtain a possibly changed account password (so if you enter an incorrect login password, the password check takes longer compared to entering the correct password).
Participates in Group Policy updates in the domain. In particular, when Group Policy changes on different domain controllers at the same time, the PDC emulator acts as the focal point for all Group Policy changes. When you open the Group Policy Management Editor, it binds to a domain controller that acts as a PDC emulator. Therefore all changes group policies by default are entered into the PDC emulator.
The PDC emulator is the main time source for the domain. PDC emulators in each domain synchronize their time with the PDC emulator of the forest root domain. Other controllers synchronize their time with the domain PDC emulator, computers and servers synchronize time with the domain controller.
To see which controller in the domain acts as a PDC emulator, you need to run the " Active Directory - Users and Computers", right-click on the domain and select " Owner of the operation".
In the PDC tab you will see the controller performing this role.
The FSMO role primary domain controller emulator (PDC emulator) is the second role (of three) at the domain level. That is, there should be one PDC emulator in one domain, but there can be several of them in the entire AD forest, depending on the number of domains.
The main article on Active Directory is . Read also other articles on the roles of operations masters -.
If you are interested in the topic Windows Server, I recommend turning to the section on my blog.
To better understand the functionality of this FSMO role, you must first look at the history of its appearance.
A little history
The role of the PDC emulator is necessary primarily to ensure compatibility with Windows versions below 2000. In a mixed environment with Windows NT, 95, 98 clients, the PDC emulator performs the following tasks:
- Participates in the process of changing passwords for user and computer accounts;
- Replicates updates to backup domain controllers;
- Performs the tasks of the Domain Master Browser.
For Windows NT 3.51, 4 domains, the primary domain controller emulator performed a very important function and if it failed, the entire domain actually went into read-only mode:
- Users would not be able to change passwords (an error would be thrown “Unable to change password on this account. Please contact your system administrator");
- When creating an account you would receive an error ( "could not find domain controller for this domain");
- There would be replication errors on the backup domain controllers (due to the fact that the backup domain controllers replicated changes only from the PDC. To be able to make changes to the BDC database, it must be made the primary domain controller).
With the development of technology, the emphasis was placed on the interchangeability and equality of all domain controllers, and thus the Windows 2003 domain was already a completely different structure, the basis of which was multi-master replication. Although “secondary” (something like a BDC) domain controllers remain, primary controllers as such have ceased to exist.
Modern purpose
Today, the role of the PDC emulator, in my opinion, is less important compared to other operation masters, but it is still needed for a number of tasks that somehow simplify administration and add some convenience:
1) Password replication occurs on the PDC emulator in priority mode. That is, if the user changes the password (and he can do this on any DC), then the domain controller first contacts the PDC emulator to report the fact of the password change. In turn, other DCs, if authorization with a changed password goes through them, do not refuse the user, but turn to the primary domain controller emulator to view possible changes and, having received them, authorize the user with a new password.
If the PDC is unavailable, you simply will not be able to log into the system with a new password when authorizing through another domain controller and will receive an increase in the login attempt counter. Of course, this situation will occur for a very short period of time, until changes are replicated to other DCs, but in reality it does not occur in practice at all;
The same applies to account locks - first of all, they are replicated to the PDC emulator.
2) To prevent conflicts, change group policies, all GPO changes actually happen on the PDC emulator and it doesn’t matter where exactly you work with the equipment;
3)
Windows Server 2003 includes some additional security objects by default. When you upgrade your infrastructure from Windows Server 2000, you you must start the update process directly from the PDC emulator so that these groups and Accounts first appeared on it and only then were replicated to other controllers. The objects themselves are stored in the container CN=WellKnown Security Principals,CN=Configuration,DC=
4) The SDProp (Security Descriptor propagator) mechanism runs on the PDC emulator. This mechanism “puts in order” the access control lists (ACLs) of Active Directory objects. Critical domain security objects (these objects have the attribute value set to 1 adminCount) sample ACLs are stored in a special container called AdminSDHolder.
By the way, here full list the most important security objects for the newly created domain:
Of course, I created the bisquit account manually, yours will be different;
5) During installation of the first domain controller, the service NetLogon creates a DNS SRV record _ldap._tcp.pdc._msdcs.DnsDomainName. This entry allows clients to discover the PDC emulator. Only the owner of this role can modify this entry;
6) On the primary domain controller emulator DFS namespace changes are in progress(Distributed File System). If the PDC emulator is not found, then DFS will not work correctly;
7) Process domain or forest functional level promotion is performed on the PDC emulator.
8) Perhaps one of the most important functions is time propagation throughout the domain. You can read more about setting time in a domain in my article.
Best practics
Many best practics Primary domain emulator administrations correspond to other operations master roles:
Administration
There is no special equipment to control the operation of the PDC emulator.
You can change the owner of a role using the snap-in . For this:
- Open the equipment on DC01, right-click on Active Directory - Users and Computers and choose Change controller domain Active Directory;
- Next, select the domain controller to which we want to transfer the role (for me it is DC02, by default the server that owns the role is always selected). We confirm the warning;
- Right click on again Active Directory - Users and Computers, but we already choose The owner of the operations...;
- Press the button Change….
After this, you need to confirm your choice and receive a notification about the successful transfer of the role.
This completes the review of the fsmo role of the PDC emulator.
Active Directory contains FSMO (Flexible Single Master Operations) roles that are used to perform various tasks within a forest and domain. There are two forest-level roles and three domain-level roles.
1. Schema Master / Forest/ Contains a forest diagram
2. Domain Naming Master (Domain Naming Master) / Forest/ Manages domain names
3. lnfrastructure Master Domain (Infrastructure Master) / Domain/ Provides cross-domain object references
4. PDC Emulator (Primary Domain Controller Emulator) / Domain/ Responsible for time in the forest
Handles password changes, Serves as a connection point for managing GPOs, Locks out accounts.
5. RID Master (Relative Identifier Master (RID)) / Domain/ Manages and replenishes RID (relative identifier) pools
In some situations, such as decommissioning a domain controller, upgrading a domain, or experiencing performance issues, you will need to transfer FSMO roles to a new domain controller. Each of the specified roles must be available in Active Directory at all times. One way to transfer or transfer these roles to a new domain controller is to use the NTDSUtil utility.
To transfer domain FSMO roles, follow the steps below:
1 . Open the window command line (cmd.exe). enter NTDSUtil and press
2. Enter roles and press
3. Enter connections and press
connect to server [Server_name] and press
5. Enter quit and press
6. The PDC Emulator role will be transferred first. Enter transfer pdc and press
transfer rid master and press
8. If necessary, you can enter transfer infrastructure master and press
9. Now that the transfer of all domain FSMO roles is complete, enter quit and press
Of course, the above steps must be completed in each domain.
If you decide to transfer forest-level FSMO roles, follow these steps:
Open a command prompt window ( cmd.exe), enter NTDSUtil and press
2. Enter roles and press
3. Enter connections and press< Enter>.
4. Now you need to connect to the server that will contain these FSMO roles in the future. Enter connect to server [ Name:_server] and press
5. Enter quit and press
6. The Schema Master role will be transferred first. Enter transfer schema master and press
7. If necessary, you can enter transfer naming master and press
8. Now that the transfer of all FSMO roles in the forest is complete, enter quit and press
Managing FSMO roles using standard MMC snap-ins is not a very convenient process, since you have to use different snap-ins to access different roles, and some of them are not so easy to get to. In addition, MMC snap-ins do not allow roles to be seized if the domain controller on which they were located fails. It is much more convenient to use the utility for these purposes ntdsutil, which will be discussed in this article.
Before moving on to the practical part, let’s remember what it is and consider what exactly will happen to ActiveDirectory if it fails. There are five FSMO roles in total, two for the forest and three for the domain.
Forest-level roles exist in a single instance and, while important, are the least critical to the functioning of AD. What happens if each of them is unavailable:
- Master of the scheme- it is impossible to change the scheme. However, this procedure is carried out every few years when introducing controllers on a newer OS into the network or installing some other server products, such as Exchange. In practice, the absence of the owner of the scheme may not be noticed for years.
- Domain naming owner- it is impossible to add or delete a domain. Similarly, with the owner of the circuit, his absence may go unnoticed for quite a long time.
Domain-level roles exist one per domain and are more critical to the functioning of AD.
- Infrastructure Master- if there are several domains on controllers that are not global catalogs membership in local groups of the domain may be violated. If all domain controllers are global directories (today this is the configuration recommended by Microsoft), then you can safely forget about the existence of the owner of the infrastructure, just like with a single domain in the forest.
- Host RID- after a while it will be impossible to create new object in AD, the time depends on the remaining number of free SIDs, which are issued in batches of 500 blanks. If your AD has a small number of objects and you do not create new ones every day, then the absence of the RID owner will go unnoticed for a long time.
- PDC emulator- the most critical role. If it is unavailable, it will immediately become impossible to log into the domain of clients prior to Windows 2000 (if they still exist somewhere), time synchronization will stop, and some policies will not take effect when an incorrect password is entered. In practice, the absence of a PDC emulator will be noticed the first time the clock is out of sync for more than 5 minutes, and this may happen sooner than you might expect.
At the same time, as you can see, there is not a single FSMO role whose failure would lead to a significant loss of AD functionality; even if all FSMO roles fail, the infrastructure can work normally for several days, weeks or even months.
Therefore, if you are going to take a controller containing some or all roles out of operation for a while (for example, for maintenance), then there is no need to transfer them; your AD will live normally without them.
Transferring roles is appropriate if you plan to withdraw this server out of service for a long time or transfer it to another department (for example, to another site), or planned operations may lead to its failure (for example, hardware upgrade).
In the event of a controller failure, do not rush to seize roles, you will always have time to do this, otherwise, when restoring and connecting to the network a server that previously contained FSMO roles, you will get many unpleasant moments associated with USN Rollback and restoration of normal functioning of the domain. If, after all, the roles were captured, and then you restored the old controller, then the best solution will reinstall the system on it and re-enter the domain.
Also another non-obvious point if you have several domains and not all controllers are global catalogs do not place the infrastructure master on a controller with a global catalog. This is tantamount to its absence.
You can find out which controllers have FSMO roles with the command:
Netdom query fsmo
To manage FSMO roles, run the utility ntdsutil on any domain controller:
Ntdsutil
Then let's move on to managing roles:
The next step is to connect to the domain controller to which we are going to transfer roles; to do this, go to the submenu for connecting to servers:
Connections
and connect to the desired server:
Connect to server SERVERNAME
Where SERVERNAME- the name of the domain controller we need. Then we exit the submenu:
It should be remembered that we can run the utility on any of the domain controllers and join any other DC to transfer or seize roles. In our example, we are physically located on the server SRV-DC01 connected to the server WIN2K8R2-SP1 and we’ll try to give him some kind of role.
The command is used to transfer roles transfer the argument of which is the name of the transferred role, for each of the roles the following names are used:
- naming master- domain naming master
- infrastructure master- owner of infrastructure
- PDC- PDC emulator
- RID master- RID owner
- schema master- owner of the circuit
Attention! On systems prior to Windows Server 2008 R2, for domain naming owner name used domain naming master.
For example, to transfer a role domain naming owner let's run the command:
Transfer naming master
A dialog box will appear that will ask us to confirm the action; we advise you to always carefully study its contents.
Having received an affirmative answer, the utility will transfer the selected role to another server.
Now let's imagine that the server WIN2K8R2-SP1 is irretrievably out of action and we need to seize the role master of naming back. The command is used to seize roles seize, which has a similar syntax.
To capture the role, let's run again ntdsutil and, having connected to the controller for which we will capture, execute the command:
Seize naming master
After we confirm the takeover ntdsutil will try to carry out the operation of transferring the role and only if it is impossible will it perform a capture.
This is done in order to avoid a situation where the role is seized from a working controller and there will be two owners of the same role in the network.
Remember that after capture, include in the network the controller from which the role was captured it is forbidden!
As you can see, using the utility ntdsutil not at all difficult and even more convenient than managing roles using MMC snap-ins. In addition, the possibilities ntdsutil are not limited to managing roles, but we will talk about this in the following materials.
FSMO, or Flexible single-master operations(single-executor operations) are operations performed by domain controllers Active Directory (AD), which require mandatory server uniqueness for each operation. Depending on the type of operation, uniqueness FSMO means within a single domain or forest of domains. Various types FSMO can be executed on one or several domain controllers. Performance FSMO called a server role servers, and the servers themselves are the masters of operations.
Most operations in AD can be done on any domain controller. Replication service AD will copy the changes to other domain controllers, ensuring the identity of the database AD on all controllers of the same domain. Resolving conflicts occurs as follows - the one who made the last changes is right.
However, there are several actions (for example changing the schema AD), in which conflicts are unacceptable. That's why there are servers with roles FSMO. Their task - prevent such conflicts. Thus, the meaning of roles FSMO in the following - each role can only be executed on one server at a time. And if necessary, it can be transferred to another domain controller at any time.
There are five roles in the forest FSMO. To begin with, I will give a brief description of them. :
- The owner of the scheme ( Schema Master) - responsible for making changes to the schema Active Directory. There can only be one for the entire forest of domains.
- Domain naming master ( Domain Naming Master) - is responsible for the uniqueness of names for created domains and application sections in the forest. There can only be one for the entire forest of domains.
- Infrastructure owner ( Infrastructure Master) - stores data about users from other domains who are members of local groups of their domain. There can be one for each domain in the forest.
- Master RID (RID Master) - is responsible for allocating unique relative identifiers ( RID) required when creating domain accounts. There can be one for each domain in the forest.
- Emulator PDC (PDC Emulator) - responsible for domain compatibility NT4 and clients to Windows 2000. There can be one for each domain in the forest.
Now let’s take a closer look at each role and find out how important they are for the functioning of Active Directory.
Schema Master
Schema Master- is responsible for making changes to the schema, where descriptions of all classes and attributes are located Active Directory. The scheme is modified extremely rarely, for example when changing the domain level, installing Exchange and sometimes other applications. This role can be located on any domain controller within the forest. If unavailable Schema Master change the scheme AD will be impossible.
Domain Naming Master
Domain Naming Master responsible for operations related to domain names A.D. however, the list of his responsibilities is somewhat longer :
- Adding and removing domains within a forest. Only a controller with the role is allowed to add and remove domains Domain Naming Master. It ensures that the domain being added is unique within the forest NETBIOS-Name. If Naming Master is not available, it is impossible to add or delete a domain in the forest.
- Creating and deleting partitions. Beginning with Windows 2003 it became possible to create separate sections - Application Directory Partitions, which are used for storage in AD arbitrary data. As an example, storing data for DNS-servers in sections ForestDnsZones And DomainDnsZones. Managing partitions when unavailable Domain Naming Master impossible.
- Creating and deleting cross-references. Cross-referencing is used to search the directory if the server to which the client is connected does not contain the desired copy of the directory, and you can also refer to domains outside the forest, provided they are available. Cross references are stored ( crossRef) in a container Partitions section Configuration, but only Domain Naming Master has the right to change the contents of this container. If unavailable Domain Naming Master It will not be possible to create a new cross-reference or delete an unnecessary one.
- Approval of domain renaming. To rename a domain, use the utility rendom.exe. She writes a script with instructions that will need to be executed during the renaming process. This script is placed in a container Partitions section Configuration. Since only the controller with the role has the right to change the contents of this container Domain Naming Master, then he is responsible for checking instructions and recording attributes.
This role can be located on any domain controller within the forest.
Infrastructure Master
If the server is not a global directory ( G.C.), then its database does not contain data about users from other domains. However, we can add users from other domains to domain local groups. And the group is in the database AD must physically have links to all users. This problem was solved by creating a fictitious object - a phantom ( phantom). Dummy objects are a special type of internal database object and cannot be viewed through ADSI or LDAP. It is the infrastructure master who deals with phantoms.
Another feature of this role is that for proper operation in a multi-domain environment, the domain controller acting as the infrastructure master should not be a global catalog server. If the owner of the role Infrastructure Master is also a server G.C., dummy objects are not created or updated on this domain controller. This occurs because the global catalog already contains partial replicas everyone objects in Active Directory and he has no need for phantoms .
RID Master
Each account in a domain (user, computer, group) must have a unique security identifier ( SID), which uniquely identifies this account and serves to differentiate access rights. Looks like SID in the following way:
S-1-5-Y1-Y2-Y3-Y4, Where
- S-1 - SID revision 1. Currently only this revision is used.
- 5 - Indicates who issued the SID. 5 means NT Authority. However, so-called "well-known identifiers" SID (well-known SID) can have 0, 1, and some other values in this part.
- Y1-Y2-Y3- ID of the domain to which the account belongs. Same for all objects security principal within one domain.
- Y4- Relative identifier ( Relative ID, RID) specific to a specific account. Substituted from the pool of relative domain identifiers at the time of account creation.
Domain controller with role RID Master is responsible for identifying a sequence of unique RID to each domain controller in its domain, as well as for the correctness of moving objects from one domain to another. Domain controllers have a common pool of relative identifiers ( RID Pool), RID from which each controller is allocated in portions of 500 pieces. When their number comes to an end (becomes less than 100), the controller requests a new portion. If necessary, the number of issued RID and the request threshold can be changed.
Another area of responsibility RID Master- moving objects between domains. Exactly RID Master ensures that one object cannot be moved to two different domains at the same time. Otherwise, a situation is possible when in two domains there will be two objects with the same GUID, which is fraught with the most unexpected consequences.
If RID Master will not be available, then after the end of free RID It will become impossible to create a new account, and it will also be impossible to migrate objects from the current domain to another.
PDC Emulator
Initially the main task Primary Domain Controller (PDC) Emulator was ensuring compatibility with previous versions Windows. In a mixed environment where clients meet Windows NT4.0/ 95/98 and domain controllers NT4, PDC Emulator performs (only for them) the following functions:
- Processing the “password change” operation for users and computers;
- Replication of updates to BDC (Backup Domain Controller);
- Network Explorer (search for network resources).
Starting at the domain level Windows 2000 and he got older than his work. Domain controller with role PDC Emulator performs the following functions:
- Responsible for changing passwords and monitoring user bans in case of password errors. A password changed by any other domain controller is first replicated to PDC Emulator. If authentication on any other domain controller is not successful, the request is repeated on PDC Emulator. If the account is successfully authenticated immediately after an unsuccessful attempt, PDC Emulator it is notified and the counter of failed attempts is reset to zero. It is important to note that in the event of unavailability PDC Emulator information about changing the password will still spread throughout the domain, it will just happen a little slower.
- Group Policy Editor connects to the server by default PDC Emulator, and policy changes occur on it. If PDC Emulator is not available, you will have to tell the editor which domain controller to connect to.
- By default it is PDC Emulator is an exact time server in the domain for clients. PDC Emulator root domain in the forest is the default time server for PDC Emulator in child domains.
- Namespace changes Distributed File System (DFS), are entered on the domain controller with the role PDC Emulator. Root servers DFS periodically request updated metadata from it, storing it in their memory. Unavailability PDC Emulator may result in incorrect operation DFS.
- IN Active Directory There are so-called “Built-in security participants” ( Well Known Security Principals). Examples include accounts Everyone, Authenticated Users, System, Self And Creator Owner. They are all managed by a domain controller with the role PDC Emulator. More precisely, with changes in AD PDC Emulator checks and updates the contents of the container “ CN=WellKnown Security Principals, CN=Configuration, DC=
>”. - In every forest domain Active Directory there is an owner of administrative security descriptors - AdminSDHolder. It stores information about security settings for so-called protected groups ( protected groups). At certain intervals, this mechanism requests a list of all members of these groups and assigns them rights in accordance with its access control list. Thus AdminSDHolder Protects administrative groups from changes. Performed AdminSDHolder on a domain controller with the role PDC Emulator.