Unable to Authenticate to Local Site? Disable Loopback Check
This one never gets old. Everytime we want to install SharePoint, we tend to continue to work on the server getting as much done as possible. And, everytime, we’re confronted with the inability to authenticate using Windows username and password and a browser on the web front end server.
You try so carefully to enter your DomainName\UserName and password exactly correctly and hit enter, enter, enter and you get a 401 or, worse, just a blank screen. As we’ve learned, what we’ve encountered is the dreaded anti-loopback monster.
Now, the ALM is a fine security measure on a server that you deploy and then spend the rest of your life as a SharePoint admin working from another workstation. It simply prevents authentication from the local machine using host headers other than the machine name. It’s detailed here on support.microsoft.com. Apparetly the threat is a “Reflection Attack” which reminds me of my mirror on the occasional Sunday morning before my shower.
Essentially, we’re creating a two registry keys:
- DisableLoopbackCheck dword registry key with a decimal value of 1 in the HKLM\SYSTEM\CurrrentControlSet\Control\Lsa hive.
- DisableStrictNameChecking dword registry key with a decimal value of 1 in the HKLM\SYSTEM\CurrrentControlSet\Services\
LanManServer\Parameters hive.
Once we restart, we should be able to access our sites locally using the propery credentials. Of course, this is a “must have” kind of thing if you’re building a development box where you’ll be accessing the WFE from the local machine in Visual Studio.
hth
-robot
Tags: