Overview of Windows Active Directory series---adds Replication (2)

How does AD DS handle replication conflicts?

Because AD DS supports multi-master replication mode, there may be replication conflicts that can occur, typically with three possible conflicts:

1. Modify the value of the same property on the same object at the same time on two different DCs

2. Add or modify an object on a DC, and at the same time on another DC the container where the object resides is deleted

3. A new object with the same associated distinguished name is added to the same container on a different DC, such as a new account added on DC1 and DC2, and a new Zhang Shan on the DC1, and DC2 on Zhang Shan, but their distinguished name DN is cn=zhangshan,cn= Users,dc=contoso,dc=com, so there will be a conflict problem.

To minimize the occurrence of the above conflicts, all DCs in the forest record and replicate those changed objects based on attributes or values, rather than objects. Therefore, it is not a conflict to change the two different properties of the object at the same time on different DCs, for example, on two different DCs, one changed the user's password and the other changed the ZIP code, in which case there will be no conflict problem. When an object on the DC has a change operation, the change is passed along with a signature to the other DC, and the signature contains the following components:

1. The version number. The version number of each object property starts at 1, and the version number is automatically added 1 each time the property is changed. When an object property is modified once, the existing version number is larger than the previous version number 1

2. Time stamp. The timestamp represents the time and date when the update originated, and it refers to the time of the system clock on the DC where the change occurred.

3. Server global Unique identifier. The server's globally unique identifier identifies the DC that originated the update, which is the source DC for the data change.

Let's look at how AD DS solves 3 of our above-mentioned conflicts.

1. Property value violation
   

   If the value of the version number is the same, but the object's property values are different, then the timestamp is evaluated. whose timestamp value is high, the change data will be applied, and if the timestamp is the same, then the server GUID will be used to determine whose GUID value is lower, and whose change data will be applied.

2. Updating data in a deleted container

   On all DCs, the container that performed the delete action is deleted, but changes to the objects in the container are saved in the LostAndFound container in the directory partition, which does not involve a comparison of the signatures.

3. The same related distinguished name is used when new objects are added. After referencing a property value violation, only one object will use the relevant distinguished name, and then adds will have the DC assign a unique correlation distinguished name to another object, the naming convention for the related distinguished name is the associated assignable name +cnf:+ * (a reserved character) + The GUID of the object. This naming convention guarantees that the newly generated name does not conflict with other object names.

How is the replication topology generated?

Replication topology refers to the routing of replicated data when it is passed through the network. To create a replication topology, AD DS must determine that the DC will replicate data with other DCs. AD DS creates a replication topology based on the information contained in AD DS, because each adds partition may be replicated to different DCs in the site, so the schema partition, configuration partition, domain partition, and application partition have different replication topologies.

Because all DCs in the forest share a single schema and configuration partition, adds replicates the schema partition and configuration partition to all DCs. DCs in the same domain use the same domain partition, and their application partitions are replicated between DCs that own the application partition. To optimize these replicated traffic, a DC may have multiple replication partners for different partitions. In a single-site environment, the replication topology has fault tolerance and redundancy, and if there are more than two DCs in the site, there will be at least two replication partners for each DC.

How schema partitions are replicated:

The replication process for the schema partition and the configuration partition is the same for the other partitions, but the two partitions are forest-wide, so there are connection objects on either of the two DCs that are used to replicate the two partitions, regardless of the domain to which the DCS belong. The more straightforward point is that all DCs in the forest are included in the replication topology for both partitions.

Impact of global Catalog (GC) on replication:

The configuration partition contains the site topology throughout the forest and global data for all domains, adds the configuration partition to the known DC through a normal forest-wide replication, each GC by connecting a DC in a domain, and then getting some of the property information for the objects in the domain from that DC. Each GC has full access to the domain partition in its own domain, so it does not need to request partial properties for objects in its own domain. The configuration partition also provides a list of GC servers in the forest to the DC, and the GC registers DNS records in the forest's root domain DNS zone, which are also registered only in the forest's root domain DNS zone, which is used to help clients and servers in the forest locate the GC server so that clients and servers can log on properly.

How is the RODC replicated?

As we mentioned earlier, the DC will replicate data by pulling the change data from other DCs, but the RODC is not allowed to write any unsolicited replication to its database, such as DC1 has data changes, but it does not notify the RODC that there is data change to be replicated. The RODC is not able to pull these change data from the DC1 to its own database, and the RODC does not replicate data to other DCs, which means that the RODC is a non-incoming replication. Because the RODC itself cannot change the data, other DCs do not need to pull the change data from the RODC. Restricting the ability of an RODC to write to a database prevents a malicious user or application from altering or tampering with the contents of the database and replicating the wrong data to other DCs in the forest through a normal replication process.

When a user or application attempts to perform a write request to the database on the RODC, a behavior in the following enumeration behavior is triggered:

1. The RODC forwards the write request to a writable DC, and then the writable DC copies the changed data to the RODC, such as password changes, SPN updates, changes to the properties of the computer or domain member.

2. The RODC responds to the client and provides a writable DC reference to the client, and the application can communicate directly with the writable DC. LDAP is an RODC reference.

3. The write operation failed because the RODC did not forward or provide a reference to a writable DC.

When you deploy a RODC,KCC it detects that the DC is configured with a read-only copy, so the KCC establishes a one-way connection object from one or more DCs because the RODC is a new feature introduced by Windows 2008 and later. So the operating system for these DCs must be a version of Windows 2008 or higher.

For some tasks, an RODC uses a single-object replication operation to perform incoming replication, which is not performed according to a standard replication schedule, and is a replication that is initiated on demand. These tasks include:

Password Change Request

When a client makes DNS updates through a writable DNS server referenced by the RODC, the RODC attempts to use a single-object copy operation to pull the updated DNS data into its own DNS, which only allows operations in an environment that uses an ad-integrated DNS zone.

Updates multiple client properties, including the computer name, DNS hostname, operating system name, operating system version information, the types of encryption that can be supported, and the most recent logon time properties.

How does the Sysvol folder for AD DS replicate?

SYSVOL is a collection of files and folders where each DC has this folder, which is connected to the%systemroot%\sysvol location of each DC. The SYSVOL contains logon scripts and Group Policy-related objects, such as Group Policy templates. The contents of the Sysvol folder are replicated to each DC within the domain, using the Connection object topology and the KCC's replication schedule.

The change in SYSVOL between DCs is dependent on the operating system version of the DC, the functional level of the domain, the migration state of the SYSVOL, or the way that FRS or DFS replication is determined, and how Windows server uses the primary FRS replication method.

In 2003R2 and older domain structures, FRS has limitations on both capacity and performance, so DFS Replication is introduced. In domains with a domain functional level of 2012R2, the DCs in 2012R2 no longer use FRS to replicate data. If the forest functional level is Windows Server 2008r2 or later, DFS Replication will be used. DFS Replication for Server 2012R2 has a new feature: DFS database cloning, but this feature cannot be used on the SYSVOL folder replication of AD, and SYSVOL replication must use DFS initial replication. (The forest functional level can be lower than the domain functional level, but the domain functional level must not be lower than the forest functional level, such as the forest is 2008r2 level, the domain can be more than 2008r2 level, but does not allow the level below 2008R2)

In Windows2008 and higher-level domains, you can use DFS Replication to replicate the contents of the Sysvol folder, DFS Replication supports scheduled replication and bandwidth control, and it can be combined with remote differential compression to replicate only incremental data in files when DFS Replication is performed. Reduced bandwidth usage during replication. If there is a change in the file in SYSVOL, DFS Replication automatically copies the location of the file changes to the Sysvol folder of the other DCs.

Note: You can use the Dfsrmig.exe tool to change the SYSVOL replication mode from FRS to DFS replication, but you must be able to migrate successfully if the domain functional level is at least Windows2008.

This article is from the "Dry Sea Sponge" blog, please be sure to keep this source http://thefallenheaven.blog.51cto.com/450907/1586035

Overview of Windows Active Directory series---adds Replication (2)