Standard users having elevated privileges is never good news. Accounts such as domain admins, enterprise admins, schema operators, krbtgt, administrators, and replicators, are a few privileged user groups within an Active Directory (AD) environment. The AdminCount attribute is an AD attribute set to “1” on privileged user accounts.
What does AdminCount = [1] mean?
Every AD domain’s System container has an AdminSDHolder object. The AdminSDHolder object is responsible for maintaining the permissions associated with the privileged accounts and groups in AD. The AdminSDHolder object has an access control list (ACL) that contains these privileged accounts and groups as principals with heightened privileges.
To ensure that the permissions associated with these privileged accounts don’t change, the AdminSDHolder’s ACL is applied to these accounts in a timely manner.
Every hour, the primary domain controller (PDC) emulator, which is a powerful Flexible Single Master Operation (FSMO) role within AD that regulates Group Policy Objects (GPOs) and authentication, runs in the background to check the permissions associated with privileged accounts. The emulator compares the current permissions of the privileged accounts to the permissions present in the AdminSDHolder object’s ACL.
If the privileged accounts have different permissions associated with them, or have been manually configured to inherit the permissions of the groups that they are part of, the PDC emulator will override the existing permissions with the permissions present in the AdminSDHolder object’s ACL.
So, for every privileged account that’s part of the AdminSDHolder object’s ACL, the AdminCount attribute is set to 1.
Why would normal accounts have AdminCount set to 1?
The AdminCount attribute is automatically set to 1 for users added to privileged groups. When these accounts are removed from the privileged groups, their permissions aren’t automatically reset.
For example, let’s say Tom is a user who is a part of a security group. The admin wants to revoke the permissions associated with Tom’s account and make Tom part of a normal group with minimal privileges. So, the admin removes Tom from the security group and adds Tom to a standard group. The admin checks for the permissions associated with Tom’s account, and identifies that Tom hasn’t inherited any permissions from the normal group. The admin then proceeds to manually update Tom’s permissions.
Little does the admin know that the permissions associated with Tom will get reverted to the permissions given in the AdminSDHolder object’s ACL during the hourly check carried out by the PDC emulator in AD. This will result in Tom having elevated privileges without his or the admin’s knowledge.
User accounts, such as Tom’s, will exist in any infrastructure. When attackers get hold of these accounts, they will have access to sensitive resources easily. To prevent such mishaps, organizations must adopt the principle of least privilege (POLP) and clean up user accounts with elevated permissions.
POLP advises on provisioning only the bare minimum permissions for users. This restricts access to sensitive resources and minimizes the risk of data leaks, making it difficult for attackers to get their hands on critical information.
How to identify normal accounts with elevated privileges?
To identify such accounts, identify user accounts with the AdminCount attribute set to 1. To do so, enter the following PowerShell command:
Get-ADObject -LDAPFilter “(adminCount=1)”
This displays a list of objects with elevated privileges.
Modifying the AdminCount attribute manually
You can modify these privileged accounts by following the steps given below:
-
Navigate to Active Directory Users and Computers.
-
Click View and enable the Advanced option.
-
Navigate to user accounts that have AdminCount set to 1 and click the Attribute Editor tab.
-
Open the AdminCount attribute and clear the field.
This will prevent these user accounts from being abused by external and internal parties in the future. However, how will you know if these accounts have already caused damage? What if one of these accounts has already been misused? How do you identify privilege abuse attempts in your infrastructure?
Managing privileged accounts
ManageEngine Log360 is a comprehensive SIEM tool that monitors everything that takes place within your infrastructure, including your AD environment. This solution provides in-depth analytics on privilege escalation and privilege abuse attempts.
If a privilege was exercised by a user account for the first time, or if a resource has been accessed on a host for the first time, the solution can notify you in real time. The solution can also monitor administrative accounts closely, and track the latest admin activity carried out by a user account.
You can also remediate attacks using the solution’s automated incident response module to contain the attack. Take a free test-drive of Log360 to better understand its capabilities.
