Constrained delegation and resource-based delegation improve network security, but attackers can still penetrate environments.
Constrained delegation and resource-based constrained delegation are features of Microsoft Active Directory™ that were created to address many of the security issues in their predecessor, unconstrained delegation. Constrained delegation was introduced as part of Microsoft Windows Server™ 2003, and resource-based constrained delegation was introduced in Windows Server 2012 to enable restricted delegation across domains. Organizations should take steps to understand why constrained delegation and resource-based constrained delegation are safer ways to allow services to act on behalf of other users, as well as how these more secure means of delegation can be hardened to further defend against attacks.
Constrained delegation and resource-based constrained delegation: What’s the difference?Constrained delegation and resource-based constrained delegation are both forms of delegation, like unconstrained delegation. In contrast to unconstrained delegation, in which a service configured for delegation can access any target service as any user that authenticates to it, constrained delegation and resource-based delegation limit the access of services configured for delegation by restricting the target services that they can access on behalf of another user.
Constrained delegation and resource-based constrained delegation differ in where the restrictions on delegation are enforced. In constrained delegation, the list of target services that a service configured for delegation can access as another user is stored in Active Directory with the service configured for delegation in its ms-DS-Allowed-To-Delegate-To attribute. In resource-based constrained delegation, the list of services that can access a target service as another user is stored in Active Directory with the target service in its ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute.
One use case for delegation is when a web server must access a database on behalf of other users to retrieve their data and serve it on a web page. In constrained and resource-based constrained delegation, system administrators can enforce restrictions that prevent the web server from accessing any target service other than the database as another user.
In this context, constrained delegation would be configured by adding only the database server to the list of target services that the web server can access as another user. Resource-based constrained delegation would be configured by adding the web server to the list of services that can access the database service as another user. The effects of both configurations are similar, but resource-based constrained delegation has the advantage of working even when the web server and database server belong to different domains.
Two extensions to the Kerberos protocol support the modern implementation of constrained delegation and resource-based constrained delegation: Service for User to Self (S4U2self) and Service for User to Proxy (S4U2proxy).
S4U2self allows a service to request a service ticket to itself as another user. If the service account has its TrustedToAuthForDelegation flag set, then the service ticket returned is marked as forwardable; otherwise, it is not. Both forwardable and nonforwardable service tickets can be used with the S4U2proxy extension to access a different resource on behalf of another user. The intended use case for S4U2self is to allow services not compatible with Kerberos authentication to access resources as other users.
In Exhibit 1, a service (service A) uses S4U2self to request a ticket-granting service (TGS) ticket that allows access to itself as a privileged user (user P), and the ticket returned is only forwardable when the user running service A (user A) is set as TrustedToAuthForDelegation.