Understanding Kerberos Double Hop

Ned Pyle · ‎Apr 04 2019

First published on TechNet on Jun 13, 2008

Hi, Steve here. Kerberos Double Hop is a term used to describe our method of maintaining the client's Kerberos authentication credentials over two or more connections. In this fashion we can retain the user’s credentials and act on behalf of the user in further connections to other servers.

Please make sure you read the previous Kerberos for the busy admin post as I will reference terms used in that blog frequently.

The Kerberos TGT is the user’s identity. When we pass this ticket along with the service ticket we can re-use the KrbTGT to request other service tickets to speak with our service resources on our network.

There are requirements for a service to be able to perform Kerberos double hop. The service account needs to be trusted for delegation. Meaning it must be trusted to act upon another user’s behalf. Source and target servers must be in the same forest or there must be a forest level trust between forests and the first level service account must be in the trusted forest root.

How it Works:

Step 1 - Client provides credentials and domain controller returns a Kerberos TGT to the client.

Step 2 - Client uses TGT to request a service ticket to connect to Server 1.

Step 3 - Client connects to Server 1 and provides both TGT and service ticket.

Step 4 - Server 1 uses the clients TGT to request a service ticket so Server 1 can connect to Server 2 .

Step 5 - Server 1 connects to Server 2 using the client’s credentials.

Specific Example:

Client is running IE7 and connecting to a web server that is using windows authentication. The client machine needs to be a member of the forest or a trusted forest and IE needs to be enabled for integrated windows authentication.

Web server machine name WEB1.mydomain.com and is using a service account, mydomain\webadmin. The webadmin account has SPN registered for both HTTP/WEB1 and HTTP/WEB1.mydomain.com. The webadmin account is enabled for constrained delegation to MSSQLSVC/SQL1.mydomain.com.

The SQL server machine name is SQL1.mydomain.com and is service account for SQL is mydomain\sqladmin. The sqladmin account has SPN’s registered for MSSQLSVC/SQL1.mydomain.com.

In the example configuration above the client is connecting to http://web1 to get access to data that is stored on a backend SQL server named SQL1. The web page hosts the code that retrieves the data from SQL. The user account is used to authenticate to the web server. The web server uses its constrained delegation ability to request a Kerberos ticket on the user’s behalf for connection to SQL1. If we were to audit the connections we would see the users account is being used to access the web page and the data on the SQL server. This is a classic example of Kerberos double hop but we could easily expand the scenario to include more hops. We could theoretically keep expanding the example as long as we enable delegation and retain the correct service principal name registrations.

Constrained vs. General Delegation:

General delegation will allow the first hop server to request Kerberos tickets on the client behalf to any other resource in the forest.

Constrained delegation is not supported by all Kerberos aware applications. The domain functional level must be 2003. It allows the administrator to selectively allow an account to request Kerberos tickets limited to specific services on specific servers. This is a much more secure method of delegating Kerberos delegation. The service accounts and the computer accounts hosting the applications need to be in the same domain. If the service account is a user account the delegation tab maybe missing. Until the account has a service principal name registered for it there will not be a delegation tab and you will not be able to setup constrained delegation.

Protocol Transition:

So far we have assumed the client is using Kerberos. Common scenarios where Kerberos is not used are when the client does not support Kerberos. In these examples the initial authentication to Server 1 can be transitioned into a Kerberos request in order to maintain the client’s credentials when connecting to Server 2.

Samples of method of protocol transition - http://technet2.microsoft.com/windowsserver/en/library/c312ba01-318f-46ca-990e-a597f3c294eb1033.msp...

Troubleshooting and Common Problems:

Setspn.exe will help confirm the service accounts have the proper service principal name registered correctly.

At each stage one of the members requests and receives a Kerberos ticket. These tickets are cached on the client and the front end servers. We can use Klist.exe or Kerbtray.exe to examine our cache. Frequently when there are configuration problems the client will be prompted for credentials and this may mean NTLM is being used instead of Kerberos. NTLM credentials cannot be delegated off the system so authentication to the backup server will be in the form of anonymous authentication.

We can increase Kerberos event logging ( KB262177 ) When kerberos authentication is failing and we have increased the logging level we should see indicators in the system event log for kerberos errors.

A packet capture utility may also be useful in recording the Kerberos requests and responses. Make sure to clear the client cache before enable a utility like Network Monitor. You could filter on Kerberos, use care that Kerberos requests may use the default UDP port 88 or fail over to TCP port 88.

Guides: