Trusted To Auth For Delegation

What this delegation setting does

The Trusted To Auth For Delegation attribute in Active Directory marks a service account as trusted to perform protocol transition and request Kerberos tickets on behalf of a user. In practice, that means the service can present itself downstream as the user it is acting for, so the attribute is a powerful trust decision rather than a routine account flag.

This matters because delegation is not simply about forwarding access. It establishes a security boundary: if the service is compromised, the attacker may inherit the ability to access other systems as the delegated user, subject to what downstream services accept.

Why protocol transition changes the trust model

Protocol transition allows a service to obtain a Kerberos ticket without the user first authenticating to Kerberos directly. That is useful when an application needs to accept a non-Kerberos login method and still reach Kerberos-protected back ends, but it also means the service becomes a trusted translator between authentication systems.

The important change is that the service is no longer just a consumer of identity proof, it is able to assert user identity to other services. That makes the account a high-value target, because abuse of the service can become impersonation at scale rather than a single stolen login.

For background on delegation abuse patterns and the related Kerberos mechanisms, see Kerberos Delegation Security Guide.

Where the exposure comes from

Exposure usually comes from overbroad delegation scope, weak service isolation, or allowing delegation on accounts that can reach sensitive back-end services. If the service can impersonate users to many systems, compromise of one application can become lateral movement into multiple data stores, administrative functions, or internal APIs.

Delegation also increases the impact of configuration mistakes. A service that is intended to act for a narrow application path may be able to present tickets in more places than intended, especially when administrators do not keep close track of which accounts are marked trusted for delegation and which downstream services accept those tickets.

Attackers often value this setting because it can turn one foothold into reusable user impersonation. RFC 8693 describes token exchange for delegation and on-behalf-of flows in a protocol-neutral way, which helps explain why delegated trust must be tightly bounded even when the underlying authentication stack differs.

How to control and validate it

Organisations should treat this attribute as a privileged trust assignment and keep an inventory of every account that has it. The practical control question is not just whether delegation works, but whether the account truly needs protocol transition, which services it can reach, and whether those downstream services are appropriate for impersonation.

Validation should include review of service ownership, review of the target services it can delegate to, and checks for accounts that are sensitive and should not be delegated. Where possible, constrain the trust path so the service can only delegate to the minimum required systems and only for the minimum required users or workflows.

For control mapping, the most relevant hardening themes are account and privilege governance, so the general access-control and authentication guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for review and enforcement.

Risk and Threat Considerations

This attribute creates an impersonation risk, because compromise of the service can let an attacker obtain Kerberos tickets that appear to come from legitimate users. The danger is highest where the delegated service has broad reach, handles sensitive accounts, or sits in front of multiple downstream systems.

Failure mechanism: An attacker who controls the trusted service can abuse protocol transition to request tickets on behalf of users, then reuse that delegated trust to access protected services as those users.

Impact: The result can be unauthorized access, privilege escalation through impersonation, and lateral movement into systems that rely on Kerberos delegation for trust decisions.

Practitioner Guidance

Governance implication: Treat this attribute as an exception-based trust grant, not a default application setting. Ownership should sit with the application and identity teams together, because the service owner understands the business need while the identity team can judge whether the delegation path is acceptable.

What to watch for: Review any service that suddenly needs broader delegation, any account that can impersonate privileged users, and any change that expands the set of downstream services accepting delegated tickets. Those are the moments when the trust boundary is usually being widened.

Practitioner takeaway: If a service does not truly need protocol transition, remove the trust. If it does, constrain the blast radius as tightly as the business process allows.

Related resources from NHI Mgmt Group

• What breaks when unconstrained Kerberos delegation is left enabled on application servers instead of being restricted to trusted infrastructure?
• Why do pre-auth vulnerabilities in trusted systems create outsized risk?
• Why do shared signing keys and trusted claims increase pre-auth RCE risk?
• How can organizations effectively manage access delegation for AI agents?