Microsoft Windows Active Directory is the central repository for all enterprise objects and their corresponding attributes. This database is hierarchical, capable of supporting multiple hosts and holding millions of objects. Multi-leader support allows you to change the database from any domain controller within the enterprise, regardless of its network connectivity status.

Multi-master support model in Windows 2000

A multi-master database (such as Active Directory) accepts changes from any domain controller within the enterprise, potentially leading to conflicts when data is replicated to other computers. One of the methods for dealing with conflicting updates in Windows 2000 is the "Last Write Precedence" algorithm, which accepts the data value from the most recently modified domain controller and discards the values ​​on other domain controllers. However, some conflicts are so complex that they cannot be resolved in this way. They are easier to prevent than to eliminate after the fact.

Some types of changes in Windows 2000 are handled in ways that prevent Active Directory update conflicts.

Single host support model in Windows 2000

To prevent conflicting updates from occurring, Active Directory updates specific objects using a single-leader model. Under this model, only one domain controller in the entire directory is authorized to make updates. This process similar to the role that was assigned to the primary domain controller (PDC) in the early Windows versions(for example, in Microsoft Windows NT 3.51 and 4.0) that the PDC is responsible for handling all updates in a particular domain.

Windows 2000 Active Directory extends the single-master model used in earlier versions of Windows to include support for multiple roles and the ability to transfer roles to other controllers within the enterprise. Because the Active Directory role is not strictly tied to a single domain controller, it is called the FSMO (Flexible Single Master Operation) role. There are five FSMO roles in Windows 2000:

• schema master
• domain naming master
• RID host
• PDC emulator
• infrastructure daemon

The role of the FSMO Schema Master

