harbar.net component based software & platform hygiene

DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Print | posted on Thursday, July 02, 2009 9:06 PM

Earlier today a Twitter conversation amongst some SharePoint people including my good buddies Todd Klindt and Rick Taylor took place on the subject of the infamous “loopback fix”. I promised to do a follow up post here to clear up some misconceptions about this subject with respect to SharePoint.

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 scenarios (more on those later).

 

OK, so what’s the big deal here?
Microsoft call this a security feature. Spence calls this a security fix! There are many exploits which attempt to attack via reflection – i.e. pretending to be local as to bypass constraints. This setting should have been in the box since Windows NT4, but it wasn’t. Microsoft have done the right thing and addressed the problem based on customer feedback and exploits. They have fixed a hole and further tightened the attack surface of a Windows server. Good Job. Anyone who cares about host security or platform hygiene knows it makes sense.

 

But it breaks my SharePoint, dang it!
Yup, it does. But only if you are attempting to access a Web Application from a server hosting it (i.e. locally). You shouldn’t be doing that. Well, you shouldn’t be doing it in production. If you or your company admins are testing locally you have bigger problems that a pesky security fix.

The trouble is there are also scenarios where this fix will break normal operations of SharePoint.

  • Search Indexing.
    If you are hosting the WSS Web Application Service on your Indexer for the purposes of having a “Dedicated Crawl Front End” and avoiding a network hop. This is common in small scale “Medium Server Farms”. Because the Indexer is crawling itself, the crawl log will fill up with 401s and your content won’t get indexed.
  • Web Application “Warm Ups”.
    If you are running a scheduled task or timer job to hit the Web Application to avoid the start up lag after an application pool recycle, the “warm up” will fail with a 401.
  • Custom Code using SharePoint Web Services.
    If you have custom code, either in SharePoint or out with it that leverages SharePoint Web Services (such as using the ExcelService API) these requests will fail with a 401.

Okay, so get to the point what should I do?
Microsoft’s KB Article 896861 details two workarounds. One is to disable the Loopback Check entirely – and this is commonly promoted as the thing to do on all your SharePoint Servers. The second is to add a list of addresses to exclude from the check. Both of these are accomplished by means of a registry key in the LSA hive.

So which one should you use? The answer, of course is, it depends.

If you are working on a development environment or on just a single MOSS box – go for it - disable it completely. You need to debug and test locally and it’s likely you don’t know what addresses you will use ahead of time. I as a matter of course disable the check as part of my sysprep build for all my development and test machines. I never hit the problem because my base image is all sorted as I want it. I recommend you do the same.

However, for production environments, DO NOT DISABLE this feature. You are unpicking a serious security check of the OS. If that environment underwent a security audit by a competent security engineer, it would be flagged. You should add a list of addresses you wish to exclude. This makes your scenario work whilst retaining the security check (which is important if you are handing over the environment to your customer’s admins who may decide to browse the interwebz from the console :)).

It’s not that big of a deal to figure out which addresses you need to exclude, and on what machines you need to apply the change. If you can’t do this quickly, you don’t understand your topology or services.

This change can of course be applied by Group Policy, so should you need to do it on a bunch of boxes (e.g. five WFEs with custom code using SharePoint Web Services) the overhead is avoided. Of course this assumes you are using GPOs to manage your SharePoint Servers (you should be). GPOs are also useful if you need to add additional addresses later on.

Another advantage of using the list, is the change does not require a reboot of the server to take effect, just a restart of the IISAdmin service.

Of course this is a lifecycle issue and like anything else, you should weigh the security risk versus additional complexity on a per implementation basis to make the right call. And more important than this, is you need to document the configuration.

In addition as a consultant or otherwise, if you are hitting 401s that don’t make sense – check this, along with Kernel Mode AuthN and Local Intranet Zone before anything else. Just like everyone else this problem has had me scratching my head for a couple hours. So remember this issue when diagnosing the dreaded 401!

 

Conclusion
The loopback check is a good thing, not a bad thing, if you care about security and platform hygiene. Do not disable this feature in production. Feel free to disable it in development/test environments. Todd is also planning to spend some time on this subject in his next netcast.

Feedback

Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

I totally agree with both the fix and how to apply for production versus dev/staging.

I also had customer situations unrelated to SharePoint (the 'issue' is after all simply with any web sites Windows 2003 SP1). Some customers rely on the host files instead of DNS entries for custom application development.

Maxime

7/2/2009 11:28 PM | Maxime Bombardier
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Thanks for documenting the historical background behind this 'fix'.

