Note<\/h2>\n
This is a super long post! It began as notes to the TechNet\/ MSDN posts but it quickly grew into more. Lots of additional stuff and examples from my side\/ other blog posts. Perhaps I should have split these into separate posts but I didn’t feel like it.<\/p>\n<\/div>\n
What is the AD Replication Model?<\/h2>\n
(source<\/a>)<\/p>\n Before the next post it’s worth going into Linked attributes and Multivalued attributes.<\/p>\n (source<\/a>)<\/p>\n A must read post if you are interested in the details!\u00a0<\/p>\n LDAP\/ AD supports the following four types of update requests<\/span>:<\/p>\n Each of the above update requests generates a separate write transaction (because remember, all updates to a single object happen in a single transaction).\u00a0Updates are an all-or-nothing event. If multiple attributes of an object are updated, and even one of those\u00a0updates fail\u00a0when writing to the database, all attributes fail<\/em> and are not updated.\u00a0<\/p>\n Once an update request is committed to the database it is called an originating update<\/span>. When a DC receives an originating update, writes it to its database, and sends out updates to other DCs these are called replication updates<\/span>. There is no one-to-one relation between originating updates and replication updates. For instance, a DC could receive multiple originating updates to an object – possible even from different DCs – and then send a replication update with the new state of that object. (Remember: AD is state-based, not log-based. It is the state that matters, not the steps taken to reach that state).\u00a0<\/p>\n Certain objects are protected from deletion:<\/p>\n A better way to structure the above query then would be to also filter out objects whose AD does not depend on timestamps to resolve conflicts. In case of conflicts the “volatility” of changes is what primarily matters. That is, if an attribute was updated twice on one DC and thrice on another DC, even if the timestamps of changes from the first DC are later than the second DC, the change from the second DC will win because the attribute was updated thrice there. More on this in my next post<\/a>.\u00a0<\/p>\n I mentioned above that each DSA has its own The AD database ( The The (I was planning on covering this separately as part of my AD Troubleshooting WorkshopPLUS posts, but USNs are mentioned\u00a0in this TechNet post so I might as well cover them now).\u00a0<\/p>\n USNs are\u00a064-bit counters\u00a0maintained on each<\/span> DC. The number is\u00a0different<\/em> for each DC and is stored in the\u00a0\n
\n
Linked & Multivalued attributes<\/h2>\n
\n
memberOf<\/code>. You can’t see this by default in ADUC in the “Attribute Editor” tab. But if you click “Filter” and select to show “Backlinks” too then you can view this attribute. ![\"backlinks\"](\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/backlinks.png?resize=551%2C666&ssl=1\")
<\/a> The memberOf<\/code> attribute is an example of a back link. And it’s generated by AD, which is why it’s a read-only attribute. It’s counterpart, the forward link, is the member<\/code> attribute of a group object. Linked attributes are linked together in the schema. In the schema definitions of those attributes – which are instances of an attributeSchema<\/code> class – there is a linkID<\/code> attribute that defines the back and forward links. The attribute with an even linkID<\/code> is the forward link (the write-able attribute that we can set) while the attribute with a linkID<\/code> that’s one more than the linkID<\/code> of the forward link is the back link (the read-only, AD generated attribute). For instance, using ADSI Edit I found the CN=Member,CN=Schema,CN=Configuration,DC=mydomain<\/code> object in the Schema partition. This is the schema definition of the member<\/code> attribute. Being a forward link it has an even linkID<\/code>. ![\"linkid\"](\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/linkid.png?resize=660%2C159&ssl=1\")
<\/a> Its counterpart can be easily found\u00a0using ldp.exe<\/code>. Search the Schema partition for all objects with linkID<\/code> of 3. ![\"linkid-2\"](\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/linkid-2.png?resize=660%2C235&ssl=1\")
<\/a> The result is CN=Is-Member-Of-DL,CN=Schema,CN=Configuration,DC=mydomain<\/code>, which is the attributeSchema<\/code> object defining the memberOf<\/code> attribute (notice the lDAPDisplayName<\/code> attribute of this object in the above screenshot).\n\n
whenChanged<\/code>\u00a0attribute<\/a> that gets changed and it is the change to the group that is replicated throughout the domain. The user object has no change and nothing regarding it is replicated. Obvious again, because the change really happens on the group and the effect we see on the user\/ group is what AD calculates and shows us.\u00a0<\/li>\n<\/ul>\n<\/li>\nmember<\/code> and memberOf<\/code> attributes mentioned above are also multivalued attributes. Obvious, because a group can contain multiple members, and a user\/ group can be a member of multiple groups. Multivalued attributes can be identified by an attribute isSingleValued<\/code><\/a> in their attributeSchema<\/code> definition. If this value is TRUE<\/code> it’s a single valued attribute, else its a multivalued attribute.<\/li>\n<\/ul>\nHow the AD Replication Model Works<\/h2>\n
On replication<\/h3>\n
\n
\n
\n
\n
ASN.1<\/code> (Abstract Syntax Notation One) BER (Basic Encoding Rules). Check out Wikipedia<\/a> and this post<\/a>\u00a0for more information on ASN.1<\/code> BER (note: ASN.1<\/code> defines the syntax; BER defines the encoding. There are many other encodings<\/a> such as CER, DER, XER but BER is what LDAP uses). See this blog post<\/a> for an example LDAP message (scroll down to the end).\u00a0<\/li>\n<\/ul>\n<\/li>\n\n
\n
member<\/code> attribute from the examples above) the update may not happen in the same transaction. In such cases the values are still guaranteed to be written in the same replication cycle (i.e. all updates from the source DC to that object will be written\u00a0before <\/em>the DC performs another replication cycle). (This exception for multivalued attributes is from Server 2003 and above domains, I think).<\/li>\n<\/ul>\n<\/li>\n\n
member<\/code>\u00a0(referring to the members of a group) had 300 entries and now an additional entry was added, all 301 entries were replicated rather than just the new entry.\u00a0<\/li>\nmember<\/code> attribute. Since that is larger than the number of values that can be committed in a single transaction, it would fail. Hence the maximum number of members in a group in a Windows 2000 forest functional level domain was 5000.\u00a0<\/li>\n<\/ul>\n<\/li>\n\n
attributeSchema<\/code>. \u00a0The\u00a0AD schema is what defines attributes and the relations between them.\n\n
Architecture<\/h3>\n
\n
ntdsa.dll<\/code>.\u00a0\n\n
wldap32.dll<\/code>\u00a0component \u00a0(am not very clear about this bit). LDAPv3<\/a> is used.\u00a0<\/li>\n<\/ul>\n<\/li>\n\n
ntdsapi.dll<\/code>\u00a0which\u00a0lets them communicate<\/em> with DCs\u00a0over RPC<\/span>.\n\n
repadmin.exe<\/code> or AD Sites and Services (dssites.msc<\/code>) use to communicate with the DC (even if these tools are running on the DC).\u00a0<\/li>\n<\/ul>\n<\/li>\nntdsapi.dll<\/code>\u00a0which lets them replicate<\/em> with other DCs over RPC<\/span>. (I infer<\/em> the word “private” here to mean it’s meant only for DCs).\n\n
ntdsapi.dll<\/code> component is not used. Other components, such as\u00a0ISMServ.exe<\/code> and the CDO library are used in that case. Remember: this is only for non-domain updates.\u00a0<\/li>\n<\/ul>\n<\/li>\ndrsuapi<\/code>. It provides the functions<\/a>\u00a0(also see this link<\/a>) for replication and management. Check this section<\/a> of the TechNet post for an architecture diagram and description of the components.\u00a0\n\n
DRS.idl<\/code>. This is a file<\/a> that contains the interface and type library definitions.\u00a0<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n
ntds.dit<\/code>\u00a0(DIT == Directory Information Tree; see this link<\/a> for more info). The database engine is Extensible Storage Engine (ESE<\/a>; esent.dll<\/code>)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nCharacteristics of AD replication<\/h3>\n
\n
\n
\n
\n
\n
Updates<\/h3>\n
\n
Adding request:<\/h4>\n
\n
objectGUID<\/code> attribute. Values of all replicated attributes are set to Version<\/code> = 1. (The Version<\/code> attribute will be discussed later, below).\u00a0<\/li>\nModify request:<\/h4>\n
\n
NULL<\/code> and Version<\/code> is incremented.\u00a0<\/li>\nVersion<\/code>\u00a0is incremented.\u00a0The\u00a0Modify request compares the existing and new values. If there are no changes then nothing happens – the request is ignored, the Version<\/code> does not change.\u00a0<\/li>\n<\/ul>\nMove request:<\/h4>\n
\n
name<\/code> attribute is changed.\u00a0<\/li>\n<\/ul>\nDelete request:<\/h4>\n
\n
isDeleted<\/code> attribute is set to TRUE<\/code>. This marks the object as tombstoned (i.e. deleted but not removed from AD).\u00a0<\/li>\nDN<\/code> of the object\u00a0is set to a value that cannot be set by an LDAP application (i.e. an impossible value).\u00a0<\/li>\n\n
crossRef<\/code>) and RID Object for the DC. Any delete request for these objects are rejected. And any originating update deletion of these objects is rejected, and all attributes of the object are updated (Version<\/code> incremented) so the object replicates to other DCs and is reanimated wherever it was deleted.\u00a0\u00a0\n\n
CN=Partitions,CN=Configuration,DC=(domain)<\/code><\/li>\nCN=RID Set,CN=(DC),OU=Domain Controllers,DC=(domain)<\/code><\/li>\n<\/ul>\n<\/li>\nnTDSDSA<\/code>) object.\n\n
CN=NTDS Settings,CN=(DC),CN=Servers,CN=(SITE),CN=Sites,CN=Configuration,DC=(domain)<\/code><\/li>\nDSAGUID._msdcs.domain<\/code> is a CNAME to the DC name).<\/li>\nobjectGUID<\/code> of the DC object is not the same as the objectGUID<\/code> of its DSA object. The latter is what matters. When a DC computer object is opened in ADUC, it is possible to view the corresponding DSA object by clicking on the “NTDS Settings” button in the first tab.\u00a0<\/li>\nnTDSDSA<\/code>. Below query, for instance, finds all objects of that class and returns their DN<\/code> and objectGUID<\/code>.\u00a0\n![\"nTDSDSA\"](\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/nTDSDSA.png?resize=339%2C201&ssl=1\")
<\/a><\/p>\n<\/li>\nisDeleted<\/code> attribute is not TRUE<\/code>.<\/p>\n![\"nTDSDSA-2\"](\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/nTDSDSA-2.png?resize=339%2C201&ssl=1\")
<\/a><\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nConflicts<\/h3>\n
Database GUID<\/h3>\n
objectGUID<\/code>. This GUID is created with the server is promoted to a DC and deleted (sort of) when the DC is demoted. Thus the GUID is present for the lifetime of the DC and doesn’t change even if the DC name changes.\u00a0<\/p>\nntds.dit<\/code>) on each DC has its own GUID. This GUID is stored in the invocationId<\/code> attribute of the DSA. Unlike the DSA GUID, the database GUID can change. This happens when (1) the DC is demoted and re-promoted (so the database changes), (2) when an application NC is added\/ removed to the DC, (3) when the DC\/ database is restored from a backup<\/a>, or (4) (only in Server 2012 and above) whenever a\u00a0DC running in a\u00a0VM is snapshotted or copied<\/a>.<\/p>\ninvocationId<\/code> attribute can be viewed via ldp.exe<\/code> as above, or in the “NTDS Settings” of the DC computer object in AD\u00a0Users & Computers, or in the “NTDS Settings” in AD Sites & Services. It can also be viewed in the output of repadmin.exe<\/code>.<\/p>\nC:\\Windows\\system32>repadmin \/showreps | more\nKOTTAYAM\\WIN-DC02\nDSA Options: IS_GC\nSite Options: (none)\nDSA object GUID: 6fdae042-053c-47e2-be5f-67db18dfc088\nDSA invocationID: 2ba93522-4caf-4130-b946-b4069081c137\n\n==== INBOUND NEIGHBORS ======================================\n\nDC=rakhesh,DC=local\n COCHIN\\WIN-DC03 via RPC\n DSA object GUID: 33398129-7632-4014-a3b4-eabb2b74de8b\n Last attempt @ 2015-01-07 22:39:38 was successful.<\/pre>\n
invocationID<\/code> is a part of replication requests (more later). When the invocationID<\/code> changes other know that they have to replicate changes to this DC so it can catch up. The first DC in a domain will have its invocationID<\/code> and objectGUID<\/code> as same (until the invocationID<\/code> changes). All other DCs will have different values for these both.\u00a0<\/p>\nUpdate Sequence Numbers (USNs)<\/h3>\n
highestCommittedUsn<\/code>\u00a0attribute of the rootDSE<\/code> object.<\/p>\n