How to: Configure Custom or Forms Authentication in Reporting Services
Reporting Services provides an extensible architecture that allows you to plug in custom or forms-based authentication modules. You might consider implementing a custom authentication extension if deployment requirements do not include Windows integrated security or Basic authentication. The most common scenario for using custom authentication is to support Internet or extranet access to a Web application. Replacing the default Windows Authentication extension with a custom authentication extension gives you more control over how external users are granted access to the report server.
In practice, deploying a custom authentication extension requires multiple steps that include copying assemblies and application files, modifying configuration files, and testing. This topic focuses on just the authentication settings that you specify in the configuration files. For a complete walkthrough of all the steps you must follow, see Security Extension Sample.
Note
Creating a custom authentication extension requires custom code and expertise in ASP.NET security. If you do not want to create a custom authentication extension, you can use Microsoft Active Directory groups and accounts, but you should greatly reduce the scope of a report server deployment. For more information about custom authentication, see Implementing a Security Extension.
Additionally, if you want to use Forms authentication or a custom authentication extension in a Reporting Services environment that is integrated with Windows SharePoint Services (WSS) 3.0 or Microsoft Office SharePoint Server (MOSS) 2007, you must configure the SharePoint site to use the authentication method that you choose. For more information about configuring authentication in SharePoint, see Authentication Samples on Microsoft Developer Network (MSDN).
Warning
It is the responsibility of the Forms Provider to mitigate brute force security attacks in which a malicious user makes frequent and repeated calls to the end-point until the server is adversely affected. A common approach to mitigate this type of security threat is that the Forms provider has implemented features to lock accounts after a specific number of incorrect log-in attempts. Windows Integrated security has lock-out support through the lock-out policy of the domain. The domain lock-out policy needs to be configured by your domain administrator. However with Forms authentication, it is the responsibility of the Forms Provider to provide protection to potential threats.
To configure a report server to use Custom authentication
Open RSReportServer.config in a text editor.
Find <Authentication>.
Copy the following XML structure:
<Authentication> <AuthenticationTypes> <Custom /> </AuthenticationTypes> <EnableAuthPersistence>true</EnableAuthPersistence> </Authentication>Paste it over the existing entries for <Authentication>.
Note that you cannot use Custom with other authentication types.
Save the file.
Open the Web.config file for the report server. By default, it is located at \Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer.
Find authentication mode and set it Forms.
<authentication mode = "Forms" />Find identity impersonate and set it to False.
<identity impersonate = "false" />Open the Web.config file for Report Manager. By default, it is located at \Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Serivces\ReportManager.
Find authentication mode and set it Forms.
<authentication mode = "Forms" />Find identity impersonate and set it to False.
<identity impersonate = "false" />Add the PassThroughCookies element structure to the configuration file. For more information, see Enabling Report Manager to Pass Custom Authentication Cookies.
Save the file.
If you configured a scale-out deployment, repeat all of the previous steps for other report servers in the deployment.
Restart the report server to clear any sessions that are currently open.