Topic starter
24/06/2026 10:50 pm
TL;DR: Kerberos delegation is not just a user-account problem in Active Directory: Silverfort’s research on CVE-2025-60704 shows that machine accounts can be delegated too, creating a path from weak user access to domain dominance. The missing mental model is that sensitive non-human identities need the same delegation scrutiny as privileged users.
Editorial analysis by NHI Mgmt Group, based on content published by Silverfort: “Delegation Part Two: (In)sensitive accounts”.
Key questions
Q: What breaks when a sensitive machine account is left delegable in Active Directory?
A: A delegable machine account can be impersonated in Kerberos flows, which lets an attacker turn routine service trust into privileged directory access.
Q: Why does Kerberos delegation on machine accounts create higher-risk escalation paths?
A: Because machine identities often hold authority equivalent to privileged users, delegation on those objects can convert a weak entry point into domain-level control.
Q: How do security teams find machine accounts that should not be delegated?
A: Start with Tier 0 and identity infrastructure, then identify any computer account that can influence authentication, replication, or certificate issuance.
Practitioner guidance
- Mark sensitive machine accounts as non-delegable Use the ADS_UF_NOT_DELEGATED setting on Tier 0 computer objects so S4U2Proxy requests targeting those identities fail by design.
- Audit delegation trust paths before changing machine flags Review msDS-AllowedToDelegateTo and msDS-AllowedToActOnBehalfOfOtherIdentity so you know which services depend on delegated machine identity flows.
- Inventory Tier 0 computer objects that control identity Prioritise domain controllers, AD CS tiers, federation bridges, and replication-capable machines for non-delegable treatment.
Bottom line: Kerberos delegation is not just a user-account issue, because computer objects can also be delegated and abused as part of a domain escalation path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
25/06/2026 7:40 am
Delegation risk is not a user-only control problem: Active Directory delegation logic applies to computer accounts as well as users, so the common mental model is incomplete. That matters because machine identities often sit closer to Tier 0 services than ordinary accounts do, and the attack surface changes when those objects can be impersonated in delegated flows. The practitioner conclusion is that delegation governance must explicitly include computer objects, not just privileged humans.
A question worth separating out:
Q: What should teams do when a service depends on delegation to a computer account?
A: Treat the dependency as a governance exception and verify whether the service truly needs to act on behalf of that machine identity. If the answer is yes, constrain the path tightly and document the justification. If the dependency exists only because nobody noticed it, that is a control gap worth remediating immediately.
👉 Read our full editorial: Kerberos delegation risk extends to machine accounts in Active Directory
This post was modified 5 days ago by NHI Mgmt Group