A flaw in Active Directory?

By Dave Kearns
Network World, 08/16/99

In Network World Fusion's "Windows NT" newsletter I've been taking a close look at Active Directory as it is implemented in Windows 2000. In the August 2 newsletter, I outlined the Active Directory replication and synchronization strategy. But the more I think about it, the more afraid I become.

Active Directory uses multimaster replication. No more Primary Domain Controllers (PDC) and Backup Domain Controllers (BDC) - all Domain Controllers are equal peers. Objects can be manipulated on any Domain Controller, and the changes are then propagated to the remaining domain controllers. While this is easier on the administrator than the PDC-BDC mode of NT 4 (where all changes had to be made on the PDC), it means that there needs to be a way to reconcile changes which might be made to the same object on different Domain Controllers.

There is no time synchronization among the Domain Controllers, so changes based on time stamps won't work. Instead, a concept called the Update Sequence Number (USN) is used. Each Domain Controller holds a table containing entries for its own USN and the USNs of its replication partners. During replication, the Domain Controller compares the last known USN of its replication partner (saved in the table) with the current USN that the replication partner provides. If there have been recent changes (that is, if the replication partner provides a higher USN), the data store requests all changes from the replication partner. After receiving the data, the directory store sets the USN to the same value as that of the replication partner. This only guarantees that all changes made on a single Domain Controller will be propagated in the correct order.

If properties on the same object are changed from different domain controllers, a series of comparisons must be made by Active Directory to decide which is the correct order of changes.

The first decider is the version number. All properties carry a version number that is incremented with each change, and the higher version always takes precedent. But if I make two changes to an object on one Domain Controller (+2 to the version number), then make a change to the same object on another Domain Controller (+1 to the version number) before the first changes are propagated, my second change - not the third one, which would be correct - is the one accepted as final.

If the version numbers on the changed object are the same, then the timestamps on the changes are used. But because there is no time synchronization between Domain Controllers, this could lead to wrong information being propagated.

If both version number and timestamp are the same, Active Directory performs a binary memory copy operation and compares the buffer size. The higher buffer size wins. If the two buffers are equal, the data is the same, and one can be discarded. If they're not the same, though, there's nothing to guarantee that the correct information is chosen - just the one with a bigger buffer size!

Because none of these methods guarantees that correct information is propagated, all possible changes are logged. You can peruse the logs, then make further changes to correct the errors - and hope that they get propagated correctly.