Kerberos delegation is already known as an expansion of the familiar on-prem attack surface. Our latest Kerberos delegation vulnerability research by Eliran Partush (CVE-2025-60704) is a great example of how delegation can be leveraged for elevation of privilege (EoP) from a weak user to domain admin.
A common assumption we still see in the field is that delegation risk is “a user thing.” If a user is considered sensitive, delegation should be disabled for that account, and the problem is solved. In this post, we’ll show why that assumption is incomplete: Kerberos delegation in Active Directory applies to computer accounts as well. That means a service trusted for delegation can act not just on behalf of other users, but also on behalf of machine accounts, the most critical non-human identities (NHIs) in any domain.
The risk is obvious. If an adversary can leverage delegation, it can act on behalf of sensitive machine accounts, which in many environments hold privileges equivalent to Domain Administrator.
Executive summary
- Delegation is not limited to users. Computer accounts can be delegated on behalf of, including highly privileged machine identities such as domain controllers.
- The ADUC UI creates a dangerous blind spot. The “Account is sensitive and cannot be delegated” checkbox exists for user objects but is missing for computer objects. There is no Account tab exposed for machines.
- The protection still exists under the hood. The ADS_UF_NOT_DELEGATED bit in userAccountControl can be set on computer accounts using PowerShell.
- This is a widespread hardening gap. Based on our research data, we rarely see sensitive machine accounts explicitly protected from delegation.
Technical whitepaper
CVE-2025-60704: Validation Flaws in Windows Kerberos S4U: From Protocol Transition to Privilege Escalation
TL;DR
Mark sensitive machine accounts as not delegable:
PowerShell
Set-ADAccountControl -Identity “HOST01$” -AccountNotDelegated $true
Delegation is not an edge feature
Kerberos delegation is a common control-plane mechanism used to preserve identity across tiers when a front-end component must access a back-end service that enforces authorization in the caller’s context.
CA Web Enrollment is a representative example of constrained delegation being used to extend user identity into a back-end service tier that performs sensitive operations. The IIS component receives a user request and must interact with the CA back end to submit enrollment operations. Constrained delegation allows the CA to receive a Kerberos ticket that represents the requesting user so that certificate issuance can be authorized using domain identity, group membership, template permissions, and issuance policy.
This pattern shows up everywhere. SQL Server’s Kerberos double-hop, where a front-end application server queries a SQL back end on behalf of the calling user, is one of the most common constrained delegation configurations in enterprise environments. Most AD administrators have set this up at least once.
Delegation is powerful, common, and deeply embedded in real architectures. That’s also why it shows up in attacks.
The UI trap: “Sensitive and cannot be delegated” does not exist for computers
In Kerberos delegation, a service trusted for delegation can request tickets on behalf of any user or computer account by default. To exclude sensitive user accounts from being delegated on behalf of, there is a simple method through the UI: enable “Account is sensitive and cannot be delegated,” and the user is protected.
However, this “easy method” is not available for computer account objects. The ADUC console does not expose an Account tab for machine accounts, and there is very little documentation or day-to-day awareness that the same protection applies to computers.
This creates a practical blind spot. Organizations harden privileged users, but sensitive machines often stay delegable because admins do not get a clear UI indication, and most guidance focuses exclusively on user accounts.
What we’re seeing in the wild
This issue is especially concerning because it is not rare. Based on our research data, we rarely see sensitive machine accounts explicitly protected from delegation, which makes this a widespread hardening gap.
In other words, many environments still have at least one sensitive machine identity that can be delegated on behalf of, often without any operational awareness that the protection is missing.
Silverfort customers have already been alerted to this misconfiguration and have the visibility and remediation steps needed to address it in their environments.
Demo: From sensitive machine identity to DCSync
To demonstrate the danger of sensitive machine account delegation, we exploited CVE-2025-60704 against an environment with AD CS web enrollment enabled.
The attack combines two techniques at two different protocol layers. At the HTTP layer, we modified the certificate enrollment request to specify the DomainController template. This template is not listed in the web enrollment interface’s available options, but the underlying CA endpoint accepts it regardless, allowing us to request a DC-class certificate the administrator may not realize is reachable through web enrollment.
At the Kerberos layer, the web enrollment service performs constrained delegation to the DC on behalf of the requesting user. By performing an adversary-in-the-middle attack on that delegation flow (CVE-2025-60704), we exploited the missing cryptographic step to escalate from a weak user identity to the domain controller’s machine identity.
With the domain controller’s certificate in hand, we demonstrated domain dominance via a DCSync path.
This attack chain reinforces a pattern: the UI hides things from you. The NOT_DELEGATED checkbox is hidden for computer accounts. The DomainController template is hidden from the web enrollment interface. The cryptographic gap in the delegation flow is hidden from anyone who assumed the protocol was protecting integrity. Three blind spots, and one path to domain compromise.
NOT_DELEGATED flag under the hood
The UI checkbox for users ultimately sets the NOT_DELEGATED bit in userAccountControl:
- ADS_UF_NOT_DELEGATED = 0x00100000 (1048576)
Here’s the key point: userAccountControl exists on both user and computer objects. So even though ADUC does not expose the checkbox for computers, the protection still exists and still works when applied to machine identities.
If we apply the NOT_DELEGATED attribute to a computer account, the account is protected — S4U2Proxy requests targeting that account will fail, which is exactly what we want for Tier 0 machines.
Which machine accounts should be considered sensitive?
Any Tier 0 machine account should be considered sensitive and should be protected from delegation. In practice, this includes:
- Domain controllers and other Tier 0 infrastructure
- PKI and AD CS servers and enrollment tiers
- ADFS, Entra Connect, and hybrid identity bridge servers
- Identity infrastructure and management-plane systems
- Machine accounts with replication-class permissions (DCSync risk category)
- Machine accounts that can reset passwords or modify privileged identities (shadow admin style authority)
If a machine identity (NHI) can control identity, it’s sensitive.
Non-human identity security
Every NHI—in sight and under control
- Automatically discover every NHI in your environments.
- Map their activities and establish baselines.
- Enforce control and fence their activity.
Mitigation
The mitigation is straightforward and requires a single PowerShell command, as documented by Microsoft. A small change like this can remove an entire class of delegation risk and eliminate a potential attack surface.
For each sensitive machine account, run:
powershell
Set-ADAccountControl -Identity “HOST01$” -AccountNotDelegated $true
Then monitor and validate that nothing breaks. Setting this flag will cause S4U2Proxy requests targeting the protected account to fail, which means any legitimate service that is constrained-delegated to interact with this machine on behalf of other identities will stop working. Before flipping the bit, audit your msDS-AllowedToDelegateTo and msDS-AllowedToActOnBehalfOfOtherIdentity configurations to understand which services may be affected.
If something does break, investigate which application or service is attempting to delegate on behalf of a Tier 0 machine account, and decide whether that behavior is expected and acceptable. In many cases, finding that a service was delegating on behalf of a domain controller is itself a finding worth investigating.
Closing thoughts
We’ve all internalized “don’t delegate sensitive users.” The gap is that sensitive machine identities often don’t get the same treatment, because the UI doesn’t make it obvious and there is very little documentation or awareness that the same control applies to computer accounts.
This post highlighted three places where the UI hides risk from administrators: the missing NOT_DELEGATED checkbox for computers, the unexposed certificate templates in web enrollment, and the unprotected delegation flow that made CVE-2025-60704 possible. The pattern is consistent—what you can’t see in the console, you probably haven’t hardened.
Given how much of the modern enterprise control plane is powered by machine identities, this is a high-leverage hardening step: identify your sensitive machine accounts, set them as not delegable, and make it part of your Tier 0 baseline.
Learn more about non-human identity security risks and what you can do about them in our latest research report, “Insecurity in the shadows.”
Report