Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Supposed you have 2 domain controllers, DC1 and DC2.

For whatever reason, two different people go to create a new user account - one does it on DC1, the other on DC2.

Presumably, the two accounts now have the same username, but different SIDs.

What happens when the DC's try to synchronize the next time?

share|improve this question
3  
You do know that the solution is to use a ticketing system so that you don't have two techs trying to work the same request :-) –  mfinni Jan 21 '13 at 18:37
1  
We do...and it works 99% of the time. In this case someone was on site setting up their PC, couldn't log in, went to the local domain controller, didn't see the account, and thought it wasn't done yet. –  Grant Jan 21 '13 at 20:00

1 Answer 1

up vote 9 down vote accepted

You get a replication conflict.

One of the accounts will get to keep the desired name, and the other will be automatically renamed to something else to resolve the conflict.

This very example is actually used here, and the relevant parts are pasted below.

Consider the example of the jsmith user object in the contoso.com domain. An administrator on DC1 changes jsmith's description to "Marketing." Nearly simultaneously, an administrator on DC3 changes the same user's description to "Sales and Marketing." At this point, DC1's and DC3's information about jsmith's description attribute compare as shown in Figure 9.

enter image description here

If DC2 receives both of these changes simultaneously, it will clearly need to determine which one is the "winning" change. The order of tiebreakers for conflict resolution is as follows:

The modification that has the higher versionID will be accepted as the "winning" change; the "losing" change will be overwritten. In this case, the versionID is 2 for both records, so we need to move onto the second tiebreaker.

If both records have the same versionID, the change that has the later timestamp will be accepted as the winning change; the losing change will be overwritten. In this case, the timestamp from DC3's originating write is later, so jsmith's description will be set to "Sales and Marketing." In the rare instance when both the versionID and timestamp are identical, we need a third and definitive tiebreaker:

If both records have the same versionID and timestamp, whichever write was originated by the DC with the lower-numbered GUID will win; the write from the higher-numbered GUID will be overwritten. So if DC1's GUID is 1234567890 and DC3's GUID is 2345678901, the originating write from DC1 would win if both the versionID and timestamp were identical.

You are probably thinking, "Wouldn't it make more sense to have the timestamp be the first tie-breaker?" This isn't as cut-and-dried as you might think. If timestamp were the primary tie-breaker in Active Directory conflict resolution, the only thing that a malicious administrator would need to do to propagate his or her changes would be to set back the clock on one particular DC so that it would always win by way of timestamps.

Resolving Conflicting Object Creation

In cases where two objects are created with the same name, Active Directory will use the same three tie-breakers described in the previous section to determine which one is the "winning" object. Unlike the previous section, however, the "losing" object doesn't get overwritten. Instead, the losing object is renamed using the characters CNF (for conflict object), followed by a colon and the GUID of the "losing" object. This allows administrators to more methodically determine which object should be retained and which should be deleted.

share|improve this answer
    
Excellent, this is exactly the description I was searching for :) –  Grant Jan 21 '13 at 20:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.