Enterprises have spent the last five years converging networking and security into SASE. Identity-aware access, inline inspection, microsegmentation — all designed to stop an attacker from moving freely once they land inside the perimeter. And yet breach reports keep showing the same pattern: initial access happens at the edge, but the damage happens deep inside Active Directory, where SASE controls have almost no visibility.
The gap isn’t a product failure. It’s architectural. SASE inspects traffic and enforces identity at the network layer. It was never built to understand what happens inside Kerberos, the authentication protocol still running the identity backbone of most enterprise networks. And that’s exactly where a technique called delegation abuse lives.
What Kerberos delegation actually does
Delegation exists to solve a real problem: a service (say, a web app) needs to act on behalf of a user to reach a second service (say, a database) without asking the user to re-authenticate. Windows environments implement this through three delegation models — unconstrained, constrained, and resource-based constrained delegation (RBCD). Each one lets a service request Kerberos tickets as if it were the user.
The security assumption behind all three is that only trusted, tightly scoped services get delegation rights. In practice, over-permissioned service accounts, legacy app requirements, and rushed AD configurations mean delegation rights end up granted far more broadly than intended. An attacker who compromises one of these services doesn’t need credentials, malware, or lateral movement tools that trigger EDR alerts. They ask Kerberos, politely, for a ticket — and Kerberos hands it over, because from a pure protocol standpoint, the request is completely legitimate. Hackita.it has a full technical breakdown of how Resource-Based Constrained Delegation abuse (https://hackita.it/articoli/rbcd/) plays out step by step, from attribute write to full impersonation.
Why this slips past network-layer security
This is the part that matters for anyone running a SASE stack. Delegation abuse doesn’t generate anomalous traffic patterns. It doesn’t touch the internet edge. It doesn’t require moving through a segmented zone your SD-WAN fabric is inspecting. The entire attack happens as authenticated, protocol-compliant Kerberos traffic between systems that were already allowed to talk to each other — because that communication is the legitimate business function the delegation was configured for.
RBCD abuse specifically is attractive to attackers because it can be set up by anyone with write access to a computer object’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute — a permission that’s more common than most AD admins realize, often inherited through nested group memberships nobody audited. Once configured, the attacker requests a service ticket impersonating a privileged user, and walks into the target system with that user’s rights. No password. No hash. No malware signature.
Where SASE and Zero Trust actually help — and where they stop
To be clear, SASE isn’t irrelevant here. Identity-aware proxies and continuous verification do raise the cost of initial access, and microsegmentation does limit how far an attacker can reach after landing. But once an attacker has a foothold with the right AD permissions, delegation abuse operates entirely within the trust boundaries that SASE has already approved. The network layer sees two authorized systems talking Kerberos to each other — which is precisely what it’s designed to allow.
This is the same blind spot behind other identity-layer techniques enterprises are seeing more of: Kerberoasting against service accounts (https://hackita.it/articoli/kerberoasting/) with weak passwords, ACL abuse chains that hand attackers a path to Domain Admin through misconfigured object permissions, and golden ticket attacks that forge trust at the KDC level itself. None of these show up as network anomalies, because none of them are network anomalies. They’re identity anomalies — and most SASE/SD-WAN deployments have no native telemetry into AD internals like ticket-granting requests, delegation attribute changes, or ACL modifications.
Closing the gap without ripping out your architecture
Fixing this doesn’t require abandoning SASE — it requires layering identity-specific detection on top of it. Three things move the needle:
1. Audit delegation configurations directly, not just group memberships. msDS-AllowedToDelegateTo and msDS-AllowedToActOnBehalfOfOtherIdentity should be reviewed on a schedule, not discovered during an incident — Microsoft’s own documentation on Kerberos constrained delegation (https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview) is a solid starting reference.
2. Feed Kerberos event logs (4768, 4769, 4670) into whatever SIEM already ingests your SASE telemetry, so identity and network signals sit in the same investigation timeline instead of separate silos.
3. Treat any write permission on a computer object as a privilege escalation path, not an administrative convenience — because that’s exactly what RBCD abuse turns it into.
Network security architecture and identity security architecture have been drifting apart for years, largely because they’ve historically been owned by different teams with different tools. Attackers don’t respect that boundary, and delegation abuse is one of the clearest examples of why defenders can’t afford to either. TeckNexus has already flagged this shift toward identity-based access as the sector’s next security baseline (https://tecknexus.com/utility-private-network-security-attack-surface/) — the same rethink needs to happen at the AD/Kerberos layer, not just at the network edge.
