Server 2008

Read-Only Domain Controller (RODC)

Windows Server 2008: Read-Only Domain Controller (RODC)

A Read-Only Domain Controller (RODC) is a new type of domain controller in Windows Server 2008. Its main purpose is to improve security in office branches. In this post, I summarize the functionality of RODC.

In office branches, it is often not easy to provide sufficient physical security for servers. It is not a big deal to manipulate a Windows system if you can get physical access to it. Since Domain controllers store security sensitive data, they are particularly endangered. RODCs can help with this problem in four ways:

RODC essentials

  • Read-only feature: An intruder on the RODC can’t manipulate the Active Directory database.
  • DNS protection: If the RODC server hosts a DNS server, the intruder won’t be able to tamper with the DNS data.
  • Password protection: A malicious user won’t be able to access passwords using a brute-force-attack. This applies only if password caching is disabled on the RODC.
  • Administrator Role Separation: You can delegate a local Administrator role to a domain user.

Read-only Domain Controller

  • An RODC holds all Active Directory objects and attributes.
  • RODCs only support unidirectional replication of Active Directory changes (i.e., from the forest to the RODC).
  • If an application needs write access to Active Directory objects, the RODC will send an LDAP referral response that redirects the application to a writable domain controller.

DNS Protection

  • A DNS server running on an RODC doesn’t support dynamic updates.
  • If a client wants to update its DNS record, the RODC will send a referral for a writeable DNS server.
  • The client can then update against this DNS server.
  • This single record will then be replicated from the writable DNS server to the RODC DNS server.

Password Protection

  • By default, an RODC doesn’t store user or computer credentials. (The only exception is the computer account of the RODC itself and a special krbtgt account.)
  • However, an RODC can cache passwords.
  • If a password isn’t cached, the RODC will forward the authentication request to a writeable DC.
  • The Password Replication Policy determines the user groups for which passwords caching will be allowed (more about this in my next post).

Administrator Role Separation:

  • A domain user having the Administrator role on an RODC doesn’t have to be a domain admin.
  • A domain user having the Administrator role can do maintenance work on the RODC such as installing software.
  • If an intruder gains access to the credentials of this local administrator account, he will not be able to make changes on other domain controllers.

the disadvantages of RODCs

I don’t have much experience with RODCs yet. However, I already see some of the downsides of this new kind of domain controller:

  • If you add RODCs to your network, you certainly increase the complexity. RODCs simply work differently than DCs, which means that new kind of problems might come up.
  • Administrators need to invest time to learn how to manage RODCs.
  • Some third party products will not work together with RODCs.
  • An RODC usually needs a writeable domain controller to work properly. For example, users can’t change passwords, computers can’t join the domain, accounts whose passwords haven’t been cached can’t logon, and Group Policy doesn’t work properly if no writable RODC is available. This means that an RODC doesn’t provide the same failure safety like a writeable DC.

Don’t underestimate the first two points. At first, I thought, it can’t be too difficult installing an RODC. After all, it is just a DC with reduced functionality, i.e. with only unidirectional replication. However, it took me more time than expected to set up a test environment.

My RODC had two network cards, one was in the same sub network as the writeable DC, and the other network card was connected to the same sub network as my clients. Most things worked fine. However, I wasn’t able to authenticate against the RODC if the writeable DC was offline. In theory, this should work if the user’s password is cached on the RODC. Even though I could see that the password was cached, I always got this error message: The trust relationship between this workstation and the primary domain failed. However, if the writeable DC was online, I had no problems logging on to the RODC.

Maybe my configuration was not correct or maybe there was a bug involved. I didn’t try too long to solve this problem, since Windows Server 2008 is still beta. But this example shows how new kind of problems can arise. With two writable DCs I wouldn’t have to invest extra time. Time is money. Maybe it makes more sense to invest this money in a better physical protection of the servers in your branch offices.

There are certainly environments where it makes sense to work with RODCs. Big companies with Active Directory specialists probably won’t be afraid of the increased complexity. However, since bandwidth gets cheaper almost every day, it is probably only a matter of time until domain controllers in branch offices will not be necessary anymore. So maybe it is a bit late for this new technology.



Leave a Reply

Your email address will not be published. Required fields are marked *