When it comes to securing Active Directory, the first place to start is usually getting a handle on what currently exists - getting a ‘lay of the land,’ so to speak. In Active Directory, the admincount attribute can play a role in identifying privileged accounts. It’s not without its faults, however. In this blog, we will explore the admincount attribute in more detail and potential uses it may have for determining which accounts may have or had privileged access.
The admincount attribute is a value that’s stored on a user object in Active Directory. The attribute is set to 1 for accounts that are members of a privileged group, such as Domain Admins, Enterprise Admins or Schema Admins. By default, its value is <NOT SET>. This is only changed to 1 when the native SDProp process runs on its hourly schedule. Because of this, someone could be added to the Domain Admins group, make a change and then immediately be taken out before the next execution of SDProp. This would result in the offending user’s admincount attribute remaining unchanged, no matter what the value was previously.
Understanding the SDProp process is crucial to making use of the admincount attribute. As stated previously, it runs every 60 minutes by default. In short, it compares the permissions of the domain AdminSDHolder object with the permissions on protected accounts and groups in the domain. If a discrepancy is found, the permissions to the protected objects are altered to match what exists on AdminSDHolder. Therefore, the permissions on the AdminSDHolder container need to be monitored carefully, since any change made at this level will be propagated to privileged accounts/groups. The interval for running the SDProp process can be altered to occur more or less frequently. Running the process more frequently could reduce the risk of the previously mentioned attack occurring at the expense of increased LSASS traffic. More information can be found here.
Additionally, let’s say a user was to be a member of a privileged group long enough for SDProp to mark the admincount attribute as 1, then the account is removed from the group. Most may see this as a good step, but there’s more to it than that. Removing a user from a privileged group does not reset or change the admincount attribute at all. It can be manually changed but does not do so automatically. The significance here is that if we leave it set to 1, other non-Domain Admin user accounts will not be able to modify it since it remains a protected object in AD and does not inherit permissions. This can cause all sorts of havoc if you have service accounts that are not domain admins that need to modify the user object in some form. Products such as password self-service tools are a prime example of software or other processes that could fail if the service account has been delegated the least amount of rights required for regular user modifications.
Because of this glaring hole in accuracy of the admincount attribute, and whether it determines if a user is privileged, should come with a hefty grain of salt. It is not entirely useless either. Although finding a non-admin account with the attribute set to 1 would not likely be an indicator of a persistent backdoor attack, it is still useful to have a list of objects that are or were members of a privileged group. Additionally, reports could be generated to show these non-admin users, which could then lead to further investigation on when/where/why the account was previously a privileged user.
It is important to note that the admincount attribute is not a security control by itself. It is merely an indicator of whether an account is or was a member of a privileged group when the SDProp process ran. Therefore, it is essential to ensure that proper security controls are in place to manage privileged accounts. This includes implementing strong password policies, Multi-Factor Authentication (MFA), regularly reviewing and monitoring privileged access and restricting access to privileged accounts in a number of ways. This is where third-party solutions can help tremendously.
One Identity Active Roles allows you to easily identify these user objects and collect them in what we call a “Managed Unit,” which is more like a virtual OU. This gives you an instant, non-powershell scripting method of finding these accounts and displaying them. Additional filtering criteria can be added to further refine the results. Bulk actions can, of course, be taken against these objects if you desire to set the value back to its default. Finally, the permission structure of Active Roles allows you to delegate administrative level permissions to users without actually giving them domain admin level rights.
Quest Change Auditor can also play a large role in monitoring permission changes made to the AdminSDHolder container and admincount attribute with email alerts sent instantaneously.
For more information on how Active Roles can help you find and secure your privileged accounts, visit Active Directory Management Tool | Active Roles (oneidentity.com).
