
Microsoft first introduced Kerberos delegation with the initial release of AD on Windows 2000 Server. There was only one Kerberos delegation type at that time. The problem with this initial release of Kerberos delegation is it allowed a service to delegate an identity to any Kerberos service on the network. Bad actors realized they could abuse this if they had control of a Kerberos service on the network to steal more credentials and eventually become a domain admin. A bad actor with domain admin privileges can wreak havoc on an organization’s IT infrastructure, such as stealing data or holding data at ransom via ransomware.
When Windows Server 2003 was released, Microsoft renamed the initial Kerberos delegation type to unconstrained delegation. In the Active Directory GUI, this is displayed as the “Trust this user/computer for delegation to any service on the network (Kerberos only)” option, found on the Delegation tab of user or computer objects, as depicted in Figure 1.
At the same time, Microsoft introduced a new type of delegation called constrained delegation, where a Kerberos service is authorized to delegate any identity to a list of specific Kerberos services. This is displayed as the “Trust this user/computer for delegation to specified services only” option shown in Figure 1. If configured to the new delegation type, it significantly reduces the attack surface of the service and the entire environment.
To change the delegation type from the GUI, the account must be a user or computer object and have a previously defined service principal name (SPN). To configure Kerberos delegation, the admin can use the delegation tab. Delegation can also be configured on other types of accounts such as group Managed Service Accounts (gMSAs) and delegated Managed Service Accounts (dMSAs) using command-line based tools.

While on the topic of Kerberos delegation types, constrained delegation with protocol transition should be avoided much like unconstrained delegation. Looking at the same delegation tab, the user interface presents the configuration as “Trust this user/computer for delegation to specified services only”, with the “Use any authentication protocol” option selected in Figure 1. This setting is a concern because it allows the possibility for a service to impersonate any user without providing proof of authentication.
If a bad actor has control of a Kerberos service configured for unconstrained delegation, it gives them the opportunity to obtain a Kerberos ticket to any service for any user or computer that has used the service. The bad actor can re-use those tickets to authenticate to any other Kerberos service on the network. There are several attack methods that a bad actor can use with a stolen ticket:
- Golden ticket: This is the most powerful Kerberos attack where a Ticket Granting Ticket (TGT) is reforged to steal more credentials but leaves behind auditable traces that can be detected by a security operations center (SOC). A bad actor may choose to use this traceable attack method to gain control of an environment quickly.
- Silver ticket: This method is less effective than a golden ticket attack because the Ticket Granting Service (TGS) ticket is reforged. However, a bad actor may choose this slower attack method to avoid detection.
- Pass-the-ticket: This method relies on a lateral movement attack style, which involves stealing TGT and TGS tickets to achieve privilege escalation. A bad actor may use this attack method to acquire more credentials.
- Overpass-the-hash: A bad actor leverages this attack by using an identity’s NTLM hash to obtain a TGT. They may use this method because an NTLM hash is typically easier to acquire.
Now that some of the history of Kerberos delegation has been brought to light and it’s clear that unconstrained delegation and constrained delegation with protocol transition are dangerous for any environment, let’s discuss common reasons why we see these insecure settings:
- Legacy service accounts created prior to the implementation of Windows Server 2003 domain controllers (DCs) had no option to configure constrained delegation. These accounts can be retroactively reconfigured to use constrained delegation for Kerberos if the environment has a domain functional level of Windows Server 2003 or better.
- Service accounts created after the implementation of Windows Server 2003 DCs may have been configured without a focus on security.
- Independent software vendors (ISVs) may have instructed customers to configure Kerberos services in an insecure manner to ensure compatibility and usability of their products.
Protecting delegation in your environment
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
1. Understand the scope of accounts presenting risk to the environment
To understand the scope of accounts that must be addressed, you must identify accounts with insecure delegation configurations. You can use Microsoft Defender for Identity (MDI), Semperis Directory Service Protector (DSP), or Ravenswood’s AD Health Check for this information. Alternatively, you can run the following PowerShell command (which requires the ActiveDirectory PowerShell module) to identify accounts configured using unconstrained delegation:
Get-ADObject -Filter "(UserAccountControl -band 0x080000) -and (isCriticalSystemObject -notlike '*')"
To identify accounts configured using constrained delegation with protocol transition, you can use the PowerShell command below:
Get-ADObject -LDAPFilter "(&(userAccountControl:1.2.840.113556.1.4.803:=16777216))"
2. Identify account usage
It’s important to understand where accounts with unconstrained delegation are being used and why. To start the identification process, ask the following questions:
- Is the account actively being used? Look for events with ID 4624, 4768, and 4769 (source: Microsoft Windows security auditing.) from each DC’s security log in your Security Information and Event Management (SIEM) service. If there are no events found, the account isn’t being used and therefore should be deleted.
- What service is using the account? Review the SPNs set on the account. There should be a prefix and suffix on each SPN. This should be an indicator for not only which system is running a service with this account, but also the software used. For accounts with an SQL Server SPN, you should use SQL Configuration Manager to determine if the account is running an actual SQL Server instance.
- Is delegation required on the account? Confirming the delegation requirements helps identify erroneously configured accounts.
3. Implement stop-gap measures
- Configure the Kerberos service to use a delegated managed service account (dMSA ). If the service is not compatible with dMSAs, reset the account’s password at least once every year, using at least 30 characters in the password. This will help protect against silver ticket attacks.
- Configure the most sensitive AD accounts (e.g. Domain Admins and other Tier 0 accounts) to have the “Account is sensitive and cannot be delegated” flag enabled. This will help protect your most privileged users from having their Kerberos tickets stolen. Accounts with this configuration will prevent their identities from being delegated to any service.
- Add tier 0 accounts to the Protected Users group. This achieves the same result as configuring “Account is sensitive and cannot be delegated” but also provides additional account protection safeguards.
4. Implement preventive measures
- To prevent an account from being used to delegate identities to any service (unconstrained delegation), configure the account to use constrained delegation with specific services and Kerberos only.
- Make accounts single-purposed to reduce the attack surface. Reconfigure any service accounts shared by multiple services to use dedicated, single-purpose accounts.
- Establish a policy requiring managerial approval when requesting configuration of any kind of Kerberos delegation.
- Many Windows features can be enabled and leveraged to help prevent delegation attacks from occurring, including:
- LSA Protection: Requires any plugins accessing the Local Security Authority Subsystem Service (LSASS) process to be digitally signed and adhere to specific coding standards that effectively prevent tools such as Mimikatz from acquiring credentials.
- Attack Surface Reduction (ASR) rules: Provides protection against credential dumping from LSASS.
- Credential Guard: Prevents usage of unconstrained delegation from being used to run any service on the system. Usage of this in conjunction with dMSAs helps prevent silver ticket attacks.
- Windows LAPS: Rotates the local administrator account’s password every 30 days, helping to prevent silver ticket attacks.
- Use tools to persistently check for delegation weaknesses.
- Implement a tiering access model: It helps prevent privileged credentials from being scraped from lower tiered systems.
Conclusion
By implementing stronger security measures, organizations can significantly enhance their security posture and reduce the risk of delegation-related attacks. Proactive management, combined with leveraging Windows security features, can create a robust defense against potential threats. A secure environment not only helps protect sensitive data but also helps fortify the integrity and trustworthiness of the organization’s IT infrastructure.
Ravenswood Technology Group can help remediate insecure Kerberos delegation. Reach out to us to inquire how we can help!