The last week i have been playing with the Sharepoint 2013 search feature on a upgraded Sharepoint 2010 intranet.
After enabling the search service i made a new content source pointing to this intranetsite. Changed the access acount to a serviceaccount that has full rights on this intranet. This should be enough to test things out. Lets start the crawling-maddness!
After 20 seconds the crawling wsa finished! huh? Thats strange… Its a intranet of almost 20k of files. I stumbled upon the following message:
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.
Wait a minute here! I’m using a serviceaccount with full access to the database AND the webapplication. After trying several things (including using my own account as i’m a farm administrator, and several other stupid things) this was my solution:
- Go to your registry RUN -> regedit
- In regedit navigate to: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa”
- Create a new DWORD (32-bit) Value
- You can name this DisableLoopbackCheck
- Double-click this entry and change the value ‘0’ to ‘1’
“What is the issue?
Windows Server 2003 SP1 introduced a loopback security check. This feature is obviously also present in Windows Server 2008. The feature prevents access to a web application using a fully qualified domain name (FQDN) if an attempt to access it takes place from a machine that hosts that application. The end result is a 401.1 Access Denied from the web server and a logon failure in the event log.
Unfortunately 401.1 is not really helpful as this error code means there is a problem with the user credentials. Of course, the HTTP spec doesn’t know about security features in a vendor’s implementation so there can’t be a HTTP error code for such a feature. This can lead to much banging of the head on the desk. It’s one of numerous causes of the 401.1 which are nothing to do with invalid credentials (e.g. attempting to use Kernel Mode Authentication with domain account in IIS7).
What this means is that when you browse a SharePoint Web Application which uses a fully qualified domain name from a WFE in the farm you will get a 401.1. This is very annoying on a development box, or when testing locally, or in other SharePoint specific scenario “
As i installed my Sharepoint 2013 enviroment on Windows 2012 R2 i know for a fact this problem still exists.