Let's review some ways to restrict access to domain controllers.
Actually, in the previous module, it was more holistic,
wasn't it,
looking at the motherboard and hardware security
controls providing physical security.
Here, it's much more software‑based, specifically dealing with accounts.
Let's take a look.
Remember from the previous lesson we learned about authentication policy silos?
This provides us a way to restrict access to particular high‑value machines
such that even domain administrators would not be allowed to sign in to a
privileged access workstation or a Windows Server host that they shouldn't
have access to by means of policy.
We've been using Group Policy, speaking of policy,
right along, and we've got user rights assignment,
which comes into play in a more focused way in this module,
actually.
Hang on.
We've got the Windows Defender Firewall,
particularly the concept of network access groups.
This is where we can configure the Windows Server built‑in firewall to
create what is Microsoft termed as domain isolation,
where you can use IPsec, Internet Protocol Security,
to enforce particular communication rules between certain hosts in your domain.
And then again, a callback to a previous lesson.
We have the Protected Users global group,
as well as in Group Policy the concept of restricted groups where we
can buy policy assignment using Group Policy Objects,
GPOs.
We can enforce membership in particular groups,
particularly built‑in groups like the local Administrators group on
domain member servers and domain workstations.
Active Directory Account Security and Delegation.
Let's review some of the built‑in Active Directory groups.
We're going to pay attention to the ones that have the
most default permissions and user rights.
In an Active Directory Domain Services domain,
if you open the Active Directory Users and Computers application,
for instance, you see there's a couple containers.
Remember that containers are different from organizational units.
We cannot link a Group Policy Object to one of the containers.
But the built‑in container has your default domain local groups,
which is the domain controller's equivalent of machine
local groups that you would have on, say,
your workstation.
Here are the ones that you want to pay the most attention to are,
of course, the built‑in administrators, the built‑in server operators,
and then as you'll see in the demo, there's a number of other ones.
Each of these groups has automatically attached permissions and user rights,
and just out of the box, we know that we want to protect those high‑value groups.
And we can do that in a number of ways that are
built right into Windows Server or, optionally,
can extend into those Microsoft cloud services.
In the users container,
this is where you see your built‑in universal and domain global groups.
We have the default Administrator.
This is the first account in a new forest in the forest root domain.
Each domain has the Domain Admins global group.
You've got the Enterprise Admins universal group.
We've got Protected Users.
We've got Schema Admins.
These are just some of them, but they're among the highest privileged groups.
So, again,
they're the ones that you want to pay the most
attention to from a security perspective.
And a user right is different from a permission.
In terms of a permission, like an NTFS permission,
would allow create, read, update, or delete operations on an object or a file.
User rights deal with actions, the ability to sign in to a workstation,
the ability to sign on to a machine as a service as opposed
to an ordinary interactive user account,
that kind of stuff.
Here I created a lucid chart diagram to show how those
built‑in high‑privilege groups work together.
We have, particularly in the first domain in your forest,
the forest root domain, you've got that Enterprise Admins universal group.
The only entity, or account,
in there by default is going to be the forest root administrator account.
Much more common in daily practice is to use the Domain Admins group,
which is universal in a sense.
I mean it is populated by default in the Administrators domain local group,
so this means that if you make a user a member of
the Domain Admins global group, they will automatically,
by inheritance, be an administrator of every domain controller.
But then across the domain,
the Domain Admins global group is automatically populated into the
local Administrators group for member servers and member workstations
when those machines join the domain. This is what gives you
out‑of‑the‑box reach across your domain.
If you're a domain admin,
you can sign in by default outside of something like an
authentication policy silo. You can sign in as a local administrator on any domain member device.