Category: Authorization Concepts

Constrained Delegation

Also known as: KCD, Kerberos Constrained Delegation

Simply put

Constrained delegation is an Active Directory feature that lets a service act on behalf of a user, but only toward a specific, approved set of other services. Instead of allowing a service to impersonate users to anything on the network, it limits where that service can act, creating a trust boundary. This makes it a more restricted alternative to unconstrained delegation.

Formal definition

Constrained delegation (Kerberos Constrained Delegation, KCD) is a Kerberos-based delegation mechanism in Active Directory that permits a configured service to impersonate a user and obtain service tickets to a defined list of downstream services, rather than to any service on the network. Per Microsoft's documentation, it lets service administrators specify and enforce application trust boundaries by limiting the target services to which an application service can act on behalf of a user. Configuration typically involves specifying the allowed target SPNs on the delegating service account, and profiles such as Service for User (S4U), including Kerberos-only constrained delegation, govern how the service acquires tickets on the user's behalf. Note that constrained delegation carries security implications: as reflected in the offensive-security sources, compromise of a service account configured for constrained delegation can allow an attacker to impersonate users to the permitted target services. This entry concerns the AD/Kerberos delegation feature; resource-based constrained delegation (RBCD) and delegation semantics in other protocols are out of scope here.

Why it matters

Delegation is a necessary capability in multi-tier applications, where a front-end service must access back-end resources on behalf of an authenticated user rather than under its own identity. The risk is in how broadly that delegation is scoped. Unconstrained delegation permits a service to impersonate a user toward any service on the network, which effectively hands the delegating service the ability to reuse a user's identity anywhere. Constrained delegation exists to narrow that blast radius: per Microsoft's documentation, it lets service administrators specify and enforce application trust boundaries by limiting the target services to which an application service can act on behalf of a user.

That scoping matters because it turns a security control into an explicit, auditable boundary rather than an open-ended grant. Even so, constrained delegation is not risk-free. As reflected in the offensive-security sources, if a service account configured for constrained delegation is compromised, for example, by an attacker who obtains SYSTEM-level privileges on a machine account configured for delegation, that attacker can impersonate users to the permitted target services. In other words, the trust boundary limits where abuse can occur, but compromise of the delegating account still exposes everything within that boundary.

For architects and administrators, this makes the precise configuration of allowed target services a security-sensitive decision. The value of constrained delegation depends entirely on keeping the list of permitted downstream services as tight as the application actually requires, and on protecting the delegating service account itself, since it becomes a high-value target once configured for delegation.

Who it's relevant to

Active Directory and Windows administrators

Administrators who configure service accounts are responsible for setting the allowed target SPNs and choosing the appropriate delegation profile, such as S4U-based Kerberos-only constrained delegation. Getting the scope right, permitting only the downstream services an application genuinely needs, is the core operational task, since the trust boundary is only as tight as the configured target list.

Security architects

Architects evaluating multi-tier application designs use constrained delegation to enforce explicit application trust boundaries, as opposed to the broader exposure of unconstrained delegation. They should weigh it as a more restricted alternative rather than an inherently safe one, accounting for the fact that a compromised delegating account can still impersonate users to any of its permitted targets.

Red teams and defensive security practitioners

Offensive-security practitioners target service accounts configured for constrained delegation because compromising such an account, including via SYSTEM-level access to a delegation-configured machine account, can enable impersonation of users to the permitted target services. Defenders correspondingly need to treat these accounts as high-value assets, monitor their configuration, and constrain the permitted targets.

Compliance and audit teams

Because constrained delegation defines an explicit trust boundary, auditors can review which service accounts hold delegation rights and which target services they are permitted to reach. Reviewing these configurations helps confirm that delegation grants remain limited to what applications require and that no account has been left with overly broad delegation scope.

Inside KCD

Service-for-User (S4U) extensions

The Kerberos protocol extensions that underpin constrained delegation, typically comprising S4U2Self (which lets a service obtain a ticket to itself on behalf of a user) and S4U2Proxy (which lets a service request a service ticket to a downstream service on behalf of that user). Exact behavior depends on the Kerberos implementation and domain configuration.

Allowed target service list (msDS-AllowedToDelegateTo)

The configuration element that restricts which downstream services a delegating service may obtain tickets for on behalf of a user. This scoping is what makes the delegation constrained rather than unconstrained, and it is defined per service account in most Active Directory deployments.

Resource-based constrained delegation (RBCD)

A variant in which the trust relationship is defined on the target (resource) service account rather than on the delegating service, typically via an attribute such as msDS-AllowedToActOnBehalfOfOtherIdentity. This shifts control of who may delegate to the owner of the resource being accessed.

Impersonated principal (the delegated user identity)

The end-user identity whose access rights the intermediate service uses when calling a downstream service. Constrained delegation is an authorization mechanism for forwarding a user's identity to backend services; the initial authentication of that user occurs as a separate, prior step.

