When things go wrong with Active Directory’s (AD’s) Kerberos implementation, troubleshooting can be a daunting task. Ninety-nine percent of the time, everything just works—so opportunities to practice troubleshooting are limited. When you do need to solve a problem, it’s important to have a good technical understanding of the protocol. One of Kerberos’s most complicated configurable components is the concept of delegation.
In a nutshell, delegation lets a user access an application, and then the application accesses another service in the context of the user. A common example is a website that accesses a SQL Server database. Rather than access to the database occurring each time in the context of a service account, each request to the database is made in the context of the user accessing the website.
For background information about Kerberos in AD, see “Kerberos in Active Directory.” For the purposes of this article, let’s assume that your AD forest is running at the Windows Server 2003 or better functional level and that your application servers are running Server 2003 or later, unless otherwise noted. Server 2003 introduced numerous improvements to the Kerberos implementation in AD.
Kerberos Delegation
At a conference I recently presented at on the topic of Kerberos delegation, I asked the audience to raise their hands if they had ever had to configure Kerberos delegation. A large portion of the audience raised their hands. I subsequently asked those with their hands raised to leave them raised if they had gotten the delegation configured properly on the first attempt. Only a couple of hands remained raised. Unfortunately, little documentation exists on the topics of delegation and constrained delegation. But delegation configuration is a critical component of many enterprise applications.
As I mentioned earlier, the most common example of implementing delegation is to access an application (usually a web application) that subsequently accesses a resource such as a SQL Server database. In order to access the database, the application has to use credentials to make the connection. A common approach is to connect via a dedicated service account that has read and write access to all the necessary data in the database, as Figure 1 shows. The application is then responsible for managing access controls to the data itself because the service account has access to everything.
Another option is for the data to be controlled using SQL Server’s native access management capabilities on a per-user or per-group basis. In order for the controls to be effective, the application needs to make the connection in the context of the user who is accessing the application, as Figure 2 shows. The process under which this occurs is known as Kerberos delegation, or more frequently Kerberos constrained delegation.
In order to access the SQL Server system in Figure 2, the web server needs to obtain a service ticket to the SQL Server service. The service ticket must be for the user accessing the web application (e.g., User 1), not the web server’s service account. Thus, the web server presents User 1’s service ticket that was used to access the website (e.g., for www.contoso.com) to the Key Distribution Center (KDC) and requests a service ticket to the SQL Server system. The KDC evaluates the delegation settings in AD for the web server; if it’s permitted to delegate to the SQL Server system, the KDC takes the presented service ticket as proof that the user is authenticated and returns a new service ticket for the user to the SQL Server system. Figure 3 shows this exchange of information.
So far we’ve made the assumption that no configuration is required in AD for delegation to work as Figure 3 shows—but this isn’t the case, and for good reason. If any service could simply delegate authentication to any other service, a malicious person could lure a user to authenticate to the malicious person’s service, giving that person access to every service on the network that the unwitting user has access to.