Active Directory has been around a long time. No matter the version, administrators still make the same core mistakes. Some mistakes are simply inconveniences – such as using older versions of Remote Server Administration Tools (RSAT). Others can have major consequences.
Today, we are going to cover the five common mistakes that can have major consequences for your environment. These range from improper practices, potential data leaks, and full directory loss.
Mistake #1: Working from your Domain Controllers
If I had to wager, this is the single most common mistake IT administrators make. Though it appears more in small/single person IT shops, it can happen anywhere.
When I say manage Active Directory from your domain controllers, I mean that the administrator physically logs into a domain controller and launches the management tools from the server. This bad practice isn’t limited to just normal AD object management. I frequently see administrators using the Group Policy Management, DHCP, and DNS consoles.
This is mistake is twofold. If your domain controllers have the management tools installed, they probably have quite a few extra applications or features installed as well. In real environments, I’ve seen domain controllers with Java Runtime, Office, and other consumer products installed…
As a best practice, domain controllers should only run the roles required for domain services (which includes the DNS role). These servers should be configured into server core mode. All daily administration should take place on protected administrative machines.
The beautiful simplicity of server core.
Mistake #2: Not Cleaning Up
A healthy AD environment is a clean AD environment. When an administrator leaves stale users, computers, groups, or even GPOs around, they unnecessarily complicate their environment. And when little things are ignored, bigger problems can result. Let’s look at a real life example.
A certain medium sized company uses AD and SCCM. Certain clients at some locations are unable to get updates, receive software, or appear in reports. After quite a bit of troubleshooting, the problem appeared to be clients unassigned to a management point.
If Active Directory Sites and Services was properly maintained and cleaned, this problem would have never occurred. Subnets would have been populated and clients would have been assigned to a boundary group. Keeping a clean AD environment prevents little problems from growing.
For more information about Active Directory Cleanup check out this article.
Mistake #3: Not Protecting Objects
The Protect from Accidental Deletion checkbox is a hero to many fat-fingered administrators. I can confess that it has saved my bacon on several occasions. When an object is Protected from Accidental Deletion, a simple Deny – Everyone is applied to the deletion action. A very elegant method to prevent oops moments.
Certain objects in Active Directory should always be protected. These include:
- Organizational Units
- Servers
- Important Security Groups
- Important User Accounts
This OU is protected from accidental deletion
Protect from accidental deletion is designed to prevent both mistakes made in the console and improperly written (as in not tested) scripts. Of course, domains should still have the AD recycle bin enabled.
Mistake #4: Exposing Sensitive Data in AD
Active Directory makes a wonderful database. Because of this, IT administrators love to store all kinds of extra data with objects. Things like user account photos and system information are near universal bonuses. Things like clear text passwords or employee tax information are pretty bad.
When populating attributes in AD, clearly map out who should or should not be able to read this information. Some data can be universally accessible. Certain information should not be viewed by anyone (including passwords).
You should also consider if this data should be stored in AD at all. I am all for custom hacks but Active Directory should not be your purchasing or HR database. Carefully review your filled attributes and who has access to them. This brings us to our final common AD mistake.
Mistake #5: Not Delegating (or Over Delegating)
I see both sides of this coin pretty regularly. In some environments, a single IT administrator handles everything in AD. The lack of delegation is constricting to growth. Everyone has to wait on that one administrator to do something. That one administrator can’t ever tackle bigger projects because of the million manual things that need to be done.
On the other side, environments are setup where every administrator is a domain admin. This leads to the too many cooks in the kitchen problem. Everyone is doing everything differently. This, in turn, usually causes mistakes 1-4 to rear up.
Finding the balance is tricky (especially when using the built in delegation control wizard). Carefully evaluate the job duties of everyone who needs to touch AD. Think about specific processes that can be automated. The duties left can be grouped into roles. For example, the helpdesk role may include permissions to reset user passwords, join computers to the domain, and modify certain security groups. Scoping your permissions this way ensure that everyone can do their job and that your AD environment stays secure.
How Did Your Environment Rank?
Many environments have more than one of these problems. Don’t worry too much if you found a few of these in your domain. Knowing about them is half the battle – now you get to tackle the fun project of fixing them!
Joseph Moody is a network admin for a public school system and helps manage 5,500 PCs. He is a Microsoft Most Valuable Professional (MVP) in Cloud and Datacenter Management and blogs at DeployHappiness.com.