The schema master domain controller is responsible for updating the directory schema (i.e. schema naming context or LDAP://cn=schema,cn=configuration,dc= ). Only this domain controller can make changes to the directory schema. After the schema is updated, it replicates from the schema master to other domain controllers in the directory. There can only be one schema master per directory.

FSMO Role "Domain Naming Master"

The domain controller acting as the domain naming master is responsible for changing the domain namespace of the directory within the forest (i.e., the partitions\configuration naming context or LDAP://CN=Partitions, CN=configuration, DC= ). Only this controller has the right to remove and add domains to the directory. It also adds and removes cross-references to domains in external directories.

FSMO Role "RID Master"

The domain controller acting as the RID master is responsible for handling RID pool requests from other controllers within a particular domain, and for deleting objects from a domain and placing them in another domain.

When a domain controller creates a primary security principal object (such as a user or group), it assigns a security identifier (SID) to it. This identifier consists of a domain SID (same for all security identifiers created in the same domain) and a relative identifier (RID) (unique for each security principal created in the same domain).

Each Windows 2000 domain controller in a domain has a pool of relative identifiers (RIDs) that it can assign to newly created security principals. When the number of RIDs in a domain controller's pool falls below a threshold, it queries the RID master for new identities. The RID master retrieves the IDs from the unallocated domain pool and assigns them to the requesting domain controller's pool. There is only one RID master per directory domain.

Role of FSMO "PDC Emulator"

The PDC emulator is required for time synchronization across the enterprise. Windows 2000 includes the W32Time (Windows Time) time service used by the Kerberos authentication protocol. All computers under Windows control 2000 within the same enterprise use the total time. To ensure correct time synchronization, the Windows Time service must use a hierarchical relationship structure that controls permissions and prevents "loops" in control.

The domain PDC emulator acts as the master domain emulator. The PDC emulator at the forest root becomes the master emulator within the enterprise. It should be configured to receive the time value from an internal source. PDC emulator FSMO role holders follow the domain hierarchy when choosing a time source.

In a Windows 2000 domain, the PDC Emulator role holder retains the following features: Password changes made by other domain controllers are first replicated to the PDC Emulator.

Password changes made by other domain controllers are first replicated to the PDC emulator.

Before the user receives the appropriate error message, authentication failures on a specific domain controller caused by an incorrect password are reported to the PDC emulator.

Account lockouts are handled on the PDC emulator.

The PDC emulator performs all the functions of the PDC server emulator for Microsoft Windows NT 4.0, previous versions emulators on Windows based NT 4.0 or earlier clients.

You do not need to use this part of the PDC Emulator role if all workstations, servers, and domain controllers running Windows NT 4.0 or earlier are upgraded to the Windows 2000 level. The PDC Emulator performs all the same functions as in a Windows 2000 environment.

The following describes the changes that occur during the upgrade process: Windows 2000 clients (workstations, servers) and earlier clients that have the Distributed Services Client Package installed do not give preference to the domain controller when performing directory writes (such as password changes) , which declared itself a PDC, but use any domain controller for this.

After you upgrade to Windows 2000, Backup Controllers (BDCs) in domains lower level the PDC emulator stops receiving replication requests from the lower layer.

Windows 2000 clients (workstations, servers) and earlier clients that have the Distributed Services Client Package installed use Active Directory to find network resources. They do not require the Windows NT Browser service.

Role of FSMO "Infrastructure"

A reference to an object in one domain in an object in another domain is determined by the GUID, SID (for security principals), and distinguished name (DN) of the object. The domain controller acting as the infrastructure master is responsible for updating security identifiers and object distinguished names in cross-domain object references.

Note.

The infrastructure master (IM) role should not be filled by a domain controller that is a global catalog server. Otherwise, the infrastructure master will not update object information because it does not contain references to objects that it does not store. The reason for this behavior is that the global catalog server maintains partial replicas of all objects in the forest. As a result, cross-domain object links in this domain will not be updated, and a warning will appear in the event log of this domain controller.

If controllers in a separate domain also store the global catalog, all domain controllers will have up-to-date information, no matter which domain controller holds the Infrastructure Master role.

No related posts...

Transferring FSMO. The purpose of our event is to transfer FSMO from one domain controller to another. Just in case, I'll look at several ways to migrate roles, including the case when the current FSMO master is not available.

First, some theory:
FSMO (Flexible single-master operations - “operations with one executor”) - types performed by controllers Active domain Directory operations that require the mandatory uniqueness of the server performing them.

That is, all domain controllers are equal, but one (or several) is more equal than others, insofar as they perform these same operations with one executor. Depending on the type of operation, FSMO uniqueness is implied within either a domain forest or a domain.

In total, the small-soft corporation has given us 5 roles:

• Schema master - one server with this role for the entire forest. The role is needed to extend the schema Forests Active Directory, this operation is usually performed by adprep /forestprep
• The owner of domain names (Domain naming master) - one for the entire forest. A server with this role must ensure unique names for all domains and application partitions that are created in the AD forest.
• Relative identifiers owner (PDC emulator) - one server per domain. Performs several functions: is the main browser in Windows networks, keeps track of user locks when the password is entered incorrectly, is the main NTP server in the domain, designed to support clients with operating systems previous to Windows 2000.
• Primary Domain Controller Emulator (Infrastructure Master) - one server per domain. A server with this role is required for the successful completion of the adprep /domainprep command. Responsible for updating security identifiers (GUIDs, SIDs) and object distinguished names in cross-domain object references.
• Domain Infrastructure Owner (RID Master) - one server per domain. The server distributes RIDs (500 each) to other domain controllers to create unique SIDs.

To manage the Schema master role, you must be in the "Schema admins" group.
To manage the Domain naming master role, you must be a member of the Enterprise admins group.
To manage the PDC emulator, Infrastructure Master and RID Master roles, you must have domain administrator rights "Domain Admins"

The need to transfer roles can arise for various reasons, as well as in large networks these roles can be performed by different servers, although in our case all roles are performed by one server. It is important that each role is performed in your domain, if any role is not assigned to any server, then many unpleasant surprises can await you, both immediately and after a long time, depending on the AD structure.

When a domain is created, by default, all roles are assigned to the first domain controller in the forest. Role reassignment is rarely required. Microsoft recommends using FSMO role transfer in the following cases:

• Planned downgrading of the role of a domain controller that is the owner of FSMO roles, for example, in order to decommission the server (this is just my case);
• Temporarily shutting down a domain controller, for example, to perform preventive work. This is especially important when disabling the PDC emulator. Temporarily disabling other operations masters has less impact on AD.

Seizure of FSMO roles will have to be done in the following cases:

• If the current holder of the FSMO role has experienced failures that prevent the successful performance of the functions inherent in this role and prevent the transfer of the role;
• On the domain controller that was the owner of the FSMO role, the operating system is reinstalled or does not boot;
• A domain controller that held the FSMO role was forcibly demoted using the dcpromo /forceremoval command.

So the first thing we need is to find out which server is the master of FSMO. The easiest way to do this is with the netdom utility. By typing in the console:

> netdom query fsmo

We will get a list of all five roles with the FQDN of the hosts. The same utility can be used after the transfer of roles to verify the success of the operation.

Now you can proceed directly to the transfer of FSMO:

The first method is the simplest and the most pleasant to me - transferring FSMO roles using the ntdsutil utility:

ntdsutil.exe is a command-line utility for maintaining the Active Directory. It provides many AD management features, including transferring and seizing FSMO roles.
To transfer roles, go to any domain controller (This does not have to be the current or future FSMO master) located in the forest in which you want to transfer roles. We recommend that you log on to a domain controller that is assigned FSMO roles. Launch the console and enter:
>ntdsutil
After that, the utility starts in interactive mode and can accept commands. Our first command indicates that we want to work with FSMO
>roles
In response, the prompt will change to fsmo maintenance: Then, to call the connection "menu", enter
>connections
And the prompt changes to server connections: Now you can specify which server we want to connect to (<Имя_сервера>is the name of the domain controller to which you want to transfer the FSMO role.)
>connect to server<Имя_сервера>
to exit the connection menu, enter
>q
and press Enter. Now, having received the fsmo maintenance: prompt again, we can proceed with the transfer of roles. This is what the transfer command is for:
>transfer<имя_роли>
As<имя_роли>you need to specify the role you want to transfer:

• naming master - transferring the role of the owner of domain names;
• infrastructure master - transfer of the infrastructure master role;
• RID master - transfer of the RID master role;
• schema master - transferring the schema master role;
• PDC - transfer the role of the PDC emulator.

In versions of Windows prior to Windows Server 2008R2, the domain naming master is called the domain naming master. As is customary in Windows systems, case does not matter.

After entering each transfer command, a dialog box appears asking for confirmation (you could also ask for confirmation in the console, otherwise it’s “non-console” as it turns out), press “OK” each time, unless of course you typed all the previous commands by accident. :)
To exit Ntdsutil, type the q command and press Enter.

Forcing fsmo roles with Ntdsutil

But what do we do if the role owner is unavailable, damaged and there is no hope of returning it to service in the near future? And here ntdsutil.exe will help us again:
Forced assignment (capture) of roles is performed only in case of a complete failure of the server, with the impossibility of its recovery. If possible, it is best to bring the failed FSMO master back online. The capture procedure itself is similar to that described above. We go to the domain controller to which we want to transfer roles and do the same as was written in the previous paragraph by typing:
>ntdsutil
>roles
>connections
>connect to server<имя_сервера>
>q
The only difference is that instead of the transfer command, the command is used to force the seizure of the role. seize
>seize<имя_роли>
Where<имя_роли>as before

• naming master - domain name master (before Windows Server 2008R2 - domain naming master);
• infrastructure master - infrastructure master;
• rid master - RID master;
• schema master - schema master;
• pdc is a PDC emulator.

Remember to try to transfer the role using the transfer command before seizing the role, and only if it fails, use seize.

If possible, do not assign the Infrastructure Master role to a domain controller that is a global catalog server, because then it will not update object information. The reason for this behavior is that the global catalog server maintains partial replicas of all objects in the forest.

Under no circumstances should a domain controller that previously performed FSMO roles be brought back into service if the roles it occupied were seized by the seize command. when it appears on the network, a conflict will arise, which can cause big trouble. It must be removed from Active Directory. On Windows Server 2008 and older, this can be done by simply deleting the server object in the Active Directory Users and Computers snap-in, and on Windows Server 2003 using the Ntdsutil program using the ntdsutil -metadata cleanup command.

The second option - Voluntary transfer of FSMO roles using Active Directory management snap-ins, is strange and inconvenient, but this is just my subjective opinion, the method itself works great.

You can transfer domain-level roles (RID Master, PDC Emulator, and Infrastructure Master) using the Active Directory Users and Computers snap-in. To do this, go to the domain controller to which we want to transfer roles, launch the snap-in and click right key click on the desired domain, select the item "Masters of Operations".

In the window that opens, select the role we need and click the "Change" button. Then we confirm the transfer of the role and look at the result. The name of the host of operations should change to the name of the current server.

To migrate the Domain Naming Master role, you will need the Domains and Trust Active Directory snap-in. We launch the snap-in, if necessary, connect to the desired domain controller, right-click in the root of the snap-in and select the "Operations Master" menu item.

A window opens in which you need to click the "Change" button, and then confirm the changes in the same way as in the previous case.

To transfer the Schema Master role, you will have to do some more complex manipulations. First, you must register the Active Directory Schema Management Library on the system. This can be done with the command
> regsvr32 schmmgmt.dll

Then open the MMC console and add the Active Directory Schema snap-in to it.

Now you can go to the snap-in and change the owner of the Schema Master role, as in the previous examples, by right-clicking on the schema and selecting the "Operations master ..." item.

Hooray! All roles have been transferred. And again, never leave your domain without assigned FSMO role masters. Never! :)

