Planning for Extranet or Internet Deployment
Although SQL Server Reporting Services is not expressly designed for extranet or Internet report deployment scenarios, you can successfully put Reporting Services on an Internet-facing Web server to distribute general information to the public at large or private corporate data to authorized and authenticated users.
Note
Deploying Reporting Services on an Internet-facing Web server requires careful evaluation. Network and security software, network topology, and domain configuration can introduce variables that make it difficult to prescribe an exact set of steps for report server deployment. When evaluating a report server for Internet access, make sure that your test scenarios include all the features that you intend to use and that you always test by using secure connections.
Extranet or Internet Architecture Diagram
The following illustration provides an example of a best-practice deployment configuration for extranet or Internet deployment.
.gif "Internet or extranet report server deployment")
Key points to notice about the diagram include the following:
Three firewalls provide defense in depth across the entire deployment. Recommendations for configuring the firewalls are provided in this topic.
The point of entry is a custom Internet application that contains the ReportViewer control. The control hosts a report that runs on a report server behind the second firewall.
Reports use data from read-only data sources that are created specifically for reporting purposes. The data sources contain data that is copied from other sources, but without sensitive data values that you would never use in a report.
Corporate data servers contain sensitive data that you protect through strict permissions and restrictive firewall settings. You should also consider putting the report server database in this security zone so that all database servers that require read-write access can use the protection provided by the third firewall.
General Guidelines
The following list provides broad guidelines for deploying Reporting Services in the topology depicted in this topic. This list is offered as a starting point for planning your own deployment plan. The specific configuration of your network topology will probably require that you perform additional steps that are not described in this list.
It is important that you deploy the configuration in a test environment to confirm that you understand all the requirements, settings, steps, and the best order for those steps:
Install firewalls and identify servers, accounts, and permissions.
Create or obtain server certificates for SSL connections. Install certificates on all computers that host server components. If you installed the certificates with wildcard settings, you can use the same certificate for multiple URLs.
Design and implement an approach for copying corporate data to separate reporting data sources. You can use technologies such as Replication, SQL Server Integration Services, or a third-party product.
Install Reporting Services in files-only installation mode so that you can configure it with settings that are valid for external access. In SQL Server Installation Wizard, this is the Install but do not configure option.
Run the Reporting Services Configuration tool after Setup is complete to configure the report server:
Verify the service runs under a least-privileged account. Avoid using Local System. If you selected Local System, change the account to use NetworkService or a domain user account.
Define a report server URL and optionally a Report Manager URL:
You should create multiple URLs to support access through a fully qualified domain name (FQDN) that will be used by external users, and a different URL that uses the network name. Using two different URLs will allow you to connect to the report server if your Internet connection is disabled or offline.
You should select SSL certificates for the FQDN URLs that you define.
Create the report server database. If the SQL Server instance is in a different domain and Kerberos 5.0 is not enabled, use SQL Server authentication for the report server database connection. Secure the connection between the report server computer and the SQL Server Database Engine instance using SSL or IPSec.
Create and deploy a custom authentication extension. If you are using a Single Sign-on technology that is implemented as an ISAPI filter, you must use ISA Server to support the ISAPI filter. The HTTP listener in Reporting Services does not support ISAPI filters.
Configure role assignments that use the security principles of the custom authentication extension and map them to roles that convey permissions to report server operations.
Create and deploy an Internet front-end application that uses the ReportViewer Web server control.
Publish reports and other content types to the report server.
Configure the firewall settings. Verify firewall settings allow minimum access to downstream computers and applications.
Firewall Configurations
The default URLs for report server applications assume that port 80 is enabled and available to the report server. If you are using Windows Firewall, you must open port 80 or another port that is available for report server HTTP requests. If you use a different port, be sure to specify it in the report server URLs. For more information, see How to: Configure a Firewall for Report Server Access. For more information about the default Windows firewall settings, and a description of the TCP ports that affect the Database Engine, Analysis Services, Reporting Services, and Integration Services, see Configuring the Windows Firewall to Allow SQL Server Access.
ReportViewer Web Server Control in an Internet Application
To deploy reports in an Internet application, you can embed the ReportViewer Web server control in a custom Internet-ready application that you create and deploy. The ReportViewer Web server control is included in Visual Studio 2005 and later, and can be distributed freely with your application. You can configure the control to display reports that run on a report server. The connection between your application and the report server is handled by the control, through the Web service programming interface. All authentication and authorization is handled by your application, which connects to the report server through a single, user-trusted connection.
For more information, see Reporting Services and ReportViewer Controls in Visual Studio 2010.
Report Manager as an Internet or Extranet Web Front-end
Report Manager was not designed as an Internet application, but if you cannot create a custom Internet application, you can use Report Manager to view reports over an Internet connection. The following suggestions are offered as best practice recommendations for deployment:
Consider installing Report Manager as a separate instance on an application server. Report Manager runs within the Report Server service. Therefore, to install Report Manager you must install Reporting Services and then turn off the Web service and scheduling and delivery features in the service. For best results, install Reporting Services on an Internet-facing Web server using the files-only installation mode. In SQL Server Installation Wizard, this is the Install but do not configure option.
Create and deploy a custom security extension to support forms authentication or a single-sign on technology.
Configure Report Manager for minimal permissions. The Browser role and System User role are sufficient for viewing reports.
To point Report Manager to a different report server instance that runs on a separate computer, you must configure the Report Manager URL and then modify the <ReportServerVirtualDirectory> and <ReportServerUrl> settings in the RSReportServer.config file to point Report Manager to the report server instance.
On the report server that you are connecting to, turn off features that you will not use. Examples might include My Reports, subscription and delivery, Report Builder, and client-side printing.
Configuring Proxy Settings in Web.config Files
If you are using Report Manager as a front-end application for Internet deployment and the report server is also installed on the same computer, you must specify a Web.config setting that allows Report Manager to bypass the proxy server when sending requests to a local report server that is installed on the same computer.
The Web.config setting is the System.NET defaultProxy network setting. By default, defaultProxy is disabled in the Web.config file for Report Manager. This is the recommended configuration when Report Manager and the report server are deployed together on the same computer.
If you upgraded from an earlier version of Reporting Services, the Report Manager Web.config file does not include the defaultProxy configuration setting. You can add and set the defaultProxy setting to bypass the proxy server for installations where Report Manager and report server are running on the same computer. Copy the following configuration settings into the Report Manager Web.config file:
<configuration>
...
<system.net>
<defaultProxy enabled="false" />
</system.net>
</configuration>
For more information about these settings, see "Configuring Internet Applications" and "defaultProxy Element (Network Settings)" in the Microsoft .NET Framework Developer's Guide.
Authentication Considerations for Extranet and Internet Deployment
To deploy a report server in an extranet scenario that supports connections from predefined Microsoft Active Directory accounts, you can use the default Windows Authentication security extension. Plan on configuring the server for Secure Sockets Layer (SSL) connections and Basic authentication. You can use the Reporting Services Configuration tool to map an existing certificate to a report server URL. You can modify configuration files to specify the authentication type.
To deploy a report server in an extranet scenario that supports connections from a single sign-on technology or a forms-based authentication model that stores user identity information in a database, you must create a custom authentication extension to replace the default Windows Authentication security extension. Forms-based authentication is typically used when you are opening up a report server to the public but only want authenticated users to view content. By default, SQL Server Reporting Services does not provide a forms-based authentication module. For more information about how to create one, see Implementing a Security Extension in SQL Server Books Online.
Verifying Internet Deployment
To verify that your report server connection is accessible, you should be able to view the report server folder namespace over an Internet connection by typing http: (or https:)//<your-web-server-fully-qualified-domain-name>/reportserver, where /reportserver is the default name of the report server virtual directory.