Trusted For Delegation in Services for User (S4U)

First published on CloudBlogs on May, 09 2008

A while back I did a blog post regarding the user interface and settings for configuring a service account correctly to allow the more complex Kerberos delegation scenarios to take place.

I recently had a customer issue I helped with that gave a good clear symptom as an example of when things are not working and what to do.    This post mostly derives from the fact that, when I reviewed my prior blog post it was apparent that this was a complicated deal, and not easy to follow.  Hopefully this post will help make things a bit easier to understand and fix.

In the customer’s scenario they had an protocol transition and delegation scenario where the interaction was clientàmiddle tier serveràback end server.  The clientàmiddle tier authentication was using SSL/TLS and, once at the middle tier, the service account which the application server process was running under would transition to Kerberos as the user identity and then impersonate the user.  The impersonation would allow that middle tier service to request access to the back end resources, and then request and receive a service ticket for use at the back end server.  Once the ticket was at the middle tier the application would provide it to the back end server’s resource which the user needed access to and provide that ticket as it’s authentication for that resource.

The part that was failing was that, unless the application service at the middle tier was running under the System account, the user would fail to get access to the back end resource.  No overt errors would really occur in the operating system; instead the customer would see a failure on the client side to access the back end resources they need.

OK, so we’ve outlined the general scenario, now let’s talk about the other symptoms.

Network traces taken from the middle tier showed that the user’s service ticket was requested and received without error.   (For services for user calls a ticket granting ticket is not required.)  The application at the middle tier did not show GSS visible negotiation on the wire so it was difficult to say whether that ticket was being provided to the back end server at all.

In this case we decided to enable Kerberos debug logging on the middle tier in order to show debug entries for those Kerberos calls taking place.  This is not something we typically do lightly as these entries are difficult to understand without access to our source code typically.  This method is described in the Troubleshooting Kerberos Whitepaper .  I’m placing the steps here for your convenience:

How to turn on debug output (open this in Wordpad):

1. Click Start, click Run, type regedit.exe, and then press ENTER.

Caution: Incorrectly editing the registry might severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

2. Open the following registry key:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters

3. Create the following entry:

Value: KerbDebugLevel

Type: DWORD

Data: c0000043 (this value will print the most standard set of debug messages. Try it first. If you still want to see more output, set it to ffffffff).

4. Create the following entry in the same registry location:

Value: LogToFile

Type: DWORD

Data: 1

5. Reproduce the error.

6. Open the file lsass.log, located in the System32 directory of your Windows folder. You can find the debug output inside this file.

Note: After you have obtained the necessary output, delete the two registry keys that you added in order to return the system to its full performance.

In this case however, and as the main point of this blog post, we are able show a sequence that-if you see it-can tell you what to do to fix this.  Once you’ve opened the log search for a sequence like below.  Simply using Find is a good bet.

[ 1/29 11:14:20] 411.334> Kerb-Warn: KerbGetTgsTicket KerbCallKdc: error 0x1b

[ 1/29 11:14:20] 411.334> Kerb-Bnd: KerbInsertBinding binding cache disabled

[ 1/29 11:14:20] 411.334> Kerb-Bnd: Calling kdc 192.169.1.5 for realm CONTOSO.COM

[ 1/29 11:14:20] 411.334> Kerb-U2U: KerbGetS4UServiceTicket returning u2u SKEY

[ 1/29 11:14:20] 411.334> Kerb-Cred: Cant go off box w/ non-fwdble logon session & no supp creds

The above entry, at the last, suggests that the service account may not have all of the configuration necessary to allow it to forward to a remote host a ticket it has received for an impersonated user.  This can occur for other reasons, but the what you want to check is to review your service account using LDP.EXE.  The useraccountcontrol attribute should have a 1 at the seventh place.  For an otherwise blank useraccountcontrol attribute (which you will never see in a working environment) this would appear as 0x1000000.  If you are missing this flag then add it; in other words, if your useraccountcontrol attribute value is 0x410200 when you see the above failure then alter it to be 0x1410200.

These values will appear in hexadecimal in AD and when viewing in LDP.EXE, so be sure to use CALC.EXE and translate them from hexadecimal to decimal for editing.  There's a convenient radio button there in CALC.EXE that works well for that after you paste the value in.   So for the useraccountcontrol value of 0x1010200 you would have a decimal value of 16843264.  ADSIEDIT.MSC will only accept a decimal update and will give you an error if you try to enter it in hexadecimal-keep that in mind!

Here’s an easy way to see if you have that set.  When viewing it in LDP.EXE, if the needed flag is set appropriately, you will see this text appear: UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION.   And what blog post would be complete without a screenshot of something?  So here’s a screenshot of what you should see with that useraccountcontrol flag being present.

Hopefully this post helps clarify things a bit and prevents intense headaches that may otherwise occur when trying to get your authentication working using a service account.