Not long ago, I was talking to an IT pro whose Active Directory went down suddenly one day. He couldn't determine the root cause, so this was his recovery plan:
Reboot, restore, and then resign.
While not all IT pros will be quite so ready to fall on their swords, we’re all more vulnerable to similar incidents than we might care to think. The fact is, it’s shockingly easy for a privileged user to hose your AD. In this series of blog posts, I’ll illustrate just three of those methods — and also tell you where you can learn about best practices that will help protect your Active Directory, and your job.
How denying logon rights can hose your AD
There are five ways a user can log on to Windows: locally, from the network, as a batch job, as a service and through Remote Desktop Services. For each of these logon methods, there is a pair of logon rights, one to allow logon and another to deny logon.
By assigning the five deny logon rights in the right way, a privileged user can quickly bring operations to a standstill:
- Users will be unable to log on to their workstations.
- Admins won’t be able to get into the domain controllers, even using the local keyboard and screen at the console.
- Service accounts won’t be able to log on.
- Applications won’t be able to start.
To make matters worse, you’ll be just as hosed as everyone else! You won’t be able to log on with a domain account, so you won’t be able to fix the problem remotely. Instead you’ll need physical access to your DCs so you can reboot into DSRM and begin recovery operations from there. Not exactly what you want to be doing with executives and end users alike hounding you to get the business back up ASAP.
But our privileged users wouldn’t do that!
“Wait just a minute,” you might be saying, “I trust my team! They’d never damage our critical systems like this!”
Deep down, though, you know as well as I do that you can’t be certain about that. How many times have you seen interviews of people who know someone accused of some crime or other, all of them incredulous that their colleague or friend or loved one could possibly do such a thing? Even well-intentioned people have their price, and disgruntled people have their breaking points — especially if they think they won’t be caught.
Moreover, privileged users don’t have to be actively malicious to do damage; as we’ll see later in this series of blog posts, accidental changes can incapacitate your systems just as effectively as deliberate sabotage. Finally, remember that user accounts get taken over by hackers all the time; your privileged accounts are not immune.
Eight best practices for reducing your risk
In short, as the saying goes, hope is not and should not be your strategy. Rather, as IT pros, we need to think carefully about the ways in which the worst possible outcome could come to pass, and plan the steps we can take to mitigate the risk. In my next two blog posts, I’ll tell you about two of the many other ways privileged users can hose your AD, either deliberately or accidentally. I also urge you to check out our ebook, “Three ways a privileged user can hose your Active Directory,” which explains eight AD security best practices for reducing the risk of privileged accounts being misused and ensuring you can recover quickly if those preventative measures fail.
