There is no doubt that Microsoft has fully embraced The Cloud. While “Mobile first, cloud first” might be a silly statement, there is no doubt that Microsoft means it. There are very few on-premises products that Microsoft has much interest in selling at all. If there is a cloud-based option for any solution, Microsoft is going to push that cloud version at the expense of the on-premises version.
It’s also clear that Microsoft big advantage over other cloud providers in the ability to provide hybrid solutions. Not every solution can be cloud-only, and aside from maybe Windows itself, I would say Active Directory leads that category. On-premises Active Directory isn’t going away.
In this blog post we’re going to look at on-premises Active Directory and my suggestions for how to keep it healthy. I’ll try to cover all the big points you to keep your organization’s Active Directory happy, healthy and functional.
Here are six points that I find are important to ensure the health and good function of your Active Directory.
Keep up to date
As more and more of our IT services move to one cloud or another, IT departments forget about patching and updating. This can be especially the case for Active Directory.
Keeping your domain controllers patched and up to date is one thing. I see more and more organizations falling behind on the current version of Active Directory. I get it, an Active Directory version upgrade can be a very painful process. I recently did one that had problems with older applications. That was not a pleasant process, but we got through it.
A good way to make it less painful next time would be to do it more often. Don’t want 10 years for your next Active Directory upgrade.
This seems way to obvious, but I’m going to say it anyway. Backing up your Active Directory is actually a very small part of “data protection.” I see customer environments where backups are done daily, but no restores have been done in “living memory.”
If you’re not doing restores, then you’re not really doing backups. Do you know the Directory Services Recovery Mode password for all your domain controllers? Have you tried to restore a deleted OU? Do you know how to recover from a broad permission change accidentally applied?
I can’t recommend building out a lab for this sort of thing highly enough. Doing a restore during an outage is very stressful. It’s a much more manageable task if you’ve done it recently in your lab.
Add as much information as possible
I frequently run into problems where I need to sort out a subset of user’s accounts from Active Directory. Maybe we’re working on planning migration batches, or maybe we need to setup notifications of a planned outage to groups of users.
It’s important to find the time to update and maintain the information in your Active Directory accounts. Phone numbers, addresses, manager, and all the other fields in your Active Directory accounts. These bits of information can be very helpful, but you never really know before hand when you are going to need them. You’ve got those youngsters on your help desk who don’t really do all that much most of the day, right? Have them spend an hour a day updating information in your Active Directory and you’ll soon find the problem is taken care of.
Follow best practices
On the surface, that seems like pretty obvious advice. The problem is everyone talks about these “Best practices” like there is a big stone tablet somewhere listing them.
What is the Best Practice for account lockout policies? I just did a five-minute search for that and came up with about 6 different answers. Lockout after 3 failed login attempts? Some say that just raises help desk costs. So, what is the right answer?
As with most things in life, there isn’t one right answer. Maybe locking out AD accounts after 3 failed login attempts is going to work well in your environment and solve more problems than it causes. Maybe a better password policy and a self-service password reset system would help?
“Best Practices” are hopefully well reasoned arguments for this setting or that one to be implemented in your environment. Just remember, the reason that setting exists is because there is more than one opinion on the “right way” to solve every problem. Use good judgement and consider the entirety of your IT infrastructure. Listen to everyone’s opinion, then decide which Best Practice is best for your environment.
Get an outside opinion
I’m a consultant, so this one sounds a little self-servicing even to me. None the less, I still think it’s a good idea to get an outside opinion on your Active Directory health.
I do Active Directory health check projects every few months, and each one is different. I find the best thing I can do is spend a little time going through the customers Active Directory, then ask them questions. “Why is this setting like that?”, “What was the reasoning behind making that configuration choice?”
An Active Directory health check can uncover things that are clearly wrong. Much more often the exercise of talking to an administrator about her AD will lead to a stronger and healthier Active Directory.
Ask yourself “What happens if…”
When my father was teaching me to drive, he was fond of asking me questions like “What are you going to do if a tire flies off that truck next to you?”
While this little game was frustrating for me at the time, I’ve since come to greatly appreciate it. While it’s useful to be thinking about emergency situations that may occur while I’m driving, it’s been a far more useful exercise in my IT career.
If anything that can go wrong will go wrong, then our jobs as IT professionals is to figure out everything that can go wrong and have a plan ready to fix it. What are you going to do if 5,000 accounts get deleted from your Active Directory? What are you going to do if someone runs a script that changes permissions on a few hundred thousand Active Directory objects? What do you do if a Domain Controller is stolen from one of your satellite offices?
If you want to keep your Active Directory healthy spend some time each day documenting your processes for fixing the things that could go wrong.