microsoft samples reportingservices customsecurity dll

Microsoft Samples Reportingservices Customsecurity Dll Update The Program

The client sends this information to the report server in plaintext.

Informa PLCs registered office is 5 Howick Place, London SW1P 1WG.

Authentication merely confirms the identity of the requestor.

It doesnt include authorization, which is the process of using the requestors identity to check whether permissions allow access to the requested resource.

Figure 1 delineates the authentication process when SSRS is running in native mode.

Ill 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, Ill explain how the authentication process differs when SSRS is running in SharePoint integrated mode.

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.

The report server in turn passes this information to a Windows Authentication extension (which is the default) or a custom security extension.

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.

Microsoft Samples Reportingservices Customsecurity Dll Update The Program

You can manually update the Program FilesMicrosoft SQL Server ReportServerRSReportServer.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 wouldnt include all five.

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.

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 doesnt allow the report server to forward credentials to another server when external data sources are associated with reports.

You can also add this authentication type to the configuration file as a fallback option if youre experiencing Kerberos authentication errors.

However, you wont be able to use Windows integrated security for data source connections when the client application uses NTLM authentication.

If you want to use Kerberos authentication instead, you can have the domain administrator register an SPN for the domain account and manually update the RSReportServer.config file to replace RSWindowsNTLM with RSWindowsNegotiate.

In that case, you can use Basic authentication, which is supported by most browsers.

However, you must set up each user with a Windows account thats either local to the report server or on the domain.