If we are part of a software developer team (contrary to one-man-does-it-all guy), quite often we find ourselves in a situiation in which we have to set-up a new developer environment. One of the issues we have to cope with, is adjusting configuration, that has to match the new machine specifics. An useful trick that is often used, is to implement aliases (SQL Server aliases, host aliases, etc.) on each developer machine, so that there are no differences in the configuration. This way if the configuration settings are preserved in a version control system, they are used by each develeper without the need anything to be changed. Instead, what happens behind the curtains is all the settings are interpreted with the help of the mentioned aliases to match the working machine environment.
Following the abovely described practice, recently we (the team and I) had to deal with a securuty isse that did not allow us to take full advantage of aliases configuration. My point in this post is to describe the problem and solution, hoping that it can be useful to someone else, and not only me :).
What was required
We had a MS SQL Reporting Services solution with a couple of projects in it. Projects had to be configured so that :
-Each one had to use one and the same "Target Server URL" for deployment;
-Behind this "Target Server URL", actually had to stand the developer's local machine.
What had to be done
In order for these things to work, every developer machine had to include two changes:
1) To have a record in the C:\Windows\System32\Drivers\Etc\Host file saying that "fixedname" server is actually 127.0.0.1
2) And in the Report Server Web Service configuration, we had to add http://fixedname/ as a new URL from which the service could be accessed.
What was the problem
After doing what logically seemed to be enough and tried to open reporting services through the newly added URL, we found out that windows authentication did not work for this URL, and we could not use it at all.
What was the reason
After digging for sometime it turned out that after IIS 5.1 and above in combination with Windows Server 2003 SP1 (or Windows XP SP2) and later versons of Windows OS a securty check was implied. This check did not allow us to authenticate when the request was fired from the local machine using a host header, that matched a host header configured for the same machine. If we fired the request from another machine within the network, things worked perfectly. But in our situation, requests had to made and serviced by the same environment.
What was the solution
Well, it happend so, that there was trick which we could use in order to pass by the securtiy check – to disable it. Disbaling it in our case was justified, but do be careful to consider it carefully when you forbid a security feature. All we had to do was:
1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
4. Right-click Lsa, point to New, and then click DWORD Value.
5. Type DisableLoopbackCheck, and then press ENTER.
6. Right-click DisableLoopbackCheck, and then click Modify.
7. In the Value data box, type 1, and then click OK.
8. Quit Registry Editor, and then restart your computer.
... as instructed in the following Microsoft KB Article: http://support.microsoft.com/kb/896861
This scenario can be applied not only when it comes to Reporting Services, but whenever you need a web site requiring a host header, to be accessed form the same machine that hosts the site.