SharePoint 2010 crawl error with Kerberos constrained delegation KDC_ERR_BADOPTION

I have a SharePoint 2010 environment set up to use SQL Server Reporting Services in SharePoint integrated mode.

I have followed the guide from Microsoft to configuring SharePoint Kerberos (http://www.microsoft.com/en-au/download/details.aspx?id=23176)

I have enabled Kerberos event logging (http://support.microsoft.com/kb/262177)

I am now getting errors in the System log file every hour per my search incremental crawl schedule.
A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 22:56:15.0000 4/1/2013 Z
Error Code: 0xd KDC_ERR_BADOPTION
Extended Error: 0xc0000272 KLIN(0)
Client Realm:
Client Name:
Server Realm: <>
Server Name: <>@<>
Target Name: <>@<>@<>
Error Text:
File: 9
Line: f09
Error Data is in record data.

A bit of investigation later, I found this on the Active Directory Team blog http://blogs.technet.com/b/askds/archive/2012/07/27/kerberos-errors-in-network-captures.aspx

If the domain controller returns KDC_ERR_BADOPTION, it means that one of the KrbFlags set in the KdcOptions is not allowed… The most common scenario is a request for a delegated ticket (unconstrained or constrained delegation)… There are several reasons for rejection…

The request was for a constrained delegation ticket to itself (constrained delegation is designed to allow a middle tier service to request a ticket to a back end service on behalf on another user, not on behalf of itself).

Now hang on, what was it that the Microsoft guide said? (http://technet.microsoft.com/en-us/library/gg502602(v=office.14).aspx)

Note:
It may seem redundant to configure delegation from a service to itself, such as the portal service account delegating to the portal service application, but this is required in scenarios where you have multiple servers running the service. This is to address the scenario where one server may need to delegate to another server running the same service; for instance a WFE processing a request with a RSS viewer which uses the local web application as the data source. Depending on farm topology and configuration there is a possibility that the RSS request may be serviced by a different server which would require delegation to work correctly.

So if that particular scenario provided by Microsoft applies to your situation, go ahead and configure constrained delegation for the service account to itself, but expect to see these errors in the System log.

My conclusion from all this? It seems that Kerberos configuration is different for everyone, almost impossible to learn, and that the SQL stack of products needs to be claims aware as soon as possible.

PerformancePoint, Kerberos, Claims To Windows Token Service, and unhelpful error messages

A user complained that PerformancePoint was not configured correctly.

“See? SharePoint told me so!”

You check the logs and find this on the application server running the PerformancePoint service.

And corresponding in the SharePoint ULS log on the same server.

The user "DOMAIN\User" attempted to access an item in the following location: http: //SharePointServer/Data Connections for PerformancePoint/1_.000

Verify that the location exists and that the user has the "Read Items" permission.

Exception details: Microsoft.PerformancePoint.Scorecards.BpmException: The item 'http://SharePointServer/Data Connections for PerformancePoint/DataSource.rsds' is not a valid PerformancePoint Data Source. Check to make sure the content type of this item is correct.

However you can also find things related to Claims to Windows Token Service in ULS log.

SPSecurityContext.WindowsIdentity: Could not retrieve a valid windows identity for NTName='DOMAIN\User', UPN='User@DOMAIN'. UPN is required when Kerberos constrained delegation is used. Exception: System.ArgumentException: Token cannot be zero.

The following data source cannot be used because PerformancePoint Services is not configured correctly.

Data source location: http: //SharePointServer/Data Connections for PerformancePoint/5_.000 Data source name: New Data Source

Monitoring Service was unable to retrieve a Windows identity for "DOMAIN\User".

Verify that the web application authentication provider in SharePoint Central Administration is the default windows Negotiate or Kerberos provider.

If the user does not have a valid active directory account the data source will need to be configured to use the unattended service account for the user to access this data.

The best hint at the gremlin in the system is the error “Token cannot be zero” from the Claims to Windows Token service. The SharePoint system attempts to change the claims token to a windows token, but the service is just returning null. Basically this is a permissions error for the Claims to Windows Token Service identity.

If you read the SharePoint 2010 Kerberos Guide, particularly the chapter on configuring PerformancePoint, you would understand that there is a relationship between PerformancePoint and Claims to Windows Token Service. Too bad it doesn’t tell you how to fight system gremlins, but not to worry… that’s why I’m here.

The domain account you are using needs a few things to be able to successfully run the Claims to Windows Token service.

• Local administrator on the application server running PerformancePoint

And in Local Security Policy (secpol.msc)

• Act as part of the operating system
• Impersonate a client after authentication
• Log on as a service (the service account will probably already be here if it is running a service)

I found two gotchas in this particular environment.

• Windows group policy removed the Claims to Windows Token service account from local administrator. Contact your friendly Windows/Active Directory administrator for assistance on this.
• After the permissions are applied the Claims to Windows Token service account needs to be restarted in order to apply the permissions. If you do not restart the service, your user will still be getting the error message!