0

We have a problem with one of our AD: Creating a new object will instead delete another object.

In one of the DC, we have this message logged:

"There are two or more objects that have the same SID attribute in the SAM database"

This AD was recently cloned during a site migration: we cloned the original AD (all machines) into the new one and ran it in parallel while running tests (these two AD aren't actually connected in any way). We performed incremental update of the file server data (using a "bridge" machine on the new infrastructure that is the only one that can connect to both locations, is not a DC and can't connect to the DC on the old infrastructure).

Now, we had this happened twice: creating a new object (any object: user, group, computer account, etc.) results in the object being created with the same SID as an existing object, at wich point both objects are immediately being deleted. We found that out because a newly created file server was suddently deleted from the domain when we attempted to create a new user account (we had to re-add it to the domain)

Now, we have tried to invalidate the RID pool on both DCs but that did not seem to solve the issue.

We exported all SIDs from the AD and found the higest one: S-1-5-21-XXXXXX-XXX-XXXXX-7601

Then we checked our DCs using Dcdiag.exe /TEST:RidManager /v and, on the RID master, we had this:

    * rIDAllocationPool is 7600 to 8099
     The DS has corrupt data: rIDPreviousAllocationPool value is not valid
     * rIDPreviousAllocationPool is 0 to 0
     * rIDNextRID: 0
     No rids allocated -- please check eventlog.

So: first, we have the The DS has corrupt data: rIDPreviousAllocationPool value is not valid message. I can't tell if it's because we haven't allocated a new object since the RID has been reset or if it's a real error. What's certain is that there is no error in the event log, only the informational message about the RID pool being invalidated.

Second, the rIDAllocationPool does start at 7600 which hints at the fact that the next object to be created will most likely use RID 7600 which is inferior to the currently higher 7601 SID, potentially leading to a deletion problem (and since the object with RID 7601 is the file server that we had to re-add it to the AD, it will cause many issues).

So: beside the fact that I have no idea how we could have ended up with such a problem since we never restired the AD to a previous state, how can I fix it ?

  • Did you follow the Microsoft guidance for cloning a Domain Controller? If not, I wouldn't bother trying to fix it. - docs.microsoft.com/en-us/windows-server/identity/ad-ds/… – joeqwerty Aug 7 at 12:55
  • @joeqwerty No because that document does not describe the operation we performed: although a clone of each VM was indeed taken, that was at the VM level, not the AD. The resulting infrastructure never had a connection to the exiting one: it was as if we shut it all down and the powered it up again. – Stephane Aug 7 at 13:02
  • 1
    Best to scrap it anyway and create a new separate forest for testing whatever it is you want to test. – Semicolon Aug 7 at 15:25
0

We have fixed the issue but not found the root cause. Many thanks to the folks that tried to help.

The root cause of the issue was that one AD server had an invalid RID pool. We attempted to fix it by invalidating the RID pool on that machine but we made two critical mistakes when doing the fix: first, we invalidated the the pool on wrong server. When we realized this, we made the second mistake of invalidating the pool on the other system, causing all pool information to be lost on both machine.

To fix the issue, we did the following:

  • Cloned the RID master to a separate, isolated VM. In restroscpect, we could have just taken the other AD server out of the network or shut it down and performed the whole operation on the exitsing server.
  • Invalidated the RID pool.
  • Used ndsutil to force-seize the RID master role on that same machine. That restored the RID pool information.
  • Shut down the original RID master, replaced it with the clone and powered it up again.
  • Once the domain was back up and running (and syncronizing), re invalidated the RID pool on the second AD server.
  • Rebooted that second server. That caused the pool to refresh on the server and be valid again.

The idea was that the RID information in AD would be recreated when the RID master role was transfered. Since the domain RID infomations was correct and only the server local pools were lost, we wanted to force pool to be recreated, starting with the RID master.

Since the RID pool information is re-created when the RID master role is transfered, we wanted to force that operation. We also wanted to make sure that this operation was done on the current RID master since we knew it would be able to access the data objects even if the pool was invalid.

So, we needed a way to force-seize the role on the current RID master. That was done by isolating it from the other AD server (doing it on a cloned system was just giving us some security). Once the RID master was up and running again, the rest was just plumbing.

Both servers are now up and running again with valid ID pools. We lost about 1000 RIDs in the process (because the ranged used by each server had to be abandonned) but that's a small price to pay.

We will rebuild two new AD servers when we have some tme and drop these two in order to be sure there is no lingering issue here.

We had MS assist us on this case but they didn't actually help: the tech told us that the AD was toast and that we needed to restore a backup. Then when we brought everything back up, he told us he has no idea why it worked.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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