Disable Loopback Check
The Infamous Disable Loopback Check and SharePointWindows Server 2003 and newer implemented a security fix to disable browsing sites from within a server that do not match its hostname or the loopback address. This is detailed here by a great SharePoint man, Spencer Harbar: http://www.harbar.net/archive/2009/07/02/disableloopbackcheck-amp-sharepoint-what-every-admin-and-developer-should-know.aspx
At my current location I have setup multiple site collections on multiple web applications. I also have multiple web applications using host headers and SSL-only with a wildcard certificate. This would traditionally be a problem if I need to share data among them (and I do). Thankfully we use Kerberos and I have Kerberized all of my web applications and we are using Classic authentication with integrated windows authentication. So happily I go to SharePoint Designer to create a SOAP data source to connect to the web service on another web application or site collection, choose Windows Authentication on its login, and alas I get the dreaded Non Specific Error when I attempt to place a data view on a page using this data source. I can tell you for certain the error is not in the authentication you are using, it is the loopback check security feature on the web front end.
TroubleshootingGo to the web front end(s) that host the offending web applications. Open the ULS log viewer and capture events while you attempt to place a data view on a page using designer with your Data Source. You should get this error:
SOAP exception: System.Net.WebException: The remote server returned an error: (401) Unauthorized.
Also Look at the event logs, Security. Attempt to browse from the web front end, one of the web applications. As we are using integrated windows authentication, I get 3 prompts for credentials and they always fail. The security log at this time shows Audit Failure events:
An account failed to log on.
I had previously attempted to fix this using the recommended fix for production systems: http://support.microsoft.com/kb/926642
Method 1 (recommended): Create the Local Security Authority host names that can be referenced in an NTLM authentication requestTo do this, follow these steps for all the nodes on the client computer:
- Click Start, click Run, type regedit, and then click OK.
- Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
- Right-click MSV1_0, point to New, and then click Multi-String Value.
- In the Name column, type BackConnectionHostNames, and then press ENTER.
- Right-click BackConnectionHostNames, and then click Modify.
- In the Value data box, type the CNAME or the DNS alias, that is used for the local shares on the computer, and then click OK.
Note Type each host name on a separate line.
Note If the BackConnectionHostNames registry entry exists as a REG_DWORD type, you have to delete the BackConnectionHostNames registry entry.
- Exit Registry Editor, and then restart the computer.
This did not work. But I opened up my entries in the BackConnectionHostNames multi-line key, and they all looked good. (Hint: they were not)
For example my values are (these are fake):
corp.portal.domain.com (Browseable by https://corp.portal.domain.com)
I thought, why not try another value. I entered this: portal.domain.com, and instantly I could browse the web applications locally on the web front end and I could see the data source properly in a data view with SP Designer. I didn't even have to do an iisreset. It just worked.
Try the root domain first in the BackConnectionHostNames before trying the FQDN.