Windows Server 2008 introduced read-only domain controllers, which receive a full replica of the domain database but can't modify it, just like a good old Windows NT BDC.

I know all the technical ins and outs of how to run those semi-DCs (I just passed 70-646 and 70-647), but still I don't have a clear answer to the most important question of all: why should you use them?

This comment from TheCleaner really sums it up for me:

@Massimo - yes, you are correct. U are looking for a compelling reason for an RODC and there isn't one. It has a few additional security features to help alleviate branch office security and really only needs to be deployed there if you don't have a DC there already and are anal about its security.

That was the same I was thinking... a little increase in security, yes, sure, but definitely not so much to be worth the hassle.


I'll give you a real-world scenario:

  • we have one in our branch office in China

We use it because there isn't an IT dept there, we handle all requests for AD accounts, etc. here in the USA. By having a RODC there we know:

  1. Nobody there can log onto it and try to "hack away" at AD.
  2. Nobody can steal it and get anything worthwhile to then come back with and "hack away" at the network later.

By having AD/DNS read-only we don't have to worry about attempts to manipulate the data on the DC there.

This is because of features found here: http://technet.microsoft.com/en-us/library/cc732801%28WS.10%29.aspx

It's more of "peace of mind" than anything else for us...plus it allowed for a very minimal server install since it was just server core with RODC role installed. We put it on an older 1U server with 2 Raid-1 18GB drives. We actually put 2 of them in...same exact configuration using older non-warrantied hardware we had in the racks.

Simple, does what it needs to do, and we don't have to worry about it. If one of the boxes fails, we would simply replace it again.

  • 1
    You said nobody can log onto it; but nobody would be able to log on to a standard DC too, if he didn't have proper domain credentials. So where's the improved security? About stealing it: how exactly would a stolen writable DC be more dangerous than a stolen read-only one? – Massimo Sep 1 '09 at 20:24
  • 2
    @Massimo - referring to logging onto it, that's only an issue if the person has log on locally rights, you are correct. However, we do grant those to a few accounts there so that they can check the backups/backup tape swaps. For the physical security, a stolen writable DC gives you the ability to figure out their credentials and passwords and come back to the network later for additional data...the RODC doesn't. – TheCleaner Sep 1 '09 at 21:20
  • @Massimo - I noticed in your OP you said "full replica"...this is true EXCEPT for the passwords. It doesn't replicate passwords, so that ends up being the biggest pro-security feature for theft. – TheCleaner Sep 1 '09 at 21:27
  • Agreed for the passwords. But aren't they stored using one-way encryption, anyway? It sure is better if someone doesn't get hold of them at all, but I don't think cracking AD passwords is so easy. – Massimo Sep 1 '09 at 23:08
  • 3
    The RODC doesn't store the password hashes if you disable caching...I believe it stores the "login token". Yes initially the client authenticates with the real DC in a different location. See here: devendrathatte.blogspot.com/2009/04/… and here: milesconsultingcorp.com/… – TheCleaner Sep 2 '09 at 14:56

I have a whole chapter on this feature in my book (www.briandesmond.com/ad4/). The long and short of it is that this is a security feature and for distributed organizations it is a huge deal.

There are two really big scenarios here:

--> RODCs store no passwords by default. This means that if someone physically gets the disks from the server, they don't get all your user (and computer) passwords.

The correct response if someone steals an RWDC is to reset ALL passwords in the domain as you can consider them all compromised. This is a major undertaking.

With an RODC you can say only cache the passwords for subset X of users and computers. When the RODC actually caches the password, it stores that information in AD. If the RODC is stolen you now have a small list of passwords which need to be reset.

--> RODCs replicate one-way. If someone stole you RWDC, made some changes to it, and plugged it back in, those changes would replicate back into the environment. For example they might add themself to the domain admins group or reset all the admin passwords or something. With an RODC this is simply not possible.

There's no speed improvement unless you're placing an RODC in a location which didn't have a DC there before and then there is likely to be a speed improvment in some scenarios.

TheCleaner's reply is really incorrect. There are ALOT of compelling scenarios for RODCs and I can think of several deployments of them at scale offhand. This is simple security stuff, not the "anal about security" stuff.


