Another blog about KCD: Tips and Tricks on Kerberos and Delegation (ISA2006):
Kerberos has always been a big pain when people are not used to configuring it. But with a little patience and some clear concepts, it will have no secrets for you!
Let’s start from the start
Kerberos is based on tickets to perform authentication. When a client wants to access a service, it has to request a ticket to authenticate against that service.
This ticket is encrypted with the service key of the service account for which the ticket was requested.
To know which service key it has to use, the KDC uses the SPNs.
KDC: Key Distribution Center, service installed on the DCs. This service issues the Kerberos tickets.
SPN: Security Principal Name are account attributes that are stored in the Active Directory and that defines the service name and what port is being used (if needed). This is a very important part of Kerberos configuration. If the SPN is not configured correctly, Kerberos will fail.
The KDC will use the SPNs to encrypt the tickets with the correct service key which is why SPNs are important.
For example, ISA services run under the machine account. The following three are considered machine accounts: Local Service, Network Service and Local System.
But services can also run under a domain user account. For example, it is very common to see in IIS that the application pools are configured to run under a domain user account.
So we need to configure the correct SPN for the correct account that the service is running under.
When machine accounts are registered in AD, a generic SPN is created. This SPN is the HOST SPN. Many service classes map to the HOST service class so there is no need to register an extra SPN, unless we want to use something that is non-standard, such as:
- The service is running under a domain user account.
- The service is running under a non standard port.
- The service class is not mapped to the HOST service class.
In these cases we need to manually register the SPNs that would be applicable when the Kerberos authentication is enforced. The tool used to list, create and delete SPNs is setspn.exe. This command-line tool is included in the Windows Support Tools: http://support.microsoft.com/kb/926027 .
The SPN syntax is as follows:
<ServiceClass>/<machine name>:port domain/ServiceAccount
You can find more information on setspn.exe tool here:
Setspn Overview
http://technet.microsoft.com/en-us/library/cc773257.aspx
Service Logons Fail Due to Incorrectly Set SPNs
http://technet.microsoft.com/en-us/library/cc772897.aspx
Each account can have different SPNs defined for different services. BUT, there cannot be more than one account registered for the same service. In that case you will have duplicated SPNs. Duplicated SPNs are a very common point of failure.
In any case SPNs are something we always need to check in order to make sure that we have the correct ones and that there are no duplicated SPNs.
Correct SPNs should ensure that Kerberos will work (apart from server and client specific configurations).
But what happens when delegation comes into the picture?
Imagine the following scenario:
An ISA 2006 Server is publishing an internal web server. We have also an external client that wants to access to that published web server.
In this case, the authentication should be as follows:
- The external client authenticates to the ISA server which is publishing a web server.
- The ISA server then needs to access the web server that is configured to authenticate the users with Kerberos.
In this situation, how can the web server authenticate the client that was already authenticated by ISA? How can ISA pass the client’s credentials to the web server instead of using its own credentials?
To achieve this, we need to enable Kerberos delegation. To enable Kerberos delegation, we need to configure the service that will receive the first authentication from the client so it is able to delegate the client’s credentials to a back end server.
Kerberos delegation, in this case will allow the ISA server to request a service ticket in the name of the original client and authenticate against the web server.
If we go even further, we can use KCD (Kerberos Constrained Delegation). KCD allows administrators to restrict which services an account is trusted to delegate to. This is better than normal Kerberos delegation that enables the account to delegate to ANY service.
Kerberos delegation has to be configured on the account that needs to send the client’s credentials to the back end server. In this case it is the ISA server that will send the user’s credentials to the web server.
This is the most important concept we need to understand for Kerberos delegation. We trust an account for delegation. Not just a specific machine. As this account can be the either a machine account or a user account, we need to configure the SPN for the correct account and set this account as “trusted for delegation”.
We configure Constrained Delegation when we enable this setting in the trusted account:
Another step to all this is the use of Protocol Transition.
Protocol transition is the ability of a service to get a Kerberos service ticket for delegation in the name of the original client, no matter which authentication method did the client use to authenticate first.
We configure Protocol Transition when we enable this setting in the trusted account:
Summarizing, these are the things we need to have in mind:
For Kerberos:
- Check SPNs
- Check application is enabled to use Kerberos
- Check the client is enabled to use Kerberos (See http://technet.microsoft.com/en-us/library/cc779070.aspx for more info)
- The accounts are not marked as “Account is sensitive and cannot be delegated”
For Kerberos Delegation
- A Windows 2003 functional level domain is needed for KCD and protocol transition.
- KCD and protocol transition configuration.
- Configure delegation on the correct account.
For ISA to use KCD
The user can be part of any domain as long as the domain has bi-directional trust with the ISA domain. Check the following KB for more information:
A user cannot access a Web site that is published in ISA Server 2006 by using Kerberos constrained delegation if the user is not in the same domain as the ISA Server computer
http://support.microsoft.com/kb/942637/ (which is already included in SP1 of ISA 2006: http://www.microsoft.com/downloads/details.aspx?FamilyId=D2FECA6D-81D7-430A-9B2D-B070A5F6AE50&displaylang=en )
ISA and delegated servers must be part of the same domain:
KCD with Cross-Forest Accounts
http://technet.microsoft.com/en-us/library/cc752953.aspx
KCD is limited to machines which exist in the same domain. For example, an ISA server in domain1.forest1.tld cannot use KCD to authenticate to a published web server in any other domain, regardless of the trust relationship.
Karin Galli Bauza
ISA Server Support Engineer, Microsoft CSS