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.

SharePoint Enterprise Search – crawling Last Modified By

I was investigating why SharePoint search results were not including the refiner for Last Modified By when I came across this information.

SharePoint Enterprise Search requires certain settings in order to crawl data for Last Modified By and add to the search index.

Firstly you need a managed property – there is a default managed property called ModifiedBy but you can make your own if you wish. From the Enterprise Search Administration page, navigate to the Metadata Properties page.

The Metadata Properties page shows all managed properties for the Enterprise Search service application.

The managed property needs to be mapped to the crawled property “Office:8(Text)”. The crawled property needs to have ticked tickbox for “Include valies for this property in the search index”.

If anyone can tell me how Office:8(Text) happens to map to the “Last Modified By” attribute of an Office document, it would be much appreciated. In fact, a prize to go out to the first who can find TechNet documentation on what all the Office crawled properties are.

Finally don’t forget to run a crawl before seeing this in search results.

The PowerShell script equivalent of the above is as follows:

$searchApp = Get-SPEnterpriseSearchServiceApplication
$manangedProperty = Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $searchApp -Identity "ModifiedBy"
$crawledProperty = Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchApp -Name "8" -Category "Office" -PropSet "f29f85e0-4ff9-1068-ab91-08002b27b3d9"
$crawledProperty.IsMappedToContents = $true
$crawledProperty.Update()
New-SPEnterpriseSearchMetadataMapping -SearchApplication $searchApp -ManagedProperty $managedProperty -CrawledProperty $crawledProperty

SharePoint Enterprise Search – scripted PowerShell build

In the PowerShell script build for SharePoint 2010, references to the different components (query servers, component servers, administration component) should NOT be FQDN.

I wonder if this means

• Enterprise Search is restricted to being scaled out within a single domain
• PowerShell scripted builds need to be executed in the context of the same domain as the servers

Set-SPEnterpriseSearchAdministrationComponent -SearchApplication $searchApp -SearchServiceInstance $serverName
New-SPEnterpriseSearchCrawlComponent -SearchApplication $searchApp -CrawlTopology $crawlTopology -SearchServiceInstance $serverName -CrawlDatabase $crawlDB
New-SPEnterpriseSearchQueryComponent -IndexPartition $partition -QueryTopology $queryTopology -SearchServiceInstance $serverName

POSTSCRIPT: I found that the URI for publishing farms also does not contain FQDN server names. That is, the publishing URL is
https://appServer:32844/Topology/topology.svc
and not
https://appServer.domain.net:32844/Topology/topology.svc