Harden AD DS Domain Controllers.
Next, let's take a look at four suggestions from Microsoft on
how we can improve the security posture of our Active Directory
Domain Services domain controllers.
Now, this first suggestion ties into some things we learned in the first module.
One benefit of having newer server hardware is that you
can take advantage of hardware‑based security protections,
like trusted platform module, UEFI firmware,
Secure Boot, and this offers us the TPM protector options
for BitLocker drive encryption as well.
For virtualized domain controllers, you can consider enabling guarded
fabric and shielded Hyper‑V VMs. This provides a nice separation of duties
where you can delegate administration of the Hyper‑V VMs, but you're
preventing those users from having any capability to sign into the VM or
work with the disks outside of the context of the VM and so on, a
separation between what we call the management plane and the data plane of
a service or VM.
You might want to consider deploying read‑only domain
controllers to smaller branch office locations,
particularly if they have intermittent connectivity to headquarters, and
also particularly if they're staffed very lightly,
you may not have a dedicated point of presence for IT there.
And then again tying back to our previous lesson,
configuring either AppLocker or Defender App Control to make sure
that only trusted code is running on the servers,
both through the boot process, as well as when the machine is in user mode
and actually up and running. Some specific advice regarding read‑only
domain controllers that you need to know for your AZ‑801 exam success
include Administrator Role Separation.
This is what Microsoft calls the technique of having a RODC dedicated
administrator. That is, you may, in all likelihood, be in a situation where
you've got a branch office with limited or very limited,
let's say, connectivity to read/write domain controllers. And
you may not have otherwise any administrative credential
password hashes present on the RODC.
So if you do have administration work to do,
you're going to have to have at least some administrative
credentials locally cached on the server.
Now,
Administrator Role Separation ensures that that delegated RODC administrator,
if it's compromised, if that account is compromised,
its blast radius, as Microsoft calls it, will be limited to that
RODC or potentially to that remote site. But that RODC
administrator would not have, for example,
domain administrator, and certainly not enterprise admin privileges,
you understand? Speaking of cached credentials,
you have quite a bit of control about what gets replicated from a
read/write domain controller to your RODCs.
There's the local, RODC local, allowed RODC password replication, and
corresponding denied RODC password replication groups where you can enforce
which accounts will have their passwords cached on the RODC and which ones
won't. Certainly any branch office non‑administrative users should have
their credentials cached so that they can sign in to the RODC and not have a
reliance upon a read/write domain controller. You want to have a separate
Directory Services Restore Mode password configured on the RODC, such that
if it were breached, it would not be breached across the domain or forest.
The Filtered Attribute Set, or FAS, allows you to control the
Active Directory schema attributes that are replicated from the
read/write side to the read‑only side. Again,
all in the name of trying to contain the scope of
compromise if a malicious actor were to breach your RODC.
And lastly, when you deploy the RODC,
you can pre‑populate the password cache, and this would allow you to
function both for your non‑administrative users and then with
administrator role separation with one or more admin accounts in an air
gapped environment where you may not connect the RODC to a read/write domain controller, either for a long, long time, or maybe indefinitely.