After recently converting our SharePoint farm's authentication method from NTLM to Kerberos for Excel Services, PerformancePoint, and SSRS Integration among other things in a distributed environment, I found that People Search stopped working. Search for all other content within our content sources, both inside and outside of SharePoint, continued to work just fine. However, when you perform a search within the People Search, no results would be displayed.
To resolve this, I went into Application Management within the Central Administrator and Extended the web app that MySites were on (which is where the search gathers its People info for during an index) and created a new site that was using NTLM authentication instead of Kerberos. Next, I changed our content source in the SSP's Search Settings so that the People Search utilized the new MySite site instead of the normal one that is using Kerberos - sps3://mysite.domain.com:5556 instead of sps3://mysite.domain.com
Run a full crawl and Voila! - People Search started working properly.
To cut down on the possibility that someone would stumble across the new site and utilize it without Kerberos Authentication, I restricted access to this site via an IIS 7 Authorization Rule so that only the SharePoint service accounts are allowed to access that site. I also created a Server Name Mapping in Search Settings so that anything found in mysite.domain.com:5556 would be automatically rewritten as mysite.domain.com so that users won't know the difference.
Mike Laurencelle
I'm a SharePoint & Server Systems Administrator for Sears Home Improvement Products, headquartered in sunny Longwood, Florida. My primary functions revolve around SharePoint and Virtualization technologies.
I've been in the IT industry now for about 18 years. For me, IT is more than a job to make a living, more than a career to call my own. It's my passion. I am a self proclaimed geek and have interest in all things technology. I can't imagine being in any other field - I absolutely love what I do.
I found myself very frustrated earlier this week when I found that SharePoint search was not working. It wasn't returning any errors when you submitted a search. It just wouldn't provide any results.
After a quick glance at the error logs, I found I was getting an Event ID 2436 saying Access Denied:
Details: Access is denied. Verify that either the
Default Content Access Account has access to this repository, or add
a crawl rule to crawl this repository. If the repository being crawled is a
SharePoint repository, verify that the account you are using has
"Full Read" permissions on the SharePoint Web Application
being crawled. (0x80041205)
Naturally, I immediately checked my Web Application Policy to confirm that my Search account had Read Access in case someone inadvertantly removed it. However, it was still there.
After about half the morning of removing and re-adding permissions and resetting passwords and re-creating the index, I finally found several posts pointing at the .NET 3.5 SP1 update causing this problem. Sure enough, the update had been installed over the weekend.
Thankfully, this one was an easy fix that could be done on the fly. Open RegEdit and go to HKLP\System\CurrentControlSet\Control\Lsa and create a new DWORD value named DisableLoopbackCheck. Then, set the value to 1. Lastly, restart the WSS Search service and then run the following from a command line to initiate a full crawl:
stsadm -o spsearch -action fullcrawlstart
Within a couple minutes, search was back online and users were happy.
0