다음을 통해 공유

Active Directory Replication Metadata

  • 아티클

Introduction

Replication Metadata is the data which captures all the change log of an object since its creation until deletion. In fact, we will be able to see an object’s metadata even after deletion, as long as the object is tombstoned in Active Directory (AD).

In this article, we will take a deep dive on Replication Metadata, how it functions, and how it can help us.

Facts regarding Replication Metadata

Commands

 
Microsoft offers two commands which we can use to capture replication metadata :

  1. Repadmin /showobjmeta : We can run this command from any Domain Controller, or where AD Module is installed.
  2. Get-ADReplicationAttributeMetadata: This is the PowerShell command which is available Windows Server 2012 onward.

Every object within Active Directory has replication Metadata. This includes users, computers, sites, subnets, groups, group policies and so on. If we use AD Integrated DNS, each DNS Record has Replication Metadata as well.

Information

Replication Metadata provides us below information about an object:

  1. When the object was created, and in which Domain Controller.
  2. Which attribute has been modified at what time, and from which Domain Controller.
  3. All the corresponding USN Numbers.

It is important to note that Replication Metadata does not provide any information on “who” made the change. It provides us with the information “what”, “When” and “Where” the change occurred, but not “Who” changed it. To know who changed the value of an attribute or deleted/created an object, we have to log in to appropriate Domain Controller where the change occurred, search for the events on that date-time (if the log is available) and get the information. Also, the event login should be enabled for that particular type of event. 

Replication

Replication Metadata is the factor that governs AD Replication. During an AD replication, Domain Controllers compare the USN number with its direct connection partners and replicate all metadata changes which happened since last replication.

Not all attributes replicated

One important point to keep in mind here is, not all attribute changes are replicated between Domain Controllers. Every attribute in Schema has a flag called “FLAG_ATTR_NOT_REPLICATED”. If this flag value is True (1), that attribute is not included in AD Replication. If the attribute value is false (0), then that attribute is replicated.

Only forward links attributes are replicated, not backward links. For example, for a user object, the “Member Of” attribute values are not replicated. All group’s “Members” attributes are replicated, and from there the “Members” tab of linked objects are automatically updated. That means backward links are updated automatically on every Domain Controllers, by calculating the corresponding forward links which have been replicated.

For this reason, when we will add a user to a group, we will not see any update in the user metadata. We should not be surprised because group addition is a backward link, which is not updated and replicated. If we check the metadata of the group where we added a user, we will see that the “Member” attribute has been updated.

Working with Replication Metadata

Now that we know what is Replication Metadata, and what it does, we will take a deeper dive and will do some hands on.

As we have mentioned before, there are two commands available to capture the metadata. In this article, we will use the PowerShell cmdlet “Get-ADReplicationAttributeMetadata”.

For the complete documentation of this cmdlet, please click here.

Case 1: Capturing Replication Metadata for User Object Modification

In this case, we will capture replication metadata of the user object “Subhro Majumder”. 

  • This object was created on 21-Jan-2018. 
  • On 10-Feb-2018, this user object has been added to the Group “Certificate Service DCOM Access”.
  • On the same date (10-Feb-2018), the home phone number attribute has been added for this user.

We will execute this command:

Get-ADReplicationAttributeMetadata "CN=Subhro Majumder,CN=Users,DC=subhro,DC=org" DC2 -IncludeDeletedObjects –ShowAllLinkedValues

This will show us the metadata of user object ‘Subhro Majumder”, and the information will be collected from the Domain Controller DC1. It will also capture deleted objects and display linked values since we have provided that options in our command.

If any attribute of this object has been changed very recently in any other Domain Controller which has not yet replicated to DC1, then that modification would not be captured.

We are unable to display the entire output here, as it is too large. However, below screenshot captures the change of attribute “homePhone” on 10-Feb-2018 on DC2.subhro.org. 

We also observe the USN value, associated with each change.

As mentioned earlier, we will not be able to see the metadata for group membership update because it is a backward link (Member Of). To see that, we have to capture the metadata of the group “Certificate Service DCOM Access”, where we have added the user object.

So we will execute this command: 