• Back

Comments

New articles:

• Network discovery does not turn on in Windows 7/8/2008/2012

  The essence of the problem is that the user in the Windows 7 system does not turn on network discovery in the network settings. More precisely, it turns on, but if you close it and ...

• Error: This application failed to start because it could not find or load the Qt platform plugin "windows".

  So, after installing by directly copying the application written in C ++ using the Qt library, we get the following error: This application failed to start...

hb860 November 25, 2011 at 02:02 pm

Everything You Wanted to Know About Operations Masters but Were Afraid to Ask

• System administration

Most system administrators in their corporate environment to provide a system for identifying and accessing their users to resources, enterprises use domain Active services Directory, which can be safely called the heart of the entire enterprise infrastructure. As many of you know, the structure of Domain Services in organizations can include either single or multiple forests (a set of domains that include a network configuration description and a single directory instance), depending on factors such as scope constraints. trusting relationship, complete separation of network data, obtaining administrative isolation. In turn, each large forest should be divided into domains to simplify administration and data replication. In each domain to manage domain services and perform tasks such as authentication, service startup "Kerberos Key Distribution Center" and access control are used by domain controllers. And for management network traffic websites are being developed between offices.
All information about forests, domains, and sites, of course, must be consistent even when designing AD DS, according to such corporate requirements as: business requirements, functional requirements, legal, security requirements, as well as design restrictions on documentation. Often, all these points are carefully planned by the IT department of the company itself or by the enterprise infrastructure project team before the deployment of domain services and written into a special service level agreement that determines the expected level of performance and quality of the service provided.
Information obtained after design or, more often, after the deployment of AD DS should be carefully documented. Such documentation should include information about the logical and physical structure of Domain Services itself, administrative models, name resolution infrastructure, any planned changes to the organization's environment, and additional infrastructure components such as the introduction of mail servers. Microsoft Exchange, System Center servers, and more. In most cases, the organization's IT staff ignores the documentation process, and when IT staff changes, it can take some time for new administrators to fully orient themselves with the organization's current infrastructure.
You also need to understand that in the directory service, almost all domain controllers are equal (in this context, we do not take into account read-only domain controllers, RODCs), that is, all domain controllers have the right to write to the database and can replicate this data to others controllers. This topology handles most of the trivial Active Directory operations just fine and is called multi-peer replication(Multimaster). But, nevertheless, there are some operations that must be performed on an authorized server designated directly for such operations. In other words, domain controllers that perform certain operations or roles in their domain are called operations masters (or masters). Knowing and understanding the purpose of all roles of operations masters is necessary, because in the case of disaster recovery, upgrades or migrations, it is the domain controllers that act as masters of operations that can play one of the most important roles. Accordingly, it is about the masters of operations that will be discussed in this article.
From this article you will learn:

