In this guide, I’ll show you how to find and identify privileged accounts in Active Directory.
Table of contents:
- What Are Privileged Accounts
- Privileged Groups and Privileged Access
- How to Find Privileged Accounts in Active Directory
- List of Built-in Privileged Accounts in Active Directory
What Are Privileged Accounts?
A privileged account is an account that has elevated rights, privileges, and or permissions to a computer system, application, or infrastructure device. Most systems include a built-in privileged account often called administrator or admin. A regular account can be given elevated rights that turn it into a privileged account.
Privileged accounts are typically used to perform administrative tasks such as:
- Install software and driver updates
- Manage Active Directory (create, delete and modify accounts)
- Manage Office 365 (create, delete and modify accounts)
- Configure and change system settings
- Reboot, shutdown devices
- Change configuration to infrastructure devices (routers, switches, DNS, etc.)
- Manage file and folder permissions
Privileged Accounts vs Non-Privileged Accounts
Privileged accounts are typically used by system administrators to manage IT systems. A non-privileged account is often referred to as a regular user account and is what employees use to do their jobs.
If you can log in and make changes to a server or add a user to an Active Directory group then you are using a privileged account.
A non-privileged account should not have permission to make changes to critical systems. For example, Jim from finance logs in and has limited access to the finance system and data but cannot make changes to any critical devices.
A privileged account does not have to be a full administrator of a system. It could be delegated only specific rights such as being an administrator on workstations but not servers. Or having rights to manage a specific OU in Active Directory but not other OUs. It is very common for system admins to delegate specific rights to other admins but these are still privileged accounts.
Below is a screenshot from Active Directory showing the built-in Administrator account. This built-in account has full permissions to Active Directory and domain joined systems. It is a very powerful account.
How are privileged accounts created?
Typically in two ways:
- Most systems include a privileged account by default often called administrator or admin.
- An existing account is granted elevated rights by various methods (more on this in a bit).
Privileged Groups and Privileged Access
It’s important to understand that adding a regular user account to a group can give them privileged access. This is a critical component of Active Directory Security and you need to understand what permissions each group will grant a user account.
Many systems such as Active Directory include built-in groups that are configured with elevated rights. For example, the Domain Admins group is pre-configured with full administrator rights to Active Directory and all systems that are joined to the domain. Any member of this group will have elevated rights turning it into a privileged account.
Let me walk through an example:
I have a regular user account “Timothy Terrell” that has no elevated rights. This account can’t make system changes to his computer or any other system. If I add this account as a member of the Domain Admins group then it becomes a privileged account giving it rights to make system changes.
In addition to the built-in groups, administrators will often create their own groups and then grant them elevated rights.
How to Find Privileged Accounts in Active Directory
You can’t secure what you don’t know.
Privileged accounts can exist in a number of locations and configurations throughout an organization. You need to scan and inventory the following:
- Active Directory Group Membership
- Local Groups on servers and workstations
- Delegated rights to Active Directory (ACL)
- Delegated rights to group policies
- User Rights Assignment configured on group policies
- Office 365 Roles
- Permissions applied to infrastructure devices via Active Directory
This is no small task. Some of it can be done with scripts and tools but it will also require some manual work. I’ll walk through some examples.
1. Check Active Directory Group membership
You need to check group membership for all privileged groups in Active Directory. I’ll open the Domain Admins group and look at its members.
In the screenshot above you can see there are four members of the Domain Admins group. The membership of this group should be limited, meaning Domain Users and Domain Guests should NOT BE members of this group. Otherwise, this would give every user in the domain full domain access.
A faster option to inventory your groups is to use PowerShell or the group membership report tool that is part of the AD Pro Toolkit. With this tool, you can select all your privileged groups and run a report.
Here is the output of the report.
Above you can see I have some accounts in the Schema Admins group and the Group Policy Creator Owners groups. This report can be exported to CSV so you can keep track of any changes. Because these user accounts are members of this group they are now privileged accounts. These are users from other departments and should not be in these groups. This is why it is important to scan and inventory all of your privileged groups in Active Directory and Office 365/Azure.
2. Check Local Groups on Servers and Workstations
Users and Active Directory groups are often added to local groups on servers and workstations. This can give privileged access such as administrator rights to those systems.
To manually check open Computer Management then click on one of the groups. I will check the administrator’s group.
Above you can see there are four members of the local administrator’s group. Domain users are members which give every user in the domain full administrator rights to this server. This is BAD.
It will be impossible to manually check every system’s group membership so again you can use PowerShell or the AD Pro Toolkit. The toolkit has a tool called Local Group Management which allows you to get the group membership on remote computers.
In the above screenshot, I ran a scan on all the computers in my domain so that you can easily see the members of each group. From here, you can filter the results and display only members of the Administrators group or any other privileged group.
3. Delegated rights to Active Directory
Just like files and folders, Active Directory has permissions set on objects called ACL (access control list). It’s common for administrators to use the delegate control wizard to give users or groups specific rights to Active Directory. For example, maybe you gave the helpdesk staff the rights to create and delete accounts to a specific OU, or delete computer accounts. The problem with either of these scenarios is there is no easy way to check the ACL permissions on the entire domain.
In the above example, I manually checked the security for a single OU called ADPRO Groups. You can see there is a group called “Accounting_Folders” that has create/delete users object rights. This means any member of that group can create and delete user accounts in this OU. This is just one OU in the domain, so you could understand how easy security can spiral out of control with this.
You can use a tool like the ACL Scanner Tool to create reports on AD delegated permissions. It’s not the most user friendly tool but it’s better than manually checking every object in AD.
4. Delegated Rights to Group Policy
Special permissions can be delegated to group policy objects. This can give a user rights to modify, create and delete GPO’s. If an attacker gained access to an account that had delegated rights to a GPO they could change security settings, install viruses, and so on.
To check GPO delegated rights open the group policy management console, select an object and click on delegation.
5. User Rights Assignment Configured in Group Policies
Have you checked the User Rights Assignment on your GPO’s? Because these settings can give users elevated rights to perform certain tasks. You should inventory all GPOs and the user rights assignment.
These settings are in computer configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment
6. Inventory Office 365/Azure Roles
Just like Active Directory, Office 365 includes default groups that have elevated permissions. Office 365 calls them admin roles instead of groups. Here are some guidelines for assigning roles in Office 365.
- Don’t have more than 4 global admins – Global admins have unlimited power so limit their use.
- Use the least permissive role – This means giving admins only the access they need. If the helpdesk wants to reset MFA or user passwords then don’t make them a global admin. Instead, give them a role that only gives access to reset passwords.
- Use Multi-factor authentication for all admins – I would recommend enabling MFA for all users.
You can view all the groups by going to Azure Active Directory and then Roles and administrators. Here is a screenshot of the global administrator role.
7. Permissions Delegated with Custom AD Groups
Active Directory is often used as the centralized authentication and authorization for others systems. Here are some examples:
- Access to VMware
- Routers and switches
- Access to Wifi
- SQL Servers
- Sharepoint
- Accounting systems
Whatever system you are using there is a good chance it uses Active Directory to authenticate user access. When I worked for a large organization we would create Active Directory groups to give admin access to Windows Servers, SQL servers, routers, switches, and so on.
For example, we created a group called VMWare-Admins. Inside the VMWare console, we would assign this AD group as an administrator to VMware. Any user added to this group would become a privileged account and have admin access to all the VMware servers.
Access to routers and switches was also done with Active Directory groups. Members of a group called switch-admins could log into a switch with their AD credentials and make changes to the network.
I would recommend for you to check your systems and see if AD groups are being used to provide elevated access to them. In large networks, this can be a nightmare to manage if your admins are not using an easy to follow naming convention for accounts. I always recommend creating very descriptive names for your groups and putting in a description. This will make identifying groups and what they are used for an easier process.
List of Built-in Privileged Accounts in Active Directory
The image below shows a list of built-in accounts and groups in Active Directory that provide elevated permissions. Any user account added to these groups becomes a privileged account so you should inventory and monitor changes to these groups on a regular basis. These groups and accounts are listed in the Builtin and Users container.
I’ve listed the most important ones at the top.
Enterprise Admins
The Enterprise Admins group exists only in the root domain of an Active Directory forest of domains. It is a Universal group if the domain is in native mode; it is a Global group if the domain is in mixed mode. Members of this group are authorized to make forest-wide changes in Active Directory, such as adding child domains. Members in this group can modify the membership of all administrative groups. Membership can be modified only by the default service administrator groups in the root domain. This is considered a service administrator account.
Domain Admins
Members of the Domain Admins security group are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. The Domain Admins group is the default owner of any object that is created in Active Directory for the domain by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group.
The Domain Admins group controls access to all domain controllers in a domain, and it can modify the membership of all administrative accounts in the domain.
Administrators
Members of the Administrators group have complete and unrestricted access to the computer, or if the computer is promoted to a domain controller, members have unrestricted access to the domain.
Schema Admins
Members of the Schema Admins group can modify the Active Directory schema. This group exists only in the root domain of an Active Directory forest of domains. It is a Universal group if the domain is in native mode; it is a Global group if the domain is in mixed mode.
The group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain. This group has full administrative access to the schema.
Account Operators
The Account Operators group grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including those of users, local groups, and global groups, and members can log in locally to domain controllers.
Other groups:
- Allowed RODC Password Replication Group
- Backup Operators
- Certificate Service DCOM Access
- Cert Publishers
- Distributed COM Users
- DNSAdmins
- Event Log Readers
- Group Policy Creators Owners
- Printer Operators
- Protected Users
- Remote Desktop Users
- Server Operators
In addition to the built-in accounts, administrators will often create their own security groups and accounts and grant elevated access to them.
For example, in my network, I created a security group called VMware-admins. Users of this group have administrator access to the VMware ESXi servers. I also have a group called SQL-admins that is used to give admin rights to the SQL servers.