If you’re reading this blog then you’ve probably got some interest in cyber security. Hopefully you’ve heard of the Principle of Least Privilege. If not:

The Principle of Least Privilege (PoLP) states that a subject should be given only those privileges needed for it to complete its task. If a subject does not need an access right, the subject should not have that right. Further, the function of the subject (as opposed to its identity) should control the assignment of rights.

CISA.gov

In the context of Active Directory, you impose role-based access control (RBAC) to users in your organization units (OU’s) through group policy. A default installation of Active Directory does the bare minimum job.

The default domain controller policy removes the privilege of normal user accounts to sign in to the domain controller

Unfortunately for us the PoLP applies to every server and application in your network not just the domain controllers so relying on default domain controller policy is inadequate to say the least. So how do you build upon the default domain controller policy? Remember RBAC? A possible next logical step might be to restrict access to your servers based on the type of server it is and the user accessing it.

And here the story begins

Active Directory has native policy-based tools for managing the built-in windows security groups. One such tool is Restricted Groups. This policy, as it’s named, allows you to restrict membership to built-in local security groups on windows. The policy functions by removing any group that is not whitelisted in the policy.
To understand why this is important we have to put on the hat of an attacker. Let’s say that an attacker was able to compromise one of your users, gain a foothold in your corporate network through their account, and then escalate from their low privileged account into a local administrative context. Their next step, would be persistence. They might be to create for themselves an account that is a member of the Builtin\administrators group. That way they are no longer reliant on a privilege escalation chain and they have the privileges to create a backdoor in the context of a high privileged account. If you have a Restricted Groups policy in place then at the heart beat of your AD group policy update, by default every 90 minutes with a random offset of 0 to 30 minutes or on computer restart, your group policy is reapplied to every computer/user in your domain. When the group policy is refreshed the Restricted Groups policy will re-apply and remove the account any user accounts or groups that are not whitelisted from the Builtin\administrators group (or any other local security group you specify).
In effect we impose a time limit on a would-be attacker, and I hope you have tooling in place that reports the creation of arbitrary admin accounts. If not, Snare is a tool you might want to look into.

So how did I remove access to the domain controller for my boss?

I used Restricted Groups based to implement RBAC following the PoLP in a policy linked to the root container of the domain.

Big No No.

At the time I was working on a policy that separated workstation administrators from server administrators. Rather than linking the policy to an OU containing servers and workstations respectively, I linked the policy to the root container of the domain. This meant that the was policy applied to every OU (including the domain controllers). As I’ve stated Restricted Groups restricts and removes users and groups from local security groups so in effect I removed the Domain Admins group from the Builtin\Administrator group on every computer in the domain. This set off a lot of alarms and my filled up my email with automated notifications pretty fast. Luckily it was a pretty simple fix because all that really happened was, I replaced the domain admin group with server-administrators and workstation-administrators. So all I had to do was login in with an account in the server-administrators group and restore the domain admin group.

The lesson in all of this,
Beware the power of group policy….