In my days of AD administration, there was always a need for a select set of sysadmins to be granted high levels of permissions. In AD, this is typically a separate user admin account that is a member of the Domain Admins Active Directory group. There are a few other groups that are highly privileged (i.e. Enterprise Admins and Schema Admins) but the permissions required by these groups are generally more specific and therefore less populated. Here’s why sysadmins owning permanently privileged accounts is an issue.
Active Directory, at its core, is a single-sign-on solution designed to give users an awesome user experience when connecting to network resources. When a user (any standard user or highly privileged user) logs in, a hash of the password is cached into protected memory on the system. When the user connects to a resource such as a network share, the hash is replayed, and the user gets access without being prompted for credentials. This is invisible to the user.
What if …. a sysadmin logs in interactively (that’s how most of us log in every day) to a domain joined machine, does something that an admin would do, then logs off? Well, to support SSO, the hash remains cached in memory until the system is rebooted.
What if…. there was a way to get access to that hash and act as the admin user? Well, there is. This is an exploit used by attackers called “Pass the Hash”. Here’s a link to how it works.
Extracting a hash with Mimikatz
If an attacker gains access to any domain-joined machine – this can be a server or any workstation or laptop joined to the corporate AD and can impersonate any domain user (yes – any authenticated user can read Active Directory)– then the attacker will do some recon. They will gather information about the domain such as how many user accounts are in the domain, how many computers/servers are domain joined, what the OU structure looks like and how privilege is assigned. They will most likely first look at which user accounts are in the Domain Admins group.
Here’s how an attacker (or any user) would do this with PowerShell on any domain-joined machine.
Or they can just install the Remote Server Admin tools and run Active Directory Users and Computers. Any authenticated user has view rights to Active Directory. That’s just how it works.
So, what is Just-In-Time Privilege Elevation for Active Directory? It works like this.
As a sysadmin, I would still have a separate account for performing highly privileged tasks in AD, but this account would be managed by the JIT process. The account would be disabled when not in use and would NOT be a member of ANY AD groups. When I need to use the account and its credential, I would check it out from the vault. When the checkout is approved (or auto approved) and the time window for use has arrived, the JIT process enables the account, adds it to the correct AD group(s) and provides the credential.
When I’m done using the account or the allotted time expires and the account is disabled, the group membership is stripped, and the password is changed and vaulted.
This will:
- Prevent the use of any residual hashes left on machines. The hashes are still there but now useless.
- Prevent an attacker from seeing the account as an attack vector because it’s not privileged when not in use.
- Provide an audit trail of who used privileged accounts – when, and possibly why.
How does it work? One Identity Just-In-Time Privilege Elevation uses a combination of solutions to make this invisible to the sysadmin. First, the credentials are vaulted in Safeguard for Privileged Passwords. The JIT process uses the Safeguard for Privileged Passwords vault to store the credentials for the “potentially privileged”, it enables them when they are in use and disables them when not in use.
Additionally, One Identity Active Roles is used to dynamically populate group memberships using features of Virtual Attributes, Dynamic Groups and Access Templates. There is a JIT service running on the Active Roles server that listens to Safeguard for the account checkout. When the account becomes available in Safeguard, the listener service turns the Virtual Attribute to “TRUE”. This immediately fires the Dynamic Group process to add the “potentially privileged” user to a group based on the value of the Virtual Attribute being “TRUE” and any other value (i.e. the logon name of the user object).
That gets a little detailed but it’s actually very simple in practice. The end state is a much stronger security posture for the organization because it’s nearly impossible to compromise a privileged AD account. Best practice is to severely limit accounts in the Domain Admins group and even consider enforcing any account that is permanently in the Domain Admins group as a Group Managed Service Account, aka gMSA. Any account that is permanently privileged and is not a gMSA should be very closely audited.
Again, the solutions that make this work are:
Check out this video demonstration of the Just-In-Time Privilege Elevation process or
Visit our playlist to find out more about the features and functionality of Active Roles.
