It’s hard to believe that Active Directory (AD) has been around for ten years. AD was a revolutionary product compared with Windows NT, and over the years it has only gotten better. However, AD isn’t perfect—it has its share of annoyances. In this article, I outline a few things that especially bug me about AD, including steps Microsoft has taken to improve the problems. I also suggest workarounds for those problems that are still on the “to-do” whiteboard at Microsoft’s Red West campus.
AD vs. DC Administration
A basic annoyance that's been around since Windows 2000 Server is the lack of separation between administering an AD domain or forest and administering the domain controllers (DCs) that support it. In other words, you must be a domain administrator to be able to fully administer DCs. Microsoft's position is that if you have administrative access to a DC, you should also have admin rights in the domain, because that access lets you hack the DC and elevate your privileges. Computer operators have physical access to DCs, so they can theoretically gain access whenever they want. The counter argument is strictly practical: A computer operator's job is to administer servers in the data center, and a DC should be no exception. It's impractical to say that operators should have admin rights on a machine simply because they have physical access to it; basic security practices dictate that you limit the number of domain administrators to an absolute minimum—which therefore excludes many of your computer operators.
Two workarounds let you circumvent this annoyance. The first workaround is to grant your computer operator security groups only the appropriate rights for their specific job requirements. Actions that can’t be delegated (i.e., those actions that require administrative rights and that can affect AD health) must be performed by domain administrators. The Microsoft document “Best Practices for Delegating Active Directory Administration” details an organized plan to delegate AD service management.
The second method is to upgrade to Windows Server 2008 R2 and use read-only domain controllers (RODCs) wherever possible. An RODC is a DC configuration in which a read-only copy of AD is kept locally, and password secrets aren’t kept at all. A lesser-known feature of the RODC is its administrator role separation: Unlike full DCs, administrative tasks for the RODCs can be delegated to individuals or groups without compromising the entire forest’s security. The reason you can safely grant administrator rights to an RODC but not to a full DC is that, unlike full DCs, RODCs aren’t trusted by the rest of the forest. RODCs never replicate changes into the forest; they only receive them. Unless you explicitly configure the password replication policy on an RODC’s computer object, passwords are never stored on the RODC. As a result, granting an operator Administrator rights on an RODC doesn’t compromise the forest’s security. The TechNet article “Administrator Role Separation” describes how to enable administrator role separation on your RODCs; the “Read-Only Domain Controller Planning and Deployment Guide” will help guide you through placing RODCs in your enterprise. For more information about Server 2008 RODCs, see “Fortify Remote-Server Security.”
Service Account Passwords
One of the longest-running AD annoyances is that of service account passwords. A service account is a user object that’s dedicated to running a server service, such as Microsoft SQL Server. As for any user object, good security practices dictate that the password is changed on a regular basis. The problem is that service account passwords are hard-coded into the service’s properties; changing the account’s password without also changing it at the service location and restarting the service will cause authentication service restart problems. Interfering with a production application’s availability to simply change a password isn’t a popular IT practice. This difficulty has been around since Windows NT, which means longer than 15 years.
Server 2008 R2 solves this issue once and for all with a new feature called managed service accounts. MSAs are special accounts that automatically update their passwords and simultaneously change the password for the service on the managed computer. (For more information about MSAs and how to use them, see “Use MSAs to Ease the Pain of Administering Service Accounts.”) The good news is that MSAs don’t require Server 2008 R2 DCs; you only need to run the adprep /forestprep command to upgrade the forest’s schema to Server 2008 R2. The bad news is that a server must be running Server 2008 R2 to use an MSA.
IT budgets are tight, but remedying this old annoyance is important for security. In fact, it’s a great argument for upgrading to Server 2008 R2.
Site Subnet Configuration
I confess that IP subnet configuration has never been one of my strongest skills. I didn’t really enjoy the TCP/IP networking classes, and getting the custom subnet masks just right for the range of IP addresses I needed for an AD site always took me longer than the other kids. Inexplicably, Server 2008 R2 and Server 2008 make the task even harder than before by requiring that you enter the subnet range using network prefix notation (e.g., 192.168.1.0/20). I knew early on that I wasn’t destined to be a network engineer—but maintaining the list of IP subnets that define an AD site is one of the standard skills an AD admin must have. Fortunately, I discovered several websites that provide IP subnet calculators to do the heavy lifting for you.
The IP Subnet Mask Calculator at www.subnet-calculator.com works well. If you want a freeware app that you can download to your client, try WildPackets’ IP Subnet Calculator, available at www.wildpackets.com/resources/free_utilities/ipsubnetcalc. These applications let you perform what-if scenarios to choose a custom subnet mask or network prefix that covers the IP address range you need it to, and nothing more.
Rebuilding an Active Directory DC
Sometimes a DC’s just gotta go. It isn’t working properly, and you’ve tried everything you can think of to fix the problem, with no success. You’ve run out of time and patience, and you’ve decided that the best solution is to demote the DC—but it’s broken enough that it won’t demote. The only thing left to do is rebuild the box from scratch, do a metadata cleanup, and repromote the machine.
However, if you’re sure the DC’s OS is functioning properly and the problem is with its AD role, you can avoid the annoying rebuild task by using the dcpromo /forceremove command. This little-known option forcibly removes AD from the server but leaves the server OS intact. You’ll still have to do the metadata cleanup, but you’ll reduce the length of the outage because you won’t have to reinstall the OS. After the forced removal is complete and you’ve performed the metadata cleanup, you can repromote the server to a DC.
Metadata Cleanup
To get a failed DC back into service as soon as possible, you should perform the metadata cleanup during the forced removal and reboot. A metadata cleanup is the process of manually removing information about a failed DC (i.e., its metadata) from AD that the dcpromo process would otherwise remove automatically. Performing a metadata cleanup is an annoyance in itself, because you have to work through Ntdsutil commands, on a DC, using a series of commands that aren’t obvious. Fortunately, a couple of Microsoft employees wrote a script that removes AD DC metadata that’s left behind after the dcpromo /forceremoval command is used. Their GUI Metadata Cleanup Utility is available in the TechNet Script Center Repository. This script doesn’t work with Server 2008 R2, but it doesn’t need to.
The most recent versions of Windows Server make metadata cleanup much easier than in the past. Starting with Server 2008, you can perform a metadata cleanup with a click of your mouse. Launch the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in (dssite.msc), open the site that contains the failed DC (the default site is logically named Default-First-Site-Name), expand the Servers container, select the DC to be removed, then right-click and delete it. In Windows 2000, Windows Server 2003, and Windows 2003’s various service packs, deleting a DC’s computer object will generate various warnings to remind you that a metadata cleanup must still be performed. In Server 2008 R2 and Server 2008, the delete action also performs a metadata cleanup. Although this improvement isn’t enough to justify an upgrade, it’s a nice fringe benefit.
Upgrade or Outsmart
Like any large and complicated software product, AD has its share of annoyances. The Microsoft Directory Services team is aware of all these issues and is working on solutions for them. The challenge is in refining AD and making it easier to use, while staying within the boundaries of the design and balancing the amount of time and resources necessary to make changes. Because you can’t retrofit new functionality into an existing OS, in some cases you’ll have to upgrade to take advantage of certain solutions. But sometimes, having the right knowledge lets you work around AD’s problems.
Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.
