Kerberos Delegation
Application and data access configurations often require fine-grained permissions,
which can create design issues and security misconfigurations.
One classic example of this lies in the Kerberos protocol
and its authentication mechanism.
For example, consider an internal web server application
that is only available to company employees.
This web application uses Windows Authentication
and retrieves data from a backend database.
In this scenario, the web application should only be able to access data
from the database server
if the user accessing the web application has appropriate access
according to Active Directory group membership.
Kerberos does not directly provide a way to accomplish this.
When the web application uses Kerberos authentication,
it is only presented with the user’s service ticket.
This service ticket contains access permissions for the web application,
but the web server service account
can not use it to access the backend database.
This is known as the Kerberos double-hop issue.
Microsoft’s Kerberos delegation solves this design issue
and provides a way for the web server
to authenticate to the backend database on behalf of the user.
Microsoft released several implementations of this including,
unconstrained delegation, constrained delegation,
and resource based constrained delegation.
These implementations solved various security issues
and each one is available at the time of this video,
providing backwards compatibility.
However, resource-based constrained delegation
requires a domain functional level of 2012.
In the next sections, we will discuss each of these delegation types
and demonstrate how they can be exploited.