The Kerberos You Think You Know
Let’s start with what most of us remember. Kerberos is the digital bouncer for your corporate network. Instead of showing a password to every service you want to access, you prove your identity once to a central authority, the Key Distribution Center
(KDC). In return, you get a special token called a Ticket-Granting Ticket (TGT). You then use this TGT to request specific service tickets for whatever you need, whether it's a file share, a database, or an internal web app. The beauty is that your password isn't flying across the network for every request. It’s a solid system, preventing basic password sniffing and replay attacks. For most day-to-day tasks, this ticket-based flow is all we need to consider. But modern applications aren't so simple, and that’s where the trouble often begins.
The Problem That Trips Everyone Up
The complexity starts with multi-tier applications. Imagine a common scenario: a user logs into a web portal (the front-end service) that needs to pull data from a backend database on another server. The user authenticates perfectly to the web portal. But when the web portal tries to query the database on behalf of the user, it fails. This is the infamous “double-hop” problem. The web server has a service ticket that proves the user's identity to itself, but it doesn't have the authority to use that identity to ask for something from a second service (the database). The user’s initial authentication doesn't automatically follow them to the second hop. This is a security feature, not a bug, preventing any service you access from impersonating you all over the network. But it's also a functional roadblock that sends engineers searching for an easy fix.
The 'Solution' Hiding a Major Risk
In the quest for a quick solution, many engineers discover Kerberos delegation. And the first, simplest option they often find is “unconstrained delegation.” With a single checkbox in Active Directory, a service account can be trusted to impersonate any user for any service on the network. It works. Suddenly, the double-hop problem vanishes. The web portal can now access the database seamlessly. The reason it’s so easy is because it’s a legacy feature from Windows 2000, designed when security models were less mature. But this convenience comes at a terrifying cost. If an attacker compromises that front-end web server, they don’t just control the server; they can capture the TGTs of every user who authenticates, including high-privilege domain admins. With those tickets, the attacker can impersonate those users anywhere in the domain, moving laterally with near-total freedom and potentially leading to a full domain compromise. It turns a single server breach into a potential network-wide disaster.
The Safer, Smarter Approach
This is the detail that matters: you almost never need unconstrained delegation. The modern, secure alternatives are constrained delegation and its successor, resource-based constrained delegation. Constrained delegation (KCD) allows an administrator to explicitly define which specific services an application is allowed to access on a user's behalf. Instead of giving the web server the keys to the entire kingdom, you grant it permission to talk only to the specific database service it needs. If the web server is compromised, the blast radius is dramatically reduced. The attacker can't use a user's ticket to access file servers or domain controllers. Resource-based constrained delegation (RBCD) flips the model, making it even more secure. Instead of the front-end service's administrator deciding where it can delegate, the administrator of the backend resource (the database) decides which services are allowed to delegate to it. This puts control in the hands of the resource owner and further enforces the principle of least privilege.
