To configure the report server or Report Manager to use a FQDN, you must also edit the configuration files.
- Open RSReportServer.config in a text editor.
- Append the port number to the UrlRoot setting in the rsreportserver.config file. For example, if Urlroot is set to http://server/reportserver server, set it to http://www.mikeglaser.com/reportserver instead.
- Open RSWebApplication.config in a text editor.
- Set ReportServerUrl to the same URL you specified in UrlRoot.
- Delete the value (but not the tags) for ReportServerVirtualDirectory.
- Save both files.
<foo> is considered a “Host Header”. It is an alternate name for the computer on which SSRS is installed. You will need to add the NetBIOS and Fully Qualified Domain Name (FQDN) for <foo> to the list of BackConnectionHostNames stored in the Windows Registry. Casing does not matter. Use the steps in Method 2: Specify host names in KB 896861, with the following adjustment. Step 7 of the KB article says “Quit Registry Editor, and then restart the IISAdmin service.” Instead, just reboot the computer. This is the correct solution for security reasons that I’ll explain later in this article.
For example, if <foo> is a Windows machine name like “contoso”, then it likely also can be referenced in FQDN form as “contoso.domain.com”. You will need to add both representations to the list in BackConnectionHostNames.
Report Server and Report Manager communicate using a network connection. When configured for a scale-out deployment of Reporting Services, typically a single virtual server name is given to the deployment and the underlying machine names are never used by end-users. The same can happen even for non-scale-out deployments but I would consider it less common. For example, you might call the server www.contoso.com or on the internal network simply “contoso”. These are called Host Headers. We have only observed the issue in this post when using a Host Header; we have not seen it when using just the machine name.
By default, Report Manager is configured for Windows authentication. In this mode, it impersonates the user making the request and uses that user’s credentials to connect to the Report Server. Because the network request is local, the authentication between RM & RS can succeed without running into a double hop authentication issue. In the case described above, it fails mysteriously. Let’s see why…
The exact authentication mode used by both RS and RM is defined in rsreportserver.config in the <AuthenticationTypes> element. When <AuthenticationTypes> includes <RSWindowsNTLM/> then RM & RS can use NTLM authentication. NTLM is generally a destination agnostic authentication scheme. What this means is that the client does not have mutual authentication and cannot be sure which machine it authenticated to.
When you perform NTLM authentication, you can optionally specify an intended destination in the form of an SPN. This helps mitigate authentication reflection attacks. Not all clients (e.g. browsers) or APIs packages (e.g. .Net Framework) do this by default. The specific change we observed is that the .Net Framework 3.5 SP1 now defaults to specifying the Host Name used in the request URL in an SPN in the NTLM authentication package. So if you make a URL request to http://<foo>/reportserver then the SPN “HTTP/<foo>” is added to the authentication information. This is good news from a security perspective, but has an unfortunate consequence.
You might think that since the user accessing Report Manager accessed http://<foo>/reports and then the report manager accessed http://<foo>/reportserver, everything should just work. However, Windows has a special case when you do NTLM authentication on the local computer (i.e. loop back connection) that affords protection against authentication reflection attacks. Part of the NTLM authentication process centers on a challenge issued by the destination computer and sent back to the client computer. Windows keeps track of the challenges it issues. If Windows receives a challenge it itself generated Windows will fail the authentication unless the connection is a loop back connection.
To determine whether the connection is a loop back connection, Windows reads the destination contained in the authentication information supplied by the client. If the destination is not specified or maps to the local machine then Windows allows the authentication to proceed. In our failing case, <foo> is neither the machine name nor the loop back IP address nor the machine’s IP address, so Windows fails the authentication requests. This causes the requests between Report Manager and Report Server to fail with 401 (Unauthorized).
To address the issue, we need to tell Windows that <foo> is actually an alternate name for the local computer. The correct way to do that is to use the BackConnectionHostNames registry entry as described in Method 2: Specify host names in KB 896861. Solution Method 1: Disable the loopback check will result in a less secure system, as it disables the protection against reflection attacks. It is better to constrain the set of alternate names to only those you expect the machine to actually use.
After running successfully through the Reporting Services configuration we now need to edit the 2 following configuration files;
“RSWebApplication.config” located in the ReportManager directory, for example;
“ C:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting
“Reportserver.config” located in the ReportServer directory, for example;
“C:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services\ReportServer\Reportserver.config”
In “RSWebApplication.config” locate the 2 lines;
Comment out the “<ReportServerVirtualDirectory>” node and place your host header value with the virtual directory for your report server web service path in the “<ReportServerUrl>”, for example;
In “Reportserver.config” locate the line;
Replace the value with your host header and report server web service path, for example;
Something to watch out for, if you are running multiple instances of Reporting Services on one server make sure that in your “Reportserver.config” file the instance node points to the right instance path.