Recently I created a small tool to manage discount codes for CodeMash. It was a website based on ASP.NET Dynamic Data (which is part of .NET 3.5 sp1). This tool made it real easy to put together a quick and simple web form to manage these codes.
When I went to deploy it to the CodeMash server, I found I didn’t have SP1 installed, so I installed it. Deployed the web form, and everything seemed awesome.
Then at around 6:00am the next morning I started getting lots of emails about problems with the CodeMash site. Which was funny, because the core site (not including registration) has always been fairly stable. It is an ASP.NET site. We store the site content in WSS, and bring that content into the web site via the WSS web services. Both sites live on the same server (remember that, it becomes important later on).
That morning, those web services started failing with a “The request failed with HTTP status 401: Unauthorizedâ€.
I searched and wondered. I uninstalled SP1, and reinstalled .NET 3.0 RTM. Nothing fixed it. I pushed a build of the site that bypassed the services as a short term fix, but the problem persisted for over a week. It was KILLING me. What made it harder was the the services worked just fine when being called from a remote location, like my developer workstation. But calling the service from the same web server that the WSS services were running kept failing.
I searched, and searched, and searched. I couldn’t find anything that even remotely helped. The Jim Holmes (fellow CodeMash founder, and all around smart guy) sent me a link to a blog post that might help. It turns out it was a link to my own blog. The post shows how to configure WSS for just NTLM instead of Kerberos. This configuration is now exposed in the WSS admin tool, so you don’t have to do it at the command prompt anymore. But that setting was already correct.
I was at a complete roadblock. I even uninstalled, installed .NET 3.5 sp1 and reinstalled WSS. Then I simplified my search terms, and a MSKB article popped up. I then followed the steps in the article, and that fixed it. Yahoo!
The article covers a change that .NET 3.5 SP1 puts in place. This security change is already present in other scenarios, so they added it to SP1 to make it more consistent. This feature protects against loopback reflection attacks, and blocks any loopback call. A loopback call is when you call ‘out’ to a service that is actually local. The KB article goes over a few options. You can disable loopback check, or you can reconfigure how you connect to the local service (using a local address, instead of a public address.)
The problem had nothing to do with WSS, and that was the red herring for me. It had to do with some fixes that the .NET 3.5 SP1 put in place.