Protocol transition

An optional capability, associated with S4U2Self, that allows a service to obtain a delegable ticket for a user who authenticated by a non-Kerberos means. Whether this is permitted depends on account configuration and is a distinct, more privileged setting than delegation without transition.

Common questions

Answers to the questions practitioners most commonly ask about KCD.

Is constrained delegation just a way for a service to authenticate as another user?

Not quite. Constrained delegation is fundamentally an authorization concern layered on delegated authentication: it allows a service to obtain and use credentials to act on behalf of a user, but it constrains which downstream services that delegation may target. The identification and authentication of the original user typically happen upstream; constrained delegation governs what the intermediary is permitted to do with the resulting delegated identity, and to which specific services. Treating it purely as an authentication mechanism blurs the distinction between verifying who the principal is and determining what the intermediary may do on their behalf.

Does 'constrained' mean the delegated ticket or token is encrypted and therefore protected from misuse?

No. The 'constrained' in constrained delegation refers to a restriction on the scope of delegation, namely, limiting delegation to an explicitly defined set of target services rather than allowing unconstrained (open-ended) delegation to any service. It does not, by itself, describe whether credentials are encrypted. A signed artifact establishes integrity and authenticity, and an encrypted one establishes confidentiality; those are separate properties from the delegation constraint. Whether the underlying credentials are signed, encrypted, or both depends on the protocol and deployment configuration.

How do I decide which target services to include in the constraint?

In most deployments, the constraint should enumerate only the specific downstream services an intermediary genuinely needs to reach on a user's behalf, following least-privilege principles. Start from the actual service-to-service call paths the application requires, and avoid adding services speculatively. The precise mechanism for expressing the allowed target set, and its granularity, depends on the platform and configuration, so validate against your environment's documentation before finalizing the list.

How does constrained delegation interact with segregation of duties and access reviews?

Constrained delegation is a runtime enforcement concern, but the delegation relationships it enforces should be treated as governed access that appears in your IGA processes. In most environments, the configured delegation permissions represent standing entitlements that warrant inclusion in access certification and periodic review, and they can carry segregation-of-duties implications if an intermediary can reach services that would otherwise be separated. Keep the lifecycle management of these grants distinct from the real-time enforcement that applies them at request time.

What should I monitor or log for constrained delegation in production?

Depending on your platform's capabilities, it is generally advisable to log when delegation occurs, which intermediary service initiated it, the original principal on whose behalf it acted, and the target service reached. This supports auditing that delegation stayed within the configured constraint and helps detect attempts to reach services outside the permitted set. The specific events and fields available vary by vendor and protocol, so confirm what your implementation exposes.

How do I test that a constrained delegation configuration is actually restricting scope?

A practical approach is to verify both the allowed and disallowed paths: confirm the intermediary can act on the user's behalf against each intended target service, and confirm that attempts to reach a service outside the configured set are rejected. Testing the negative case is what actually demonstrates the constraint is effective rather than merely that delegation works at all. The exact tooling and error behavior for a denied target depend on the platform and profile in use.

Common misconceptions

Constrained delegation authenticates the downstream user, so the backend service can trust it as proof of who logged in.

Constrained delegation is an authorization/identity-forwarding mechanism, not the original authentication event. The user's identity is typically established in a prior authentication step; delegation forwards that identity to specified downstream services. The two steps should not be conflated.

Constrained delegation and unconstrained delegation differ only in name and are otherwise equivalent.

Constrained delegation restricts the specific downstream services a service may impersonate a user to, via an allowed-target configuration, whereas unconstrained delegation places no such scoping. The constrained model exists specifically to limit the blast radius that unconstrained delegation leaves open.

Resource-based constrained delegation (RBCD) is just another way to configure the same trust as classic constrained delegation.

RBCD relocates where the trust is defined: control moves from the delegating service to the target resource's account. This changes who administers the relationship and, depending on deployment, has different privilege and security-review implications than the classic delegating-service-side configuration.

Best practices

Prefer constrained delegation (or resource-based constrained delegation) over unconstrained delegation to limit which downstream services an intermediate service can access on behalf of a user.

Maintain an explicit, minimal allowed-target service list so each delegating account can reach only the specific backend services it genuinely requires.

Treat protocol transition as a privileged capability and enable it only where a non-Kerberos-authenticated user must be delegated, reviewing those accounts more closely.

Regularly audit delegation-related account attributes and target lists as part of access reviews, since these settings grant standing identity-forwarding capability.

Consider resource-based constrained delegation where the resource owner should control who may delegate to it, and document which model each relationship uses to avoid confusion during review.

Verify configuration and behavior against your specific Kerberos implementation and domain profile rather than assuming uniform behavior, as delegation specifics vary by deployment.