• About what would happen if there were no masters of operations;
• About forest level operations master roles;
• About the roles of domain-level operations masters;
• How you can determine which controller has the FSMO role;
• About captures and transfer of roles of masters of operations;
• About the correct placement of operations masters on domain controllers.

• Planning and Documenting Domain Controllers with Operations Master Roles. This is a separate topic that includes understanding the nuances of AD DS planning and is outside the scope of this article;
• Global catalog servers. Many system administrators equate global catalog servers with operations master roles. Actually, this is a false assertion. The global catalog is a distributed data repository that stores information about each object and allows users and applications to find objects in any domain in the current forest by looking up attributes included in the global catalog that are identified in the schema as a private set of attributes. The global catalog itself resides on domain controllers designated as global catalog servers and is in turn replicated through Multimaster replication. Although the global catalog contains full list all objects in the forest, and global catalog servers can respond to all requests without having to refer to other domain controllers, the global catalog is not a role of operations masters. For global catalog servers, you can read the following article: "Global Catalog Servers" ;
• Interaction of Operations Wizards with Read-Only Domain Controllers. Read Only Domain Controllers are a special, relatively new type domain controllers, which it is advisable to deploy in the branches of the organization that are not provided with an adequate level of security and qualified IT personnel. As with scheduling operations wizards and global catalog servers, read-only domain controllers are a separate, large topic that does not make any sense to cover in this article. The first thing to note, though, is that RODCs cannot act as a domain controller with an operations master role;
• Troubleshooting and Errors with Operations Wizards. An interesting and rather voluminous topic, which will not be considered, due to the fact that the current article deals with the general concepts of the roles of operations masters.

