User accounts deleted when creating new security principals RRS feed

  • Question

  • A client of ours is having a very odd issue, where when they create a new security principal e.g. a group, user etc. - another user account / security principal in their AD gets deleted, and event 12293 is logged in the event log:-

    Event Type: Error
    Event Source: SAM
    Event Category: None
    Event ID: 12293
    Date:  2010/02/02
    Time:  09:01:32 PM
    User:  S-1-5-21-47084126-834209451-1542849698-3167
    Computer: MYDC02
    There are two or more objects that have the same SID attribute in the SAM database. The Distinguished Name of the account is CN=East London Staff,OU=Groups,DC=mydomain,DC=com. All duplicate  accounts have been deleted. Check the event log for additional duplicates.

    It seems almost like the RID "counter" has been set back to an old number, and the DC's are dishing out SID's for accounts that already exist.  AD then deletes both the new account and the old account to maintain integrity.

    Anyone seen this before?  The client's domain has 2 Windows 2003 SP2 32-bit Std. DC's.  They had to do a restore of AD last year sometime due to a virus that locked out ALL their domain accounts - I suspect the restore may have something to do with it. 


    Friday, February 12, 2010 3:25 PM


All replies

  • Ray,
    you should clean up using ntdsutil as described here
    Rofi Neron my blog:
    Friday, February 12, 2010 5:00 PM
  • Rofi, thanks - but I've already tried the first part of that article - to check for duplicate SID's, and none are found.  I don't think there are any duplicate SID's in AD currently - it's just that when you create a new object, a SID of an existing object is assigned, and AD then deletes both the new object and the conflicting (old) object.  So when the client creates any new objects, other random objects get deleted.  Scary.  We really need to sort this out.  I've asked them not to create any new users / groups or join any new PC's to the domain until we've gotten to the bottom of it.

    Saturday, February 13, 2010 7:54 PM
  • Identify the RID pool on each DC (refer to for details) - demote the ones which have incorrect ones...
    Demote RID master and seizing its role to a "healthy" DC...
    Re-promote the demoted DCs...

    • Marked as answer by Raymond Diack Tuesday, February 16, 2010 12:47 PM
    Sunday, February 14, 2010 11:42 PM
  • Hi Marcin - thanks!  The client has 2 DC's (lets call them DC01 and DC02), with all FSMO roles on DC01.  If I look at CN=Rid Set for each DC using ADSIEdit, I see that rIDNextRID is set to 4202 on DC01, but is zero on DC02.  Should we thus be able to fix the problem by simply demoting and re-promoting DC02? I am assuming that the value of 4202 indicates that DC01 is healthy (which is where the RID master is). 

    Monday, February 15, 2010 10:57 AM
  • Ray - presumably - although ultimately this would depend on the existing SID values in the domain. But you would want to start by demoting/repromoting DC2...

    Monday, February 15, 2010 12:06 PM
  • Marcin - why would it depend on existing SID values in the domain?  Would that be because '4202' could be incorrect as well, and there may be existing SID's in the domain using 4202 ... 4xxx ? 

    Thanks very much for your help.  We'll look at doing the demotion/promotion later this week I think.

    Monday, February 15, 2010 2:32 PM
  • In case SID values of existing objects in the domain are higher than those currently allocated via RID master...


    Monday, February 15, 2010 3:09 PM
  • I've done an export of all objects that have an objectSID in AD to text file, using:-

    dsquery * -filter "(&(objectSID=*))" -attr cn objectSID -limit 0 >c:\temp\SIDs.txt

    The highest SID in the domain is 4202, which matches the rIDNextRID on DC01.  This is for a group created about 10 days ago.  So obviously DC01 is fine, and object creation/SID allocation works fine using this DC.

    On further inspection, I see that rIDNextRID on DC02 is actually set to 3167, not 0 as I originally thought.  Turns out you have to view the attribute using ADSIEdit while logged on to the actual DC you're checking - I was checking both from DC01 previously.  So the object in AD with SID ending in 3168 would be deleted next I presume, if we were to create another object now.

    Will let you know how the demotion/promotion goes.  Thanks Marcin!
    Tuesday, February 16, 2010 7:38 AM
  • Marcin,  I've been doing a bit more reading and I think I've found a less disruptive solution to our problem.  This link contains a script to invalidate a RID pool on a DC, forcing it to request a new pool.  I think we'd rather do this than demote/promote:-

    Your thoughts?

    • Marked as answer by Raymond Diack Tuesday, February 16, 2010 12:46 PM
    Tuesday, February 16, 2010 8:40 AM
  • Problem solved - running the script from the article in my previous post invalidated the RID pool and forced the DC to get a new pool of RID's from the RID master.  I created a few groups and verified that their SID's were now in a pool in a higher range than on the other DC, and no more old objects being deleted :)

    Thanks very much for pointing me in the right direction Marcin - I've marked both our posts as Answers as I guess they are both possible solutions :)


    Tuesday, February 16, 2010 12:46 PM
  • Hi All,

    I have same problem, Please  share the all information

    Log Name:      System
    Source:        Microsoft-Windows-Directory-Services-SAM
    Date:          7/10/2012 11:33:31 AM
    Event ID:      12293
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          S-1-5-21-3929239660-4167713049-3265641177-4666
    There are two or more objects that have the same SID attribute in the SAM database. The Distinguished Name of the account is CN= User,CN=Users,DC= name,DC=com. All duplicate accounts have been deleted. Check the event log for additional duplicates.



    Tuesday, July 10, 2012 7:35 AM
  • Hi Bikahs,

    The thread above should have all the info you need.  You need to identify the rIDNextRID value on each of your DC's - the one with the lowest value is likely your problem DC.  Do this using ADSIEdit on each DC using as a guide (you must run it logged on to each DC to see the proper values).

    Then, run the script in using the instructions in that article.



    Tuesday, July 10, 2012 7:51 AM
  • Hi Ray,

    Thanks for your reply, Only one  ADC 2008 STD machine have a problem, already Exchange is running on this ADC, in case I run this script suggested by you will the existing users be effected or not??



    Monday, August 6, 2012 11:44 AM
  • Hi Bikash,

    No as long as you follow the articles precisely it shouldn't cause any further issues.  But as always when making changes to AD like this, ensure you do system state backups of your DC's in case you need to roll back, and make sure you know the Directory Services Restore Mode password on your DC's (you can reset it with ntdsutil if not).

    Good luck!


    Monday, August 6, 2012 1:03 PM