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.