The newly implemented Read-Only Domain Controller (RODC) in Windows Server 2008 provides a way to increase the security of servers whose physical security cannot be assured.

In addition, it can provide a way for local administrator privileges to be assigned to a user that you need to be an administrator at the local level, but who you do not want to allow a backstage pass into the domain-wide AD database via replication.

However, because the RODC intentionally limits its participation in the enterprise-wide AD structure, it is wise to limit its use to only those times when the additional level of security is required.

Let's Get Physical

First thing is first. Microsoft has spent the years since the release of the first Windows NT products building up a full scale security model around the Windows Server products. However, security is a mission that never ends.

The hackers don't sit around eating cold pizza and wearing their thumbs out on Xbox moaning about how they can't use the buffer overflow trick to gain access to secure systems anymore.

Instead, they sit around eating cold pizza and wearing their thumbs out on Xbox while wondering what would happen if they could somehow parse a command string with a hex editor when the command is actually expecting ASCII text … Or at least that's what it looks like on YouTube.

I wouldn't know because I wear a white hat (but not after Labor Day), I don't have an Xbox, and I have some sort of genetic defect that prevents me from using both my thumbs and index fingers at the same time. Thus, since the days of Playstation and its accursed F1, F2 buttons, I have been relegated to the last kid picked for dodge ball status of video games.

One of the new frontiers of security concerns is theft of computers with important data. You've heard all about the many laptop thefts. The RODC exists so that you won't start hearing about all of the Domain Controller thefts.

Don't Break It To Save It

The Active Directory system is setup to be a robust and fully scalable way to implement security throughout your enterprise. Past versions of Windows Server products suffered from various scalability issues.

One of those issues was caused by the original domain model that had only one Primary Domain Controller operating with many Backup Domain Controllers. The problem was that too much activity had to take place on the Primary Domain Controller.

In an enterprise with several hundred or even thousands of Backup Domain Controllers, the Primary Domain Controller spent so much time replicating that it could be overwhelmed and unable to handle other requests flooding in. The solution was to distribute the responsibilities of the Primary Domain Controller to many servers instead of just the one.

So, in a regular AD environment, Domain Controllers replicate with each other, eliminating the bottleneck at the single replication point. The system has been more robust ever since.

The RODC acts in many ways like the old Backup Domain Controller. It only replicates back to a more powerful Domain Controller. RODCs do no replicate amongst themselves. Implementing too many RODCs without enough regular DCs can trigger a similar problem to the old Primary-Backup paradigm because too many RODCs will be overwhelming the too few DCs. So, while your AD might be more secure, it will be less usable.

So, how do we choose between installing a RODC and a DC? First, keep in mind that RODCs do not provide greater protection for network based attacks. A RODC only provides more security should someone gain physical access to the server, usually through theft. For those servers locked into secure racks in the nice, cool, monitored, server room this shouldn't be an issue.

When servers are installed elsewhere, usually remote sites, then we need to evaluate the situation. Who will be watching and maintaining these servers?

Are they trained IT administrators who know how important the servers are?

Or are they financial analysts who think all servers look like the WOPR?

In other words, how hard would it be for someone to walk in off the street and trick the employees into access, or how hard would it be to slip in through the back door that is never locked?

We aren't talking about master cat burglars who defeat laser beam security systems by memorizing the timing of the laser beam sweeps. (By the way, if you are going to go through the trouble of installing a laser beam security system, would it really be all that hard to put in some sort of random number generator so the pattern can't be memorized? I'm just saying.)

How to decide when we should install a Windows 2008 Server as an RODC? A simple checklist should cover most scenarios:

• If the server is stored in an open or unlocked area -- install RODC




• If the server will be installed at a location without trained IT personnel -- install RODC




• If the server is stored in a locked area, but personnel other than systems administrators also have access to the area -- consider installing RODC




• If the site will have more than two Domain Controllers -- then limit installs of RODC

  
  

  RODC will not replicate with each other, only with Domain Controllers. Each RODC at a remote site is one more server using the WAN link for replication. For one or two servers, this probably won't have a noticeable impact, but you don't want twenty RODCs using your WAN link for replication.




• If the server is stored in a secure server room or other area with restricted access -- do not install RODC

Pretty easy, right?

Settle Down Mel ...

Systems administrators tend to be clever people. When talking to them about physical security and the RODC they start to imagine all the ways someone could possibly come after their servers, and because sys admins also tend to be movie buffs, things start to get a little crazy.

In the movie Conspiracy Theory, Mel Gibson's character balances a bottle on the doorknob.

That way, if anyone tries to get in, the bottle will fall, and he'll have time to slip out the escape hatch and burn down his apartment.

If this is starting to sound like a good idea for your server areas, then it is time to take a deep breath and re-center.

Ommmmm. Ok, that's better.

While the threat of a stolen server is real, it isn't something that roving gangs of ninjas engage in on a nightly basis.

If someone breaks into your server room through the ventilation system, disables the alarm, repels down ropes, and loads your servers into phony ambulances for transport, there is probably a bigger problem than the security of your AD infrastructure. The FBI, NSA and the rest of the king's horses and men will probably be helping you put your network security back together again.

If a delivery man with a delusion of grandeur walks off with a Domain Controller after saying "Candy-gram" to the receptionist -- that is what the RODC is for.

Remember, just because someone takes your sever doesn't mean that it sings like a canary. There is still a login screen, encrypted data, file permissions, and a host of other security measures standing in the way of the would-be pirates. The delivery man has several long nights ahead of him and when he finally gets anywhere, your AD database will have updated so many times that what he has on the RODC won't be worth much.

So, implement good security and use the RODC where it makes sense and you can feel secure that you have done a good job with your infrastructure.

But, on your way home tonight, I'd make an extra U-turn near the freeway to make sure no one is following you before you go home and crank out your secret leaking newsletter. After all, maybe they are after you …