Authentication is the security mechanism used to identify a person, process, or computer that's attempting to use a system resource. Authentication
merely confirms the identity of the requestor. It doesn't include authorization, which is the process of using the requestor's identity to check
whether permissions allow access to the requested resource.
In SQL Services Reporting Services (SSRS), authentication typically begins with a request to connect to the report server but can also occur when the
report server requires access to its application databases or to external data sources, as shown in Figure 1. Figure 1 delineates the authentication
process when SSRS is running in native mode. I'll explain the various authentication scenarios shown in the figure and discuss the options you have for
authentication protocols when implementing SSRS 2008 and later. Along the way, I'll explain how the authentication process differs when SSRS is running
in SharePoint integrated mode.
Figure 1: Delineating the authentication process in SSRS (native mode)
Client Authentication (Native Mode)
A user can connect to a report server in a variety of ways. Commonly, a user opens a browser and connects to Report Manager to view reports or manage
server properties for reports. Other user activities that require a connection to the report server include report deployment using SQL Server Business
Intelligence Development Studio (BIDS), server administration using SQL Server Management Studio (SSMS) or a command-line utility, and report rendering
using URL access. In addition, programmatic access to the report server can occur when a custom application implements the ReportViewer control or
calls a Reporting Services Web service.
No matter which of these connection methods is used, the report server requires that the client authenticate the user or process that's requesting the
connection. The client passes the information to the report server in an HTTP authentication request. The report server in turn passes this information
to a Windows Authentication extension (which is the default) or a custom security extension. If the authentication fails, the report server sends an
HTTP 401 Access Denied error to the client application.
Windows Authentication Extension
When the report server uses the Windows Authentication extension, each user must have a Windows account. It can be a local account (i.e., an account on
the report server) or a trusted domain account. The account must be added as an allowed user to the report server either individually or as part of a
group. Furthermore, the client application must support Windows integrated security.
The Windows Authentication extension supports several authentication types, but SSRS is initially configured to use only one authentication type. You
can manually update the \Program Files\Microsoft SQL Server\<instance>\ReportServer\RSReportServer.config file to add other authentication types,
as you can see in the configuration file fragment shown in Figure 2. Although Figure 2 shows how each authentication type should appear in the
configuration file, you typically wouldn't include all five. Let's review each authentication type setting separately.
Figure 2: Including other authentication types in RSReportServer.config
RSWindowsNegotiate.
If you initially set the Windows service account for the report server to NetworkService or LocalSystem in Reporting Services Configuration Manager,
RSWindowsNegotiate is added to the RSReportServer.config file as the default setting. With this setting, the report server can accept requests from
client applications requesting Kerberos or NTLM authentication. If Kerberos is requested and the authentication fails, the report server switches to
NTLM authentication and prompts the user for credentials unless the network is configured to manage authentication transparently.
Using RSWindowsNegotiate is your best option because it provides the greatest flexibility for multiple clients in an intranet environment. Although a
domain administrator needs to configure Kerberos authentication, using it is advantageous because the authenticated identity is retained without
passing credentials from server to server in a distributed environment, which is an effective defensive security measure. NTLM authentication allows
clients to connect to the report server securely, but it doesn't allow the report server to forward credentials to another server when external data
sources are associated with reports.
Even if Kerberos authentication is correctly configured, any of the following conditions in your environment can cause the client to bypass Kerberos
and use NTLM authentication instead:
-
The Report Server service account is a domain account, but the domain administrator hasn't registered a service principal name (SPN) for the
service account.
-
The connection request is sent to a local report server or an IP address rather than a host header or server name.
-
The firewall blocks the Kerberos authentication port (88/TCP).
-
Kerberos isn't enabled in the report server's OS.
-
The client is Microsoft Internet Explorer (IE) and the connection request uses a Fully Qualified Domain Name (FQDN) or localhost rather than the
report server's network name.
RSWindowsKerberos.
If you have client applications that only use Kerberos, you must add this authentication type to the report server configuration.
RSWindowsNTLM.
When you initially configure the report server's Windows service account as a domain account, the default authentication type is set to RSWindowsNTLM.
You can also add this authentication type to the configuration file as a fallback option if you're experiencing Kerberos authentication errors.
However, you won't be able to use Windows integrated security for data source connections when the client application uses NTLM authentication.