Any of you who knows about Domain Controller, must be aware of Read Only Domain Controller. The concept of Domain Controller is quite straight forward but when we talk about RODCs, it’s not that simple. The concept of RODC is, if not very complex, but surely one of the most confusing topics in Active Directory. Let’s understand about RODC and why exactly we need it?
So first question comes, do we need RODC mandatorily? Answer is No. No matter how big your organization is, provisioning RODC is optional. Then another question comes, when should we use RODC? Answer is, it depends. Depends mainly on how your physical offices are setup, how remotely your organization is working or how good and reliable your technical team really is.
Before that, let’s understand what RODC is? Till Windows 2003 servers, we had a concept of only “Writable” domain controllers. With Windows 2008, Microsoft introduced a feature of “Read Only” domain controllers. As name says, in RODCs, we can’t modify any data. On other side, in writable domain controllers (or only DCs), we can modify the data. To setup a RODC, you must have at-least one writable domain controllers. Whatever content is there in your main writable DC, the same content will be replicated to RODC. The only thing is, you can’t change, create or delete anything, logging in a RODC.
So why we actually need them? We use them in mainly following conditions:
- Office is in very remote location where accessibility is a problem
- No proper physical security to the servers
- No proper network bandwidth
- No manpower with very good System Administration skill-sets
Let’s assume that you have an office in very remote place where only few users are working. Do you want to appoint a dedicated System Administrator at that location? Perhaps no. So who will be managing your domain controller there? Can you run that location without a domain controller? Yes we can, but it will create hell lot of network latency and users may face very frequent authentication issues.
We know how important domain controllers are and any bad thing with DCs can cause an enterprise level outage. Means, if I am the Domain Admin of a domain, I can shut down the entire company. I am not saying I will do it intentionally, but if I have limited knowledge and I don’t know how to manage DCs, I can do disaster. Also if anything goes wrong with the remote DC, it will take time and effort to reach there and troubleshoot it. By putting writable DCs in remote locations with limited skillsets, we can’t take such kind of risk. In these situations, RODC comes into the picture.
It acts as a local domain controller at that site and let users authenticate quickly and securely, but since it has “read only” data, including RODNS (Read Only Domain Name Server), no one can play with the content or configuration. So if I am a System Administrator at very remote location with very limited skills, I can’t do anything on local RODC intentionally or unintentionally.
So, by putting RODCs in place, we are helping local users to authenticate and authorized same as writable DCs, but at the same time we are protecting our organization from any possible outage. Isn’t it great? Hope it clarifies your confusion about RODC. In following few posts, we will practically see how we can setup a RODC and what all additional settings we need to configure.