When many think of administrative rights in Active Directory (AD), they often think about the built-in security group Domain Admins. But there are other built-in security groups that can give out administrative permissions, more than what you may think. This post will identify eleven built-in security groups that should be audited regularly along with my recommendations.
Administrators
This security group contains the security groups Domain Admins, Enterprise Admins, and the original Administrator user account. Domain Admins and Enterprise Admins get many of their AD and domain controller permissions from this group. However, this group does not have any permissions on member servers and workstations.
Recommendation
Remove all members except for Domain Admins and Enterprise Admins, and the original Administrator account.
Domain Admins
This security group is a member of the built-in security group Administrators. Also, by default, this group is a member of all local administrators groups in the domain on each server and workstation.
Recommendations
Do not have your day-to-day user account as a member of this group.
Make sure members of this group have their passwords set to expire often and have long complex passwords.
Do not add service accounts to this group. Accounts with Service Principal Names (SPNs) are vulnerable to Kerberoasting (more on this another time).
Add members of this group to the Protected Users group. Leave at least one Domain Admin account out of the "Protected Users" group as a backup authentication method. When adding users to the Protected Users group, make sure and test. Click here for more information on the Protected Users group.
Enable "Account is sensitive and cannot be delegated" on the Account tab of the user object.
Consider setting the following group policy settings for all member servers and workstations (don't apply these settings to the domain controllers themselves). You will need to create additional groups for workstation and member server administrator logon rights:
Deny access to this computer from the network for Domain Admins.
Deny log on as a batch job for Domain Admins.
Deny log on as a service for Domain Admins.
Deny log on locally for Domain Admins.
Deny log on through Remote Desktop Services user rights for Domain Admins.
Enterprise Admins
The Enterprise Admins group is a member of the built-in security group Administrators. Members of this group can make forest-wide changes such as adding or removing domains, establishing forest trusts and raising forest functional levels.
Recommendation
Keep this security group empty until you require the rights assigned to this group. Once you are done performing whatever task you need, remove the account from this group.
Schema Admins
This built-in security group has the built-in security group Administrator as a member. This group can manage the AD schema (framework for the entire AD forest).
Recommendation
Keep this security group empty until you require the rights assigned to this group. Once you are done performing whatever task you need, remove the account from this group.
Other Built-in Security Groups of Note
Typically regular user accounts have weaker passwords, and some may even be set to not expire (for instance service accounts). The following groups are more likely to have regular users as members. Below is a list of other groups that should be audited along with my recommendations. For a complete list of built-in AD security groups and their permissions click here.
Account Operators. This group can manage all AD users and group objects in the domain as well as log on to domain controllers. These privileges provide a bad actor an escalation path to an administrator account. I recommend using delegated rights instead of adding members to this security group.
Backup Operators. This group can back up files, restore files, log on to a domain controller, and shut down the domain controller. These privileges provide a bad actor an escalation path to an administrator account. If you do use this group, regularly audit the group membership.
DNS Admins. This group has administrative rights over DNS. These members can also run a DLL on a domain controller, thereby providing a bad actor an escalation path to an administrator account.
Group Policy Creator Owner. Members can create group policies. Also, members can modify and delete the policies they create. Members cannot assign policies to OUs, this will have to be done by a more privileged account. These privileges provide a bad actor an escalation path to an administrator account. I recommend leaving this group empty.
Print Operators. This group can install print drivers, create printers, share printers and delete printers on a domain controller. Also, this group can manage printer objects in AD, log on to domain controllers, and shut them down. These privileges provide a bad actor an escalation path to an administrator account. I recommend leaving this group empty.
Remote Desktop Users. By default, this group isn't provided many rights, but in some cases, this group is added to the group policy setting "Allow log on through Terminal Services". If this group policy setting is applied to domain controllers or other servers, then the members of this group can use remote desktop to connect and log on to these privileged systems. I recommend leaving this group empty and making sure it is not assigned "Allow log on through Terminal Services". If you do need to grant remote desktop rights, create another group for this purpose.
Server Operators. This group can manage servers, including logging on to domain controllers and shutting them down or restarting them. These privileges provide a bad actor an escalation path to an administrator account. I recommend creating individual AD security groups per server, then add these AD groups to the appropriate local server groups which provide more granular control.
My goal is to design and build the best infrastructure possible. The above just goes over some privileged built-in security groups. There are many other built-in groups, also custom groups and user accounts can be assigned privileges directly. My recommendations are made based on my experience, Microsoft best practices, and other security professionals. Some of my recommendations you may want to implement, others you may not, it all depends on your environment. Any recommendations you implement, you implement at your own risk (in other words do your homework and know what you are doing before you do it).
If you have any security practices you implement in regards to anything above, please leave a comment below.