Group Managed Service Accounts (GMSAs)
User accounts created to be used as service accounts rarely have their password changed. Group Managed Service Accounts (GMSAs) provide a better approach (starting in the Windows 2012 timeframe). The password is managed by AD and automatically changed. This means that the GMSA has to have security principals explicitly delegated to have access to the clear-text password. Much like with other areas where delegation controls access (LAPS), determining who should have be delegated access needs to be be carefully considered.
Key Points for Group Managed Service Accounts (GMSAs)
- The GMSA password is managed by AD.
- Computers hosting GMSA service account(s) request the current password from Active Directory to start the associated service.
- Configure the GMSA to allow computer account(s) access to the GMSA password.
- If an attacker compromises any computer hosting services using the GMSA, the GMSA is compromised.
- If attacker compromises an account with rights to request the GMSA password, the GMSA is compromised.
Group Managed Service Accounts have the object class “msDS-GroupManagedServiceAccount” and associated attributes specific to GMSAs. These properties include:
- msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) – stores the security principals that can access the GMSA password.
- msds-ManagedPassword – This attribute contains a BLOB with password information for group-managed service accounts.
- msDS-ManagedPasswordId – This constructed attribute contains the key identifier for the current managed password data for a group MSA.
- msDS-ManagedPasswordInterval – This attribute is used to retrieve the number of days before a managed password is automatically changed for a group MSA.
Lab Example
In order to identify GMSAs in an Active Directory domain, we can use the Active Directory PowerShell cmdlet “Get-ADServiceAccount”.
get-adserviceaccount -filter * -prop * | Select Name,DNSHostName,MemberOf,Created,LastLogonDate,PasswordLastSet,msDS-ManagedPasswordInterval,PrincipalsallowedtoDelegateToAccount,PrincipalsAllowedtoRetrieveManagedPassword,msDS-ManagedPassword,ServicePrincipalName | Sort Name
In my lab environment (mirroring what I’ve seen in real world AD environments), we notice that there is a GMSA in Domain Admins. Let’s dig into that one.
The Citrix GMSA is configured to allow the group “Citrix04” the ability to get the password for the GMSA (property “PrincipalsAllowedToRetrieveManagedPassword”). Now, let’s take a look at the membership of that group.
There’s a user account in that group which means compromise of that user account (AdminJackson) would result in the compromise of the password for the Citrix GMSA and that would result in the compromise of Active Directory since the GMSA is a member of Domain Admins.
I wanted to make it easier to get this information, so I wrote a PowerShell script called Get-GMSADetail that captures this information using the Active Directory PowerShell module. This adds a new property called “PasswordAccessPrincipalString which is a list of principals in the group that have the rights to pull the password.
The results are shown here:
Conclusion
As part of this lab exercise, we learned that if a GMSA is a member of a privileged group (like Domain Admins), compromise of an account that has rights to pull the clear-text password for the GMSA (property “PrincipalsAllowedToRetrieveManagedPassword”) can leverage the GMSA rights (like compromise Active Directory). Furthermore, if we can compromise one of the computer accounts that have the ability to pull the GMSA password, then we can dump the password from the computer.
For more information about attacking GMSAs, read the ADSecurity article “Attacking Active Directory Group Managed Service Accounts (GMSAs)“
Recent Comments