In my previous blog posts, I gave two examples of a privileged user could easily hose your Active Directory: by changing deny logon rights and by erasing the DNS entries on a domain controller.
You might be thinking those are just hypothetical scenarios that never really happened to anyone. So today I’m going to tell you an AD disaster story that happened to a real Quest customer.
One day, the customer, who was running Windows Server 2008, found all of its DCs in an endless reboot cycle. It turned out that a privileged user had gone into a subnet and accidentally changed an IPv6 setting to an invalid IP address. When the Knowledge Consistency Checker (KCC) replication setup process encountered the invalid setting on that DC, it crashed. That caused the DC to reboot — but not before the invalid setting had been replicated to all the other DCs across the entire environment, causing them all to start rebooting repeatedly.
Can you imagine trying to recover from an incident like this? With native tools, getting back to normal could take days, if not weeks — you’d have to reload every DC from scratch, re-promote each one and clean up the metadata, and let them replicate as if they were brand-new DCs coming into the domain. The costs of that much downtime and disruption would be enormous, and as the IT pro responsible, you’d probably need to start polishing your resume. Fortunately, as I mentioned, this company was a Quest customer; with Recovery Manager for Active Directory, their IT team had the domain back up and running in less than an hour.
There are two important takeaways here:
Don’t let this happen to you! Read our ebook: “Three ways a privileged user can hose your Active Directory” to learn about eight AD security best practices, including privileged user management, that will help you reduce the risk that privileged accounts will be misused, either deliberately or accidentally, and help ensure that you can recover quickly if those preventative measures fail.
Download the E-Book