Top 10 Privileged Accounts Best Practices for Active Directory

This is the most comprehensive guide to privileged accounts online.

In this guide, you will learn the basics of privileged accounts, the security risks, and our best practices for securing privileged accounts.

Identifying and securing privileged accounts should be a top security priority due to the potential impact these accounts can have.

Let’s dive right in.

Contents:

• What are Privileged Accounts?
• Privileged Groups and Privileged Access
• Privilege Accounts and Security Risks
• List of Privileged Accounts in Active Directory
• 10 Best Practices for Privileged Accounts
  • Scan and Inventory for Privileged Accounts
  • Use the Least Privileged Model
  • Monitor Changes to Privileged Accounts and Groups
  • Use Multi-Factor Authentication
  • Use Separate Accounts for Administrative Tasks
  • Limit the Scope of Privileged Accounts
  • Use a Good Naming Convention
  • Use a Strong Password Policy
  • Use Privileged Access Management Software
  • Do Not Share Admin Accounts

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:

1. Most systems include a privileged account by default often called administrator or admin.
2. 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.

Privileged Accounts and Security Risks

Privileged accounts are necessary for admins to do their jobs. The security risks are a consequence of the following:

1. Over-provisioning: This basically means giving admins or users more permissions than needed. A common abuse of this is giving users administrator rights on the local computer. This gives them more permission than they need to do their job.
2. Lack of inventory: Not knowing and keeping track of which accounts are privileged is the 2nd biggest risk. You can’t secure what you don’t know.
3. No audit or monitoring: Any changes to a privileged account or group should be monitored and logged.

Let me walk through the picture below to better illustrate the risk.

1. Jim from finance logs into his computer
2. Active Directory authenticates Jim and grants access based on group membership.
   1. At some point, Jim’s account was added to a “workstation-admins” group so Jim could install software on his computer. Jim is now an administrator on all computers in the domain.
   2. Turns out workstation-admins was a member of domain admins which gives Jim access to the entire domain including:
3. Full administrator access to GPOs. This gives the account permission to change security settings, push out software to computers, and change password policies.
4. Full access to office 365. Jim can delete users, data, and computers from Office 365 and Azure.
5. The domain admins group has full rights to the organization’s SAN storage. Jim’s account can delete and make changes to all critical data.
6. Domain admins are members of the VMware-servers groups. Jim now has full rights to all the virtual servers.
7. Domain admins are members of the local administrator group. Jim has full admin rights on all computers.
8. Jim has permission to connect 3rd party cloud systems to office 365. Which is also connected to the on-premises Active Directory.

This could go on and on it just depends on what systems you have and how permissions have been applied. What if Jim got a phishing email and entered his username and password. Now an attacker has his credentials which gives the attacker privileged access to the entire domain. Crazy I know. It happens more than you think.

It’s also important to know privileged access can come from one or multiple locations including:

• Adding users to Active Directory Groups
• Delegating rights in Active Directory
• Adding users to local administrator groups
• Delegating rights to specific systems (group policy, DHCP, DNS)
• Giving a user or group global admin rights in Office 365
• User right assignments in group policy settings
• Full, modify, or ownership permissions to files and folders

It can be difficult to keep track of all this. The best practices section will give you several tips to help you get control of privileged accounts and access. You also need to know which groups in Active Directory have elevated rights and that will be discussed next.

List of Privileged Accounts in Active Directory

The image below shows a list of built-in accounts and groups in Active Directory that provides elevated permissions. Any user account added to these groups becomes a privileged account and 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.

Resources:
Active Directory Security Groups – This article provides a full description of each group in Active Directory.

Privileged Accounts Best Practices

Here are my top 10 best practices for managing Privileged accounts.

1. Scan and Inventory for Privileged Accounts

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.

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.

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.

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.

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.

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

You can also improve security by using policies.

Resources:
Microsoft User Rights Documentation

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.

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.

2. Use Least Privileged Model

The least privileged model simply means to give a user only the rights needed to perform a task or job. It’s a simple strategy that can greatly increase security but unfortunately is often not implemented.

Instead what will usually happen is someone needs permissions such as installing software and they are added to a highly privileged group that gives them more rights than needed. An example of this would be, someone from the helpdesk needs to install software for a user in the accounting department and to do so they think they need to add them to the domain administrator group. This is completely unnecessary and now gives this user full administrator rights to the entire domain. What should have been done, is to give the user rights to install software on one computer only.

Another example is you have a SQL administrator that needs rights to all the SQL servers. These accounts are often added to groups that then give them full domain access or access to all the servers. You should instead give the SQL admin-only access to the SQL servers, not all the servers.

Resources:
Implementing Least Privilege Administrative Models

3. Monitor Changes to Privileged Accounts and Groups

When you have identified your privileged accounts and groups you need to monitor changes to them. This can be done with an instant email alert, or a daily or weekly report. I prefer an instant email or a daily report of changes.

For example, if a user was added to the domain admins group you need to be alerted of the change. There are many tools available that can monitor changes to your accounts such as:

• AD Audit Plus
• Netwrix
• Lepide

If you are good with PowerShell you could write a script that monitors the Windows event logs for specific event IDs and create a report.

4. Use Multi-Factor Authentication

Multi-factor authentication (MFA) should be enabled for all accounts. This will slow down an attacker that steals your credentials or gets them from a phishing email. If you can’t enable MFA for all accounts then you must enable it for all IT staff or anyone that has privileged access. Relying on passwords alone is a bad security practice.

If you are using Office 365 it includes a free option to use their MFA solution. When you buy a P1 license it includes more security features. Duo is also a popular MFA solution.

5. Use Separate Accounts for Administrative Tasks

Privileged accounts should only be used for administrative tasks. Your everyday account should not have special permissions or administrator access.

The account you log in with to check email, browse the internet, and do other basic tasks should not be a privileged account. When you do need to perform administrative tasks, then you should be using a separate account with special permissions or administrator access.

For example, I log into my computer with the account “robert.allen”. It is a regular user account that has no administrator rights. I cannot install software, create AD users, modify permissions, and so on. When I need to do an administrator task like delete AD users I would authenticate to AD with a secondary account that has those rights. Typically the name is something like “robert.allen-admin” but it can be any name you want to give it. Just remember to follow a naming convention that makes it easier for others to identify what the account is used for.

It is also recommended that these separate privileged accounts be used from a secure workstation. A secure workstation is a separate computer that has extra security applied like MFA access, limited to no internet, has network ACL in place to limit which IP addresses can access it, and so on.

Why is this important?

It has become easy for hackers to get access to user accounts through phishing emails, password spraying, and other methods. If you or another user checks emails with a privileged account and falls for a phishing email now an attacker has the credentials to your privileged account giving them remote access and full permissions to your critical systems.

6. Limit the scope of Privileged Accounts

In addition to creating separate accounts, you should limit the scope of privileged accounts. This is basically the same as the least privileged model but it needs to be mentioned again. What happens most of the time is a group of admins all have full access to everything. You should separate duties, eliminating having 10+ system admins all with full access to everything. Here are some examples of separating administrative duties.

• Network Admins – This group has permission to make changes to switches and routers
• Server Admins – This group can make changes to all servers
• SQL Admins – This group can only make changes to SQL servers
• VMware Admins – This group has rights to manage the VMware servers
• File Servers Ready only – This group has read-only access to the file servers
• 2-3 global admins – Full access to everything

7. Use a good naming convention

As I have already mentioned, a good naming convention can go a long way in helping you get control of privileged accounts. Generic accounts and group names are not helpful because you will not know what they are used for unless you have an excellent documentation system. It’s rare to see good documentation. There is usually one person that does it right but everyone else says they are too busy.

I believe you should be able to look at an account or group and know what it is used for. This will help you, your team, and any future admins.

Following a naming convention will help you to easily identify all privileged accounts moving forward. There is no cookie-cutter naming convention, just make sure it makes sense and everyone follows it.

The same goes with service accounts; I’ve seen so many generic service accounts, that it drives me nuts. I’ve even had people on my own team that has created service accounts, and then a year later no one knows the user for the account.

8. Create a Strong Password Policy

Every user should be using a strong password policy. You can even use fine-grained password policy that applies to specific accounts. Here are some best practices for a strong policy

• Minimum length 12
• Change passwords every 90 days
• Use MFA
• Focus on passphrases, not password complexity
• Use password blacklists
• DO NOT set user accounts to password never expire

9. Use Privileged Access Management Software

Privileged access management (PAM) software helps you to manage and monitor privileged accounts in an organization. There are many vendors that offer PAM solutions such as:

• Cyberark – I’ve not used their products but they are a leader in Gartner.
• Netwrix – provides many security tools
• Microsoft Pam – There is the MIM Pam that is for on-premises AD, then there is Azure AD PIM that is for Azure AD. Microsoft likes to complicate things.
• Beyond Trust – They have some nice products but are expensive.
• ManageEngine Pam 360 – I’ve used several ME products that are pretty good. They roll out a lot of new features at times and can be very buggy.

PAM software can be expensive, but in my opinion, if you follow all the tips in this guide then you probably don’t need a full PAM solution. The one tool that I would highly recommend is a tool to monitor changes to accounts. So if you can’t afford PAM software then you should at least invest in something that monitors account access and changes.

10. Do not share admin accounts

Each administrator should have their own individual accounts. This will help with auditing and the separation of duties. Using the default or a shared account provides no auditing or accountability. This also makes it difficult to remove access when an employee leaves. If the admin had their own account access can easily be terminated by disabling the user’s individual account.

I hope you found this article useful. As you can see Active Directory Security is a complex topic with many moving parts. It can easily get out of control if no processes are put in place.