Home General Kerberoasting Under Fire: How Group Managed Service Accounts Can Save the Day

Kerberoasting Under Fire: How Group Managed Service Accounts Can Save the Day.

October 9, 2025

Overview

Kerberoasting, a well-known attack on Active Directory (AD) infrastructure, poses a significant threat to organisations.

To mitigate Kerberoasting attacks one of the most effective solutions is the use of Group Managed Service Accounts (gMSAs).

We’ll be taking a look at how to set up a gMSA for a SQL Server Failover Cluster, but we’ll start with a short demonstration of a Kerberoasting attack.

Kerberoasting 101!

A condensed overview:

  1. An attacker in possession of a domain account enumerates service principal names (SPNs)
  2. They then request a service ticket from the TGS for the identified account(s)
  3. The KDC issues a service ticket which is encrypted with service account’s NTLM hash
  4. The attacker obtains the service ticket, targets the portion encrypted with the underlying NTLM hash of the service account, and attempts to crack it offline to reveal the clear-text password

In this demo we’ve already obtained the privileges of a low-level user in the AD domain.

From here we will use the Impacket toolset to first enumerate any domain accounts that have a SPN set on the AD attribute ‘servicePrincipalName’.

We’ve identified a single account, SQLService, which appears to be used to run the MSSQL Service on LAB-MSSQL1.

We’ll request a TGS for this account from the KDC.

Cracking the hash itself will not be performed as part of this blog post, but further guidance and detailed explanations of a wide range of password attacks can be found in our free hands-on training, Password Cracking 101+1!

It’s as simple as that. Whilst more complex passwords can be set in an effort to mitigate the risks of Kerberoasting attacks, Microsoft has the answer for us in the form of Managed Service Accounts.

Advantages of Group Managed Service Accounts

  • Enhanced Security and Credential Management:
    • gMSAs eliminate the need for static passwords and manual management. They are stored securely in Active Directory, hidden from users, automatically generated and rotated at regular intervals, reducing the risk of weak, stale credentials.
  • Least Privilege Principle:
    • Following the principle of least privilege, gMSAs receive precisely the privileges they require to perform their designated tasks. As they’re not granted excessive permissions, the likelihood of abuse for other attacks is reduced.
  • Isolation:
    • gMSAs are domain entities but function in a more secure and restricted manner. They are tied to specific computer accounts, which limits their use to those systems only and helps safeguard against potential lateral movement abuse.
  • Credential Protection:
    • gMSAs encrypt their passwords, ensuring they can only be accessed by the system they’re assigned to. Additionally, these passwords are automatically rotated by Active Directory, after a given timeframe. (Default is 30 days)

Setting Up gMSA’s

We start by creating a Key Distribution Services (KDS) Root key, which is responsible for generating and distributing service principal keys used for secure communication between services and clients in a Kerberos authentication environment. It essentially serves as a master key, enabling domain controllers to create unique keys for running services to ensure proper authentication across the network.

We can use PowerShell again to create this:

Note: After creating a KDS Root Key, it is highly recommended to wait at least 10 hours from the last point of a full AD Replication before attempting to create MSAs, as this is the default time for replication of the key to complete across the AD estate.

Add a new Global Security Group that will contain the SQL Servers that will be scoped to the gMSA.

Now add the target SQL servers to the newly created group. In this example we are adding LAB-MSSQL1 and LAB-MSSQL2, both of which are SQL servers that form a SQL Server failover cluster.

Note: In the above example, note the dollar ($) used at the end of each server name, denoting that the target members are computer accounts.

So far we’ve added a new KDS Root Key, created a new AD Security Group for the gMSA, and added both member SQL servers to the group.

Next we need to create the gMSA entities, and specify which AD objects (AD group in this case) can retrieve the passwords for the gMSA.

We will be following the Microsoft recommended best practice and separating out the groups, one for the SQL Server, and one for SQL Server Agent.

Here’s a breakdown of the parameters:

  • Name – Specifies the display name of the new service account.
  • SamAccountName – Specifies the SAM account name of the new service account. The SAM account name is the legacy pre-Windows 2000 logon name.
  • DNSHostName – Specifies the DNS host name associated with the new service account. It is used for the service principal name (SPN) registration.
  • PrincipalsAllowedToRetrieveManagedPassword – Specifies the security group or user accounts that are allowed to retrieve the managed password of the new gMSA. (In this case, we are scoping this to the ‘gMSA_SQL_svc’ group created in the previous step)
  • ManagedPasswordIntervalInDays – Specifies the interval (in days) for automatically regenerating the managed password. The gMSA password is automatically changed within this interval for enhanced security.
  • Enabled – Indicates whether the new service account will be enabled or disabled.

Test and Implement

Before we reconfigure any services to use gMSAs, we can quickly use PowerShell to determine whether the gMSA is set up and configured to work for the target machines.

If a gMSA has been configured correctly, and relevant permissions and delegation assigned, running Test-AdServiceAccount -Identity <serviceAccountName> should return the following:

In contrast to this, machines that are not configured as member servers for the gMSA will return the following:

All that is left is to configure the SQL Servers to run the SQL Server and SQL Server Agent services with the respective accounts on LAB-MSSQL1 and LAB-MSSQL2.

Using SQL Server Configuration Manager, select ‘SQL Server Services’ from the left pane, and then right click the SQL Server service in the right pane. Choose the ‘Log On’ tab and then configure the SQL Server service to use the corresponding gMSA. Do not enter a password, as this will automatically be retrieved from Active Directory.

To finish, repeat the above step for the SQL Server Agent service. Both services are now configured to use gMSAs.

With the gMSAs configured and in use, the burden of manually managing service account passwords is eliminated, reducing the chances of security breaches due to password-related insecurities, as well as greatly reducing administrative overhead.