Blogged about it some time ago as we always run into it when connecting to the Shared Services admin during deployment of a new SharePoint farm.

www.muhimbi.com/.../...g-unable-to-sign-in-to.html

7/3/2009 10:50 AM | Jeroen Ritmeijer
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

I also ran into this problem days ago. Good article and thanks for the background information.

www.communardo.de/.../sharepoint-2007-host-name...

7/4/2009 10:39 AM | Torsten Hufsky
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Damn lad.. Excellent post

7/4/2009 4:24 PM | Bob Fox
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Nice post Spence. Just ran into the search issue couple of days back because of this.

7/5/2009 2:51 PM | Tajeshwar Singh
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Great post Spence. The number of times I run into this on customer sites is beyond belief. Now I have a well written article to point them too.

7/7/2009 1:40 PM | Neil Hodgkinson
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Good post, easy to understand, nicely written. Thanks!

7/10/2009 3:17 PM | Alistair Laing
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Thank you for this helpful post. I was running into this 401 problem and the registry fix was the solution.

7/13/2009 9:35 PM | Vince Z
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Very interesting reading. I was wondering about 2 things:
Was is the read added value of this security fixe and what are the known exploits already present "in the wild"?
Up to my knowledge this feature or fix is only applicable to NTLM so the good move would be to use Kerberos, no?
Finally one remark: I find particularely annoying that MS makes security change to Windows without letting proper information circulate at release time. Due to this, I bet that 99% of the sharepoint servers out there will run with Loopback check disabled, despite the fact you warned us...

Marc

7/24/2009 3:42 PM | Marc Lognoul [MVP]
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Thanks much for the info. Todd and Shane talked about this at TechEd and I have heard nor seen anything but a peep since. Well done.

7/30/2009 2:42 PM | Greg Kamer
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Great stuff mate.

8/1/2009 3:09 PM | Tobias Zimmergren
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Thanks for the reminder of this issue Spencer.
I ran into it this weekend when changing the configuration of a farm to have a dedicated crawler.

8/8/2009 1:43 PM | Lorna Hermin
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

I found an easy workaround for crawling a FQDN Sharepoint site without the DisableLoopbackCheck. Go ahead and crawl the site using the Host Name so it will not fail, then create a Server Name Mapping from the Host Name to the FQDN name (SSP>Search Administration>Server Name Mappings), thus serving the results of the Host Name crawl as FQDN results. Hope this helps someone.

8/19/2009 2:41 AM | James McDowell
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

James: this only works when using the host name and AAMs for the FQDN.

8/19/2009 10:45 AM | harbars
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Hey Spence,

Ran into a variation on this problem recently on an InfoPath Forms/Nintex Workflow project. I was using a custom SharePoint web service to allow InfoPath to talk to SharePoint, and when I exposed the Form to an Internet-facing zone, I started getting unauthorized errors. Disabling the loopback check fixed the problem. The behavior was mimicing the *double hop* authentication issue, but it was all on the same server!!

www.sharepointbits.com/.../...opback-security.html

Cheers,
Chris

8/19/2009 5:44 PM | Chris Beckett
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

You nailed it. Thanks for the write-up.

9/21/2009 11:50 PM | Jon Sagara
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

I've never gotten the "BackConnectionHostNames" working (even after reboot). Hence, it's disabled.

9/30/2009 2:33 AM | Peter
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

You saved my sanity with this one (trying to set up a dev domain/MOSS environment and pulling my hair out at 2AM).

10/2/2009 2:44 PM | Carrie
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Please help me understand what you mean by "You should add a list of addresses you wish to exclude" means when addressing the loopback security issue in the production environment... are these crawl rules?
Thank you

11/30/2009 5:20 PM | John
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Does anyone know the specific Group Policy objects to modify to add the host names to the loopback?

12/6/2009 1:28 PM | Jim Chrapowicz
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

It is mentioned that you get a 401 with "Custom Code using SharePoint Web Services." That makes sense, but couldn't you also get an error while calling a SharePoint Web Service without custom code? For instance, using "GetUserProfilebyName" to load the current user's profile information in an InfoPath form.

12/20/2011 9:57 PM | Patrick
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Thanks for a great post.

8/6/2012 10:48 PM | Hareesh
Gravatar

# re: DisableLoopbackCheck & SharePoint: What every admin and developer should know.

Great link

8/21/2012 12:14 PM | SP Developer

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 7 and 6 and type the answer here: