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?

3
  • 1
    Have you fired any IT people in the last few months? Nov 14, 2014 at 23:46
  • In a manner of speaking, yes. We went from one outsourced IT service provider to another. I don't view either of them as having the know how to have done something that elaborate though. Nov 15, 2014 at 3:19
  • It doesn't take a lot of knowledge to be utterly destructive, and it does happen. Nov 15, 2014 at 3:38

1 Answer 1

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.

5
  • Yep. This is the answer. They are almost certainly reanimated tombstones. Someone screwed up and tried to cover their tracks.
    – MDMarra
    Nov 15, 2014 at 3: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. Nov 15, 2014 at 3: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! Nov 15, 2014 at 5: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. Nov 15, 2014 at 6:30
  • 1
    Nevermind, found out there are tools like AdRestore from SysInternals to do this in bulk. Nov 15, 2014 at 7:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .