Deploy Read‑Only Domain Controllers, RODCs.
What is an RODC?
Well,
it's a domain controller that hosts a read‑only copy of the AD
directory database and also read‑only DNS.
So the idea here is security.
You would consider deploying an RODC to branch offices that may have
limited network connectivity and/or no local IT staff.
So you're concerned that if there is a breach in that branch office,
you may not have the eyeballs inspecting that server or those servers so much,
so how can you harden the machine as much as possible?
Well, if it has a read‑only AD database, then that means a couple things.
One, it still will be able to process logons and it'll have a DNS zone,
so again, name resolution should be fine,
but if there's a new user let's say, how is that new user,
especially if it's a new user to the organization and the branch,
how will that happen, you know?
Or if you make a host addition to the DNS zone,
how in the world can you do that if the RODC cannot do a write?
Well, it's replication.
You're going to need to create the objects on a read‑write domain controller,
and then we have uni‑directional replication to the RODC.
You also can configure something on a read‑write domain
controller called the filtered attribute set.
In other words,
you can specify that certain Active Directory attributes are secure.
Maybe you've extended your schema and added a badge ID let's say,
and maybe for security reasons a particular branch that has an RODC
should never receive that particular new user property.
The idea is you want to contain the blast radius.
If a bad actor or group were to compromise that RODC.
They're not going to be able to modify AD or DNS because they're read‑only.
We have potentially some attributes coming from the domain or
forest that are not being replicated to the RODC because we've
marked them as the filtered attribute set,
and then we have the ability to selectively cache credentials.
So the idea is that you would allow credential caching on the
RODC only from the users in that branch office.
And again, worst‑case scenario, if the RODC were breached,
the only accounts that would be compromised would be the ones
that have cached credentials on the RODC.
Now riding herd with the RODC, we have the concept of Install from Media or IFM,
this is where you can deploy a domain controller without
a live connection to a read‑write DC.
Maybe you have an RODC deployed to an offline or secure network.
What you can do,
the process is you create your installation media on a writeable DC,
transfer it to your offline server, what will become your RODC,
install the AD DS role on that target server,
and then when you promote the server to be a domain controller in the domain,
you specify the IFM option and then point to your offline media.
Now, eventually, that server will need to receive updates.
The idea is that,
especially when you're deploying a domain controller in a
spot with limited network connectivity,
that initial replication is going to be potentially a big one if you're
in a mature domain environment with lots of objects,
so you can save on all that replication traffic by doing an offline install
for media to get the bulk of the directory on that machine.
And then when you light up replication to it again,
whether it's uni‑directional if it's an RODC,
or bidirectional if it's a read‑write domain controller,
it'll just be any updates that might have occurred to Active
Directory since you created the media. See the idea?