Get-ADReplicationAttributeMetadata "CN=Certificate Service DCOM Access,CN=Builtin,DC=subhro,DC=org" DC2 -IncludeDeletedObjects –ShowAllLinkedValues

As we can see here, the group metadata captures the inclusion of user object “Subhro Majumder” at 10-Feb-2018, and it also tells us that the activity has been performed on Domain Controller DC2.Subhro.Org.

So we have successfully found the metadata for Home Phone Number and Group Membership attributes update.

Case 2: Capturing Replication Metadata for DNS Record Modification

An important point to note here is, capturing replication metadata of a DNS Record is only possible when the DNS Zone is AD integrated.

In this case, we will update the host (A) record for “DC1.suburo.com”, by changing its IP address. Now, we will see the metadata for this record to track this IP address change.

First, we need to identify in which partition the record exists. As we know, an AD Integrated DNS zone can be stored in two partitions, 

  • DomainDNSZones: If the Zone is Domain-wide replicated.
  •  ForestDNSZones: If the Zone is Forest-wide replicated.

In this case, the DNS Zone “Subhro.Org” is replicated Domain-wide, so the Canonical Name of the record “DC1” would be: "DC=DC1,DC=subhro.org,CN=MicrosoftDNS,DC=DomainDnsZones,DC=subhro,DC=org"

 So we will execute this command : 

Get-ADReplicationAttributeMetadata "DC=DC1,DC=subhro.org,CN=MicrosoftDNS,DC=DomainDnsZones,DC=subhro,DC=org" DC2 -IncludeDeletedObjects -ShowAllLinkedValues

As we can see, it has captured the update of the attribute “dnsRecord” on 10-Feb-2018 at DC2.subhro.org.

Case 3: Capturing Replication Metadata for DNS Record Deletion

We will now capture the metadata of a DNS record which has been deleted. Please note that the deleted object must be within the tombstone lifetime, in order to capture the metadata.

We have deleted a DNS record “esx1” from the zone “subhro.com”.

We will now execute the below command to see the metadata of esx1:

Get-ADReplicationAttributeMetadata "DC=esx1,DC=subhro.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=subhro,DC=com" DC2 -IncludeDeletedObjects –ShowAllLinkedValues

We can see the DNS Record has been deleted (dNSTombstoned=True) on 10-Feb-2018 from DC.subhro.com. We can now go and check the event log on DC.Subhro.Com to see who deleted it, which is beyond the scope of this article.

Case 4: Capturing Replication Metadata for AD Sites and Subnets

We will now capture the Replication Metadata of an AD subnet 172.16.2.0/24. We have recently changed the AD site of this subnet, and we would like to check whether it reflects in the metadata.

We will execute this command:

Get-ADReplicationAttributeMetadata "CN=172.16.2.0/24,CN=subnets,CN=sites,CN=configuration,DC=subhro,dc=com" DC -IncludeDeletedObjects –ShowAllLinkedValues

As we can see, the “siteObject” attribute has been updated on 10-Feb-2018 on DC.subhro.com. We can also see that this is a linked attribute.

Now let’s check the metadata of the corresponding subnets, from where this subnet is removed and to where this subnet is attached.

The subnet was removed from the AD site “Kolkata” and was added to the AD site “Bangalore”.

  • To check the property of the AD site Bangalore, we will execute below command: Get-ADReplicationAttributeMetadata  "CN=Bangalore,CN=sites,CN=configuration,DC=subhro,dc=com" DC -IncludeDeletedObjects -ShowAllLinkedValues

  • To check the property of the AD site Kolkata, we will execute below command:

    Get-ADReplicationAttributeMetadata  "CN=Kolkata,CN=sites,CN=configuration,DC=subhro,dc=com" DC -IncludeDeletedObjects –ShowAllLinkedValues

However, we will not find the metadata for subnet addition/removal. Guess why? For AD sites, the linking of AD subnets are backward linking which would not be captured in metadata. It will be captured in AD subnet metadata, as for AD subnets, the AD site attribute is forward linking.

Summary

In this article, we have discussed Active Directory Metadata. We have captured Active Directory Metadata for User objects, DNS records, sites, and subnets.

We have also observed how forward and backward linkages work related to metadata and replication.

References