5

We had an instance yesterday where approximately 130 of our well over 5,000 user objects suddenly became corrupted. Every attribute you can possible set with the exception of sAMAccountName and cn were wiped clean including their password despite policy forbidding anything less than 8 characters. The modified timestamps were all seconds apart from one another. Their accounts were also disabled. I suspect because of the blanking of the password. When we went to re-enable the accounts, we would get an error saying the password did not meet requirements. So, we had to reset all of their passwords. The accounts were also unlinked from their Exchange mailbox and we had to re-connect them. Even all of their group memberships were removed.

Something odd we noticed is that all of them were, when sorted alphabetically by cn, among the first one to three users within their OU container. Beyond that, no patterns were noticed.

Initially, I thought this might have been caused by someone writing a script and screwing up. But, the fact the passwords were set to blanks leads me to believe that couldn't have been done via a script.

Unfortunately, for reasons I won't go into we did not have auditing turned on.

Has anyone seen this before? Do you know what might have caused it?

Drew Chapin
  • 631
  • 7
  • 16

1 Answers1

7

This sounds like someone or something deleted the accounts, and then restored them. (Picture an admin saying "oh shit" - we've all been there.) This is the same kind of behavior you'd see when you restore/reanimate objects that have been deleted, back in the old days before the AD Recycle Bin. The object is restored with a blanked password and is disabled as a result, and most of the attributes and group memberships are lost.

Check Security event logs on your DCs if you have auditing enabled. If you don't, check repadmin /showobjmeta.

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • Yep. This is the answer. They are almost certainly reanimated tombstones. Someone screwed up and tried to cover their tracks. – MDMarra Nov 15 '14 at 03:53
  • This makes sense. In fact, now that you mention it. I recall one of the other IT admins saying some of those users under their OU had been deleted a week or so ago. Also, we're probably still living in the "old days" as we're still in a 2003 R2 environment. – Drew Chapin Nov 15 '14 at 03:55
  • **+1**, Doing some research on this I was able to confirm this is what happened. All of the affected user's show the `isDeleted` attribute in their replication history. Unfortunately, we don't have auditing turned on, and the security logs for the DC don't go back far enough to see who was logged on during that time. Thank you for your help! – Drew Chapin Nov 15 '14 at 05:51
  • Something still unexplained. How did they re-animate 130 of them within a matter of minutes (the modified timestamps were also approximately the same)? The only way I found to do this was using `ldp` and it seems you have to do them one-at-a-time? `ldp` also seems to update the modified timestamp from my testing. – Drew Chapin Nov 15 '14 at 06:30
  • 1
    Nevermind, found out there are tools like `AdRestore` from SysInternals to do this in bulk. – Drew Chapin Nov 15 '14 at 07:07