Don’t Worry He Can’t Write: The Story of the RODC

Once upon a time, if you worked for the XYZ Company, you worked in the XYZ Headquarters building on Main Street with everybody else.

The computer systems for the XYZ Company were managed by professionals whose full-time job was to install, configure, and maintain the systems.

So if Joe in accounting had a problem with his computer he would call you or Ted, or one of the other admins, and you would stop by Joe’s desk on the way back from grabbing a bagel in the company cafeteria.

If the XYZ Company got big enough it would open up another office. Management would decide which employees should be in which location.

Accounting might stay in the original headquarters while you and the marketing group moved to the new location ("So long, Joe.")

Along the way, things changed …

Companies needed not just two or three big offices, but maybe two or three big offices and DOZENS of smaller offices. Some of those offices might have just a handful of employees.

Your average Sys Admin would get pretty bored maintaining just eight computers. The XYZ Company is not interested in paying for a fully qualified systems administrator for a dozen offices if they aren’t going to be fully utilized.

So, IT responsibilities get handled by a technician or in some cases by Rob, the contracts guy.

Now, Rob is a good guy. He makes sure the Nowhereville office’s contract get approved quickly, and he also manages the local softball team.

His wife is the manager at the local grocery store/video store/bowling alley/Post Office.

The thing about Rob is, that although he is a good guy and can change a printer toner in less than eight minutes, he doesn’t really know a lot about servers.

So, when the professional looking gentleman in the uniform that looks kind of like the ones the phone company guys wear shows up to make the network faster by tuning the Domain Controller, well … Rob points him in the direction of the "big computer" and offers him a cup of coffee.

You Ain’t Got a Thing If You Ain’t Got Physical Security

Microsoft has spent millions of dollars and many years working on the security for its Windows Server products. These days, a Microsoft Server is about as secure as any server can be; that is if you are coming at it from over the network.

With the proliferation of remote offices for companies both big and small, there are more and more computers out there. The workstations are secured in their own way, and if one is compromised by theft or a local administrator run amok the damage is limited to whatever was on that system.

There really is no way to leverage a single computer into enterprise access once the system has been removed from access.

But, the Computer Grinch is not so easily defeated, and one day he got an idea, a really fantastically rotten idea. If he got a Domain Controller he could take as much time as he wanted to get inside at the goodies, and when he did, he would have a way into your whole enterprise right in his hairy green hands.

For a smaller organization it might be possible to rebuild the Directory for security purposes, but for a large organization with hundreds or thousands of man-hours in the design, development, and implementation of a complex Active Directory, that isn’t a viable option.

Just hoping that the Computer Grinch doesn’t work something out isn’t very viable either.

Reading, No Writing, Rithmitic

Although this scenario sounds a bit far fetched, computer hackers aren’t just going to go away. And with good full scale attacks becoming harder to implement thanks to the growing use of firewalls, secure server systems, and even savvier users, the idea of walking off with a domain controller starts to look a little bit better.

So Microsoft has developed the Read-Only Domain Controller. The Read-Only Domain Controller (RODC) is pretty much the same thing as a Writable Domain Controller as far as your users and their resources are concerned. Where it is different is in how its AD database is handled.

Here is a quick point of terminology. Microsoft considers a regular "writable" domain controller to be a Domain Controller. A non-writable domain controller is a Read-Only Domain Controller.

So, if you see the phrase "Domain Controller" it means a full writable Domain Controller. Only if you see the words "Read-Only" or the letters RODC should you think "read only."

The RODC allows your enterprise to put a controller in any office regardless of the level of security that office has. If you want to put a RODC underneath the receptionist’s desk or next to the vending machine, that’s fine. (It’s not great, so if you have a better spot then use it.)

A RODC contains, as one might expect, a Read-Only Active Directory Database, but it isn’t as simple as it sounds.

For starters, the database isn’t really read-only in the traditional sense. The data can be, and is, updated. It is just that the updates only come in one direction: FROM the other domain controllers.

So, any changes that might be made by someone using a compromised local administrator password or a disgruntled field technician won’t be replicated back into the Enterprise. The damage is limited to the RODC.

This means that even if a domain controller was stolen there is no need to change your entire Directory because every second the stolen domain controller is off the network, its database gets staler and staler until it is completely worthless even to the most talented of hackers.

This level of security also provides a way around that nasty problem of needing someone to handle something locally on a domain controller that requires an administrator password like installing a driver or replacement hardware.

In Server 2003 giving someone an administrator password on the domain controller means giving the full access to the enterprise’s Active Directory. While Mr. Local is politely saying, "Ok. Yeah. Ok," to your directions over the phone, he could be giving his user account admin rights. Or, if he’s a little smarter making a new hard-to-spot account with admin rights. Neither one is a good thing.

On the other hand, while giving someone a local admin password to a RODC does give them full access to that machine, it stops there. No changes that are made while in the RODC get propagated back to the enterprise, so your guy gets nothing out if it.

Not a Problem

The most common thing I hear when people learn about the Read-Only Domain Controller is that physical security of the Domain Controllers isn’t a very big problem. I always respond with one word, "Yet."

In the end, the RODC solves a fairly uncommon security issue, that of domain controller theft, and a slightly more common security issue of employee tampering.

It’s likely that neither causes your organization much trouble today, and that is a good thing. By implementing the Read-Only Domain Controller now, you can make sure it stays that way.

And, isn’t it nice to be out in front of the danger instead of catching up?


This site uses Akismet to reduce spam. Learn how your comment data is processed.