KDC_ERR_BADOPTION when attempting constrained delegation

Hit this earlier while working with someone else on a Kerberos delegation problem.

All the SPNs looked right and were registered against the right accounts; all the App Pools were Network Service; from what I'd been told, everything should have been working... but wasn't. More troublingly, it had been working at one point. But why!?

We checked that Kerb was working from the client to the first tier, then grabbed a network capture from the web server while trying to reproduce the problem.

The trace showed us a KDC_ERR_BADOPTION in response to a TGS request for http/targetserver.example.com , but looking it up didn't yield any likely results (until after we knew where to look).

In short - if everything else is right, chances are this error means that the middle tier (or however far you've got - whatever machine is acting as the KDC client at this point) isn't able to delegate.

We checked delegation options for the middle tier account, quickly popped them into "Trusted for delegation", and whop, it was working. Now we have a working baseline, confidence is restored, and they're going to implement constrained delegation later. The reason it worked once before: ticking "trusted for delegation" was one of a batch of changes implemented and rolled back during troubleshooting.

I updated my wiki with a useful* batch file that searches msds-allowedtodelegateto attributes as well as serviceprincipalname attributes.

It's documented in Technet already, but the search excerpt I got put me off initially:

https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

The SPN to which the client is attempting to delegate credentials is not in its Allowed-to-delegate-to list.

Resolution

1.Use Network Monitor to determine the SPN to which the client is attempting to delegate credentials. You will need this information in a later step.

2.Click Start, click Run, and then open Active Directory Users and Computers by typing the following:

dsa.msc

3.Right-click the user or service account that has problems authenticating, and then click Properties.

4.Click the Delegation tab.

5.The Allowed-to-delegate-to list is the list of servers shown under the heading, Services to which this account can present delegated credentials.

6.Add the SPN the client is attempting to delegate to (information from the captured data you obtained in Step 1) to the Allowed-to-delegate-to list for that client. This will tell the KDC that this client is indeed allowed to authenticate to this service. The KDC will then grant the client the appropriate ticket.

For information about setting up service accounts for delegation, see “HOW TO: Configure Computer Accounts and User Accounts So That They Are Trusted for Delegation in Windows Server 2003 Enterprise Edition” in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=23067 .

(or)

• The server does not support constrained delegation or protocol transition. (Windows 2000 does not support constrained delegation or protocol transition.)

Comments

• Anonymous
  January 01, 2003
  PingBack from http://feeds.maxblog.eu/item_1292686.html

• Anonymous
  January 01, 2003
  Anon: thanks - that's why the relevant bit was excerpted. Think the same doc is available here now: download.microsoft.com/.../Troubleshooting_Kerberos_Errors.DOC

• Anonymous
  January 01, 2003
  Too many moving parts to be definitive, so here's how I'd think about it: I'd go to first principles on that - is everything set up correctly at the SPN level? blogs.technet.com/.../spns-r-fn.aspx Does a network trace confirm the SPN referred to by the client (at whichever hop you're having a problem with) is the one you're expecting, and that it's associated with the right account? (more tips on that here blogs.technet.com/.../configuring-kerberos-for-sharepoint-farms-a-generic-gotchas-list.aspx) Are AllowedToDelegateTo SPNs set appropriately for any middle-tier accounts? Do any accounts have the "sensitive and cannot be delegated" bit set? The SPNs essentially form the "account map" of service names to account names, and then the "bad options" tend to be from account settings for those accounts, in my experience.

• Anonymous
  January 14, 2013
  The link www.microsoft.com/.../tkerberr.mspx ... is bad.

• Anonymous
  February 06, 2013
  The comment has been removed

• Anonymous
  July 12, 2015
  If you have a shared service account in IIS across the app pools, try to config "useAppPoolCredentials = True".