What would happen if there were no masters of operations

• Lightweight Directory Access Protocol (LDAP);
• SMTP.

Roles of Forest-Level Operations Wizards

• Schema Master;
• Domain Name Wizard

Schema Master Role

The Role of the Domain Name Master

• Adding and removing domains. When performing such an operation as adding or removing a child domain using the Active Directory Setup Wizard or a command line utility, the Setup Wizard refers to the Domain Naming Wizard and requests the right to add or, accordingly, delete the latter. The Domain Naming Wizard is also responsible for ensuring that domains in a forest have unique NETBIOS names within the entire forest. Naturally, for obvious reasons, if the Domain Naming Wizard is not available, you will not be able to add or remove domains in the forest;
• Adding and Removing Cross References. As you already know, when you create the first domain controller in the forest, schema, configuration, and domain directory partitions are created in the forest. At this time, for each directory partition in the Partitions container of the configuration partition (CN=partitions,CN=configuration,DC=forestRootDomain), a cross-reference object (crossRef class) is created. The cross-reference object defines the name and location of the servers that store each directory partition in the forest. When creating each subsequent domain or application directory partition, the creation of a cross-reference object in the Partitions container is initiated.
• Adding and Removing Application Directory Partitions. Application directory partitions are special partitions that you can create on Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 domain controllers to provide dynamic LDAP application data storage. If your forest works on Windows level Server 2000, then in such a forest, all non-domain data is limited to configuration and schema data, which is replicated to all domain controllers in the forest. In a Windows Server 2003/2008 and 2008R2 forest, application directory partitions store domain controller-specific application data that can be replayed on any domain controller in the forest.
• Confirmation of domain rename instructions. The last action performed by the Domain Name Wizard is to validate the domain rename instructions. It is customary to rename domains using a special command line utility. So, when using the Rendom.exe utility, which is designed to rename domains, in order to rename a domain, the utility must have access to the domain naming wizard. In addition to the above capabilities, the domain naming wizard is also responsible for validating domain rename instructions. When this tool is run, on a domain controller with the Domain Naming Wizard role, an XML script is written to the msDS-UpdateScript attribute of the Partitions (CN=partitions,CN=configuration,DC=forestRootDomain) container object of the Configuration directory partition that contains instructions for renaming domains. It's worth remembering that the Partitions container can only be upgraded on a domain controller that holds the Domain Name Master role. In addition to the value of the msDS-UpdateScript attribute, the Rendom.exe utility writes the new DNS name of each renamed domain to the msDS-DnsRootAlias ​​attribute of the cross-reference object (crossRef class) corresponding to that domain. Again, because the cross-reference object is stored in the Partitrions container, this object can only be updated on a domain controller with the domain naming master role. Changed msDS-UpdateScript and msDS-DnsRootAlias ​​attribute data is replicated to all domain controllers in the forest.

Roles of Domain-Level Operations Wizards

• Relative RID Wizard
• PDC Primary Domain Controller Emulator
• Infrastructure Master

Master RID

PDC emulator

• Participation in domain password update replication. When a user's password is changed or reset, the domain controller making the change replicates the change to the PDC emulator via urgent replication. This replication ensures that domain controllers quickly learn the changed password. In the event that a user tries to log on immediately after changing the password, the domain controller responding to this request may not yet know New password. Before denying a logon attempt, this domain controller sends an authentication request to the PDC emulator, which verifies that the new password is correct and instructs the domain controller to accept the logon request. This means that every time a user enters an incorrect password, authentication is sent to the PDC emulator for a final decision;
• Manage Group Policy Updates in a Domain. As you know, Group Policies are used to control most of the settings in the configuration of computers and users in your organization. In the event that a GPO is modified on two domain controllers at approximately the same time, then later conflicts between the two versions may occur that are not resolved when GPOs are replicated. To avoid such conflicts, the PDC emulator operates as follows: when a GPO is opened, the Group Policy Management Editor snap-in binds to the domain controller acting as the PDC, and all changes to the default GPOs are made to the PDC emulator;
• Acting as a Domain Central Browser. Clients use Active Directory to discover network resources. When opening a window "Net" the operating system displays a list of workgroups and domains. After the user opens the specified working group or domain he will be able to see the list of computers. These lists are generated by a browser service, and on each network segment, the master browser creates a browse list with the workgroups, domains, and servers of that segment. The central browser then aggregates the lists of all the leading browsers so that the client machines can view the entire browsing list. I think that of all the functions of the PDC emulator, you may have questions related directly to the central browser of the domain, therefore, this topic will be discussed in detail in a separate article;
• Securing a master domain time source. Since Active Directory, Kerberos, DFS-R, and the FRS file replication service use time stamps, time synchronization is required on all domain systems. The PDC emulator in the forest root domain serves as the lead time source for the entire forest. The rest of the domain controllers synchronize time with the PDC emulator, and the client computers synchronize with their domain controllers. The hierarchical synchronization service, which is implemented in the Win32Time service, is responsible for time consistency.

Infrastructure Master

How can I determine which domain controller has the FSMO role

Defining Operations Master Role Holders Using the GUI

Determining Operations Master Role Owners Using the Command Line

Rice. 6. Determination of FSMO roles using the Dcdiag utility

Capturing and Transferring Operations Master Roles

1. open command line and in it go to the utility ntdsutil;
2. Navigate to NTDS role management using the command roles;
3. You need to establish a connection to a domain controller that will act as the owner of the operations master in the future. To do this, run the command connections;
4. In line server connections enter connect to server and specify the required domain controller;
5. Navigate back to fsmo management using the command quit;
6. Now in line fsmo management specify command seize and click on Enter;
7. In this last step, you need to select the FSMO role that will be captured from the idle domain controller.

1. Physically disconnect such a domain controller from the network;
2. Demote a domain controller to a member server using the command Dcpromo /forceremoval;
3. Clear metadata for the current domain controller. You can clean metadata using the utility Ntdsutil with the team Metadata Cleanup;
4. After removing the metadata, you need to bring the server online, join the domain, and then promote the server to a domain controller;
5. In the last step, simply transfer the role to this domain controller.

Placing Operations Wizards on Domain Controllers

• Place the RID master and PDC emulator roles on the same domain controller. These operations master roles are co-located for load balancing considerations. Since these roles are direct replication partners, by placing these roles on separate domain controllers, you will have to establish a fast connection for the respective two systems and create explicit objects for them in Active Directory. In addition, if you have servers in your organization that play the role of backup masters of operations, on such servers these roles must also be direct partners;
• Host schema and domain naming master roles on the same domain controller. Generally, it is recommended that the schema master and domain naming master roles be hosted on the same domain controller that serves as the global catalog server. The domain naming wizard role must also be a global catalog server because when adding a new domain, the wizard must ensure that there is no object in the forest with the same name as the newly added domain. However, if a domain controller with the Domain Naming Wizard role is not a global catalog server, operations such as creating grandchild domains may fail. Because these roles are the least used, you should ensure that the domain controller that manages them is as secure as possible;
• The Infrastructure Master role must be hosted on a domain controller that is not serving as a global catalog server. Typically, the Infrastructure Wizard should be deployed on a domain controller that is not serving as a global catalog server, but has an object direct connection to one of the global catalogs in the forest. Because the global catalog server stores partial replicas of all objects in the forest, the infrastructure master hosted on the global catalog server will not perform updates because it does not contain references to objects that it does not store.

Instead of a conclusion