Disable Loopback Check

Disclaimer: DO NOT DO THIS IN PRODUCTION … period.  Why? The loopback check is a security feature that is designed to help prevent reflection attacks on your computer/server.  As such, it is designed to fail fail authentication if the FQDN or the custom host header that you use does not match the local computer name.

So once upon a time (several times a year at least), you decide to build a new clean virtual machine to code on, you make it pristine with every patch, service pack, cumulative update, and the latest development tools.  It is pure awesomeness.  You build your web application with your dev site collection. You open a browser to it, and boom … you get prompted for credentials.  Alright!!!! It is alive.  You login … and you login again, and again.  Uh, what just happened; Nada … a white freaking page of nothingness.  If you use fiddler (or your tool of choice) to see the response, you will notice a “HTTP 401.1 – Unauthorized: Logon Failed”.  You can try again, but are logging in just fine.  You are being denied.

Long story short, you have been denied by the Loopback check feature which has been around since Windows 2003 (SP1) and Windows XP (SP2).  A very very long time.  The loopback check is a security feature that is designed to help prevent reflection attacks on your computer/server.  Unless you create web applications starting with the local computer name, you will be denied. That is why Central Administration works fine (unless you decided to give it a FQDN).  There are to solutions explained here (and all over the place on the web): https://support.microsoft.com/en-us/kb/896861

Here is a tool that implements the recommended approach (method 1):

https://loopbackchecktool.codeplex.com/

or visit my buddy’s blog @ http://blogs.technet.com/b/sharepoint_foxhole/archive/2010/06/21/disableloopbackcheck-lets-do-it-the-right-way.aspx

Here is the simple powershell command (method 2):

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name “DisableLoopbackCheck” -Value “1” -PropertyType dword

The powershell approach is obviously the easy route.  I do encourage that you eventually look at the tool as this will be a better and safer long term approach.  For the curious, even in production, you shouldn’t have to do this in production at all.  You can diagnose just fine without it … log into to production for diagnostics should not be your first course of action.  If you have to do this, remove it after doing diagnostics … better yet, before you log off.