Delegation and unconstrained delegation: What’s the difference?
Microsoft originally introduced the concept of delegation as part of Microsoft Windows Server™ 2000 to solve a straightforward problem: Sometimes services need to access resources on behalf of another user. A common example is a web server that displays information to users from a database.
One solution is to grant the account running the web server access to the entire database. However, this creates another problem because it requires the web server to check the users’ permissions each time a request is made to ensure it only displays data that users making the request are allowed to access.
A second solution, called delegation, allows the account running the web server to impersonate users connected to it when accessing the database on their behalf. This way the web server can only display data to users that they would otherwise be able to retrieve from the database themselves. Therefore, the burden of checking user permissions falls to the database rather than the web server.
When the concept of delegation was first introduced, the only supported implementation method was unconstrained delegation. However, this type of delegation comes with one major caveat: Services configured for unconstrained delegation can impersonate users when accessing any other resource. For example, when a user authenticates to the web server, the server is not limited to accessing the database as that user. The web server can access any resource, including other web servers and file shares, as the user, even though it is only supposed to access the database as the user.
If unconstrained delegation sounds a little too permissive, that's because it is. Unconstrained delegation runs counter to the principle of least privilege, which dictates that services configured for delegation should only possess delegated access to resources they need to function correctly. Unconstrained delegation is a legacy Microsoft Active Directory™ configuration that attackers love to see, because it allows them to easily elevate their access from a standard user to holding the highest privilege in a Microsoft Windows™ environment.
Microsoft recognized the security issues with unconstrained delegation and later released constrained delegation and resource-based constrained delegation in Windows Server 2003 and Windows Server 2012 respectively to improve security.
Mechanics of unconstrained delegation
Unconstrained delegation is enabled by default and required on all domain controllers (DCs). In addition, it can be configured manually by setting the “TRUSTED_FOR_DELEGATION” flag to “true” in the userAccountControl attribute of the user running the service that will make use of delegation. The service can then delegate authentication for all accounts by default, although configuration changes can prevent delegation under specific circumstances.
The “TRUSTED_FOR_DELEGATION” flag also can be set to “true” in the userAccountControl attribute of the account that runs the web server. Unconstrained delegation can be enabled for an account by any user with the SeEnableDelegationPrivilege right. By default, only domain administrators have this right, but it can be granted to additional users.
When Kerberos authentication is used for a service without unconstrained delegation, the only information the user sends to the service is the ticket-granting service (TGS). The TGS contains the information required by the service to identify the user’s identity and permissions as well as establish a secure connection. This TGS can only be used to access the service for which it was issued. Exhibit 1 shows the process for authentication and service access without unconstrained delegation.
Exhibit 1: Authentication and access without unconstrained delegation