Brian Desmond

Active Directory MVP

  • Brian, thank you for the detailed answer, but I'm still as curious as before about some things: 1) If someone can get hold of a DC, how can he make changes so the domain, if he doesn't have an administrative account? He wouldn't even be able to log in. 2) If someone steals a DC, how can it get passwords from the AD database? They're stored inside a proprietary database, using one-way encryption (and quite a strong one, IIRC). 3) If your DC is stolen and who stole it can access your network and connect it back, something's definitely broken in your security... and no RODC is going to fix it. – Massimo Sep 6 '09 at 12:12
  • 1
    With regards to 1 and 2, there are tools available on the Internet that will gladly take an AD database and read/write directly to it. All you need to do is pop the hard drive(s) in somewhere that contain it and open it from another machine. Agreed on 3 to some extent. Many organizations have hundreds of DCs in branch offices all over the world. I can tell you first hand that enforcing physical security in a closet 10,000 miles from your desk is next to impossible. – Brian Desmond Sep 7 '09 at 16:44
  • If a bad guy has access to your hardware - it ain't your hardware any longer. Do you use Bitlocker for your current DCs to begin with? If not, consider doing that to start with or some other full disk encryption... if the bad guys have your data - you're SOL ^^ – Oskar Duveborn Nov 5 '09 at 15:25

You need RODC's when you have lots of branch offices with poor physical security and/or slow or unreliable network connectivity. Examples:

  • Medical provider with a central office and storefront clinics that move frequently and use DSL/Cable for connectivity
  • A company with facilities in remote areas where the telco infrastructure is unreliable, or where you are forced to use cellular or satellite networks.

Most organizations have physical security standards for remote equipment. If you cannot meet those requirements, RODC's allow you to provide high speed authentication for access to local applications and file shares. They also allow you to limit the number of credentials stored on the server. A compromised server only compromises users at the remote location. A full DC with 75,000 users exposes all of those users in the event of a local compromise.

If you work in a smaller company, it's no big deal at all. I'm pumped to roll them out with BitLocker because RODC's substantially reduce security risk.


We are going to use RODC in a DMZ based off of this TechNet article. Setting up a new forest for web services with an RODC in DMZ.


Primarily for security, but also for speed as well.

See the short write up here

  • 2
    I disagree with the "speed" thing. If users need to authenticate against a "real" DC, then the RODC doesn't actually speed up anything: having a writable DC available in the site instead of the RODC would actually be faster. – Massimo Sep 3 '09 at 7:12

A RODC contains a read-only copy of your AD and you use one in a branch office where you don't have IT staff present and therefore can't guarantee security or integrity of your server room. In the event of the RODC being compromised you are safe in the knowledge that whoever compromises it will only have access to your AD in the state it was in at the time of discovery. No changes made to it will be replicated back to your main DCs. That means that whoever compromises it can't do nasty things like elevate themselves to Domain Admin, lock out your own admins, and have their wicked way with your entire network.

  • What do you mean by "no changes made to it will be replicated"? If I can get administrative access to AD, which is needed to change anything at all, then I can connect ADUC to a "real" DC (or RDP into it) and make my changes directly there. And if I can't get administrative access, I can't do anything even if I have a DC sitting on my table. – Massimo Sep 1 '09 at 23:13
  • 2
    @Massimo - yes, you are correct. U are looking for a compelling reason for an RODC and there isn't one. It has a few additional security features to help alleviate branch office security and really only needs to be deployed there if you don't have a DC there already and are anal about its security. – TheCleaner Sep 2 '09 at 15:00
  • @Massimo You don't need administrative access to AD to change anything - boot from a DVD and you can directly write to the AD databases. – Richard Gadsden Oct 17 '12 at 16:48

RODCs are useful for large enterprise organisations, competing enterprise Directory services like Novell eDirectory have had Read-Only replicas for years.


Another advantage of RODCs is, that they will allow you to have working domain controllers while you do some disaster recovery, that involves taking down all normal domain controllers to rebuild active directory. You don't have to turn off RODCs in those situations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.