Share via

  • Article

Security Overview for Reporting Services in SharePoint Integrated Mode

When you configure a report server to run in SharePoint integrated mode, the report server uses the authentication provider and permissions defined in the SharePoint Web application to control access to report server items and operations.

Permission to access items and operations is granted through SharePoint security policies that map a user or group account with a permission level, relative to an item. Conceptually, it is identical to how role assignments are used in a native mode report server deployment, where a role assignment maps a user or group account to a set of allowable tasks relative to an item. As is common with most role-based authorization models, SharePoint security provides permission inheritance to reduce the complexity and overhead of maintaining a large number of policies.

If you are deploying report server content types to a SharePoint site, you need to know the following:

Before you can set permissions, you must configure each server for integration. For more information, see Configuring Reporting Services for SharePoint 2010 Integration.

Authentication Providers in SharePoint Technologies

A SharePoint Web application can use Windows Authentication or Forms authentication. A report server will process requests from either one. You can configure authentication in these combinations:

  • Windows Authentication using Kerberos

  • Windows Authentication using NT LAN Manager (NTLM)

  • Forms authentication

Note

Both Reporting Services and SharePoint products and technologies support forms authentication. The implementation is different for each product group and they are not compatible. Reporting Services custom authentication extensions are not supported for report servers that run in SharePoint integration mode.

The following table summarizes the benefits and drawbacks to each of the authentication providers:

Benefits

Drawbacks

Windows Authentication using Kerberos

Works in single-server and multi-server deployment scenarios.

Supports using Windows integrated credentials for external data sources.

Does not work with NTLM authentication in multi-server deployments.

Requires complex domain and configuration server configuration.

Windows Authentication using NTLM or Forms authentication

Works with Kerberos and all non-Kerberos authentication scenarios.

Does not support Windows integrated credentials for external data sources.

SharePoint Claims Authentication

SharePoint 2010 products support Claims Based Authentication. SQL Server 2008 R2 Reporting Services in SharePoint integrated mode will work with SharePoint Claims enabled Web applications by using Trusted Account authentication and SharePoint User tokens. For more information on how Reporting Services supports Claims Authentication, see Claims Authentication and Reporting Services. For more information on Claims based authentication, see Claims-Based Identity Overview.

Sending Requests to a Report Server

All requests for a report server item or operation must be a valid authenticated request. The authentication provider you are using determines how that request is processed.

Windows Integrated Security Using Kerberos

If the SharePoint Web application is configured for Windows Authentication using Kerberos, the connection from the SharePoint Web application to the report server can use the impersonated or delegated credentials of the current Windows user. By using Windows integrated security with Kerberos and identity delegation, you can eliminate the classic "double-hop" issue wherein Windows credentials expire after a single connection. It can also expand the set of options that are available to you when you configure data source connections for reports and models. The following diagram shows the connections when a report server is configured for SharePoint integration, and the SharePoint Web application uses Windows Authentication with Kerberos and identity delegation.

Connections in SharePoint integrated mode

  • Connection 1
    A user accesses a SharePoint site under the user token created when the user logged on to the network. It contains the user identity and group membership. The SharePoint Web application authenticates the user. The user requests a report server item or operation.

  • Connection 2
    The SharePoint Web application sends the token and the request to the report server. The connection request is sent under the delegated Windows identity of the user. The report server authenticates the user to see whether the user is allowed to access the report server.

  • Connection 3
    If authentication is successful, the report server will use the user account of the Reporting Services instance to make a connection to the SharePoint content databases to verify that the user is authorized to access the item or operation. If authorization is successful, the report server services the request.

  • Connection 4
    If the user is viewing a report, the report server can delegate the Windows identity of the user during report processing to retrieve data from external data sources. This means that when you set data source properties on a report, you can select the Windows integrated security option for the data source connection. For more information, see Specifying Credential and Connection Information for Report Data Sources (SSRS) and How to: Create and Manage Shared Data Sources (Reporting Services in SharePoint Integrated Mode) in SQL Server Books Online.

Windows or Forms Authentication and Trusted Accounts

If the SharePoint Web application is configured for Forms authentication or for Windows Authentication using NTLM, the connection to the report server is sent across the network under a predefined trusted account that has permission to impersonate a SharePoint user on the report server. The following diagram shows the connections when trusted accounts and SharePoint user identities are used.

Connection diagram for trusted connection

  • Connection 1
    A user logs on to a SharePoint site. The SharePoint Web application authenticates the user. The SharePoint Web application translates the user identity to a SharePoint user identity (SPUser). A new user token is created for that user in the context of SPUser. It contains the user identity and group membership. The user requests a report server item or operation.

  • Connection 2
    The SharePoint Web application connects to the report server using a trusted account, which is the process identity of the SharePoint Web application. The SharePoint Web application then impersonates the SharePoint user identity in the request for an item or an operation.

    The report server authenticates that the connection request is from a trusted account by comparing it to account information that the report server retrieved from the SharePoint configuration databases when the report server started. On a report server, the trusted account is a Windows user with permission to impersonate the SharePoint Web application. It is also used to impersonate the SPUser, but it is not allowed access to report server items and operations.

  • Connection 3
    If authentication is successful, the report server will use the user account of the Reporting Services instance to make a connection to the SharePoint content databases to verify that SPUser is authorized to access the item or operation. If authorization is successful, the report server services the request.

  • Connection 4
    If the user is viewing a report, the report server cannot use the SPUser to retrieve data from external data sources due to the “double-hop” issue. This means that when you set data source properties on a report, you cannot select the Windows integrated security option for the data source connection. You can, however, configure the report to use other connection options, such as stored credentials or prompted credentials. For more information, see Specifying Credential and Connection Information for Report Data Sources (SSRS) and How to: Create and Manage Shared Data Sources (Reporting Services in SharePoint Integrated Mode) in SQL Server Books Online.

Account Expiration and Subscription Processing

When you create a subscription to a report, the report server will store the SPUser account information so that it can verify that the user has permission to view the report at the time of delivery. If SPUser has expired, the subscription will fail and return an rsSharePointError error. A farm-level property named TokenTimeout determines how long SPUser is valid.

Configure Administrative and Service Accounts to Use Unique Domain User Accounts

A deployment of a SharePoint product or technology uses a variety of accounts to run services and access front-end and back-end servers. If you specify domain accounts for your deployment, be sure to follow best practice recommendations and specify accounts that are used exclusively by the SharePoint Web application. Do not configure a service account to run under the domain user account of an actual person who will be accessing the SharePoint site. If you access a SharePoint site using service credentials, you might encounter errors.

Best Practices for Configuring Authentication Providers in a Scale-Out Deployment

If you have a scale-out deployment of Reporting Services and a SharePoint product, and you have configured different authentication providers for your environment, you might encounter problems with authenticating users. For example, if your reporting environment uses Forms authentication for Internet connections and Windows Authentication for intranet connections, the request might be routed to a Web front-end computer with an authentication provider that does not match the authentication type of the request. This might cause Reporting Services to deny access for the request, or the request might be run under the application pool identity rather than the user who made the request.

As a best practice, users should use different URLs to access content from the Internet and intranet. Or you can configure the hosts file on the Web front end computers to override the Domain Name System (DNS) lookup by mapping the Internet Protocol (IP) address of the Internet-facing site to the Internet URL so that requests to the Internet URL do not get routed to the intranet URL by DNS.

How the Report Server Accesses SharePoint Content Databases

Both the SharePoint Web application and the report server connect to their respective databases to store application state and other data, but the report server must also connect to the SharePoint databases to store and retrieve items, properties, and configuration settings. The following diagram shows the server connections to the various databases.

Connection diagram

A SharePoint Web application can use a local or remote database for internal storage. If the SharePoint databases are on remote computers, a domain account must be used for the connection.

A report server can use a local or remote database for internal storage. For either type, the database connection can be made by using a domain account, a SQL Server login, or a built-in account such as Network Service or Local System.

Report Server Connection to the SharePoint Databases

In Reporting Services, both the Web service and Windows service require access to SharePoint databases. The service accounts for both services run as trusted users in a SharePoint Web application, and are automatically granted permission to access the SharePoint databases.

The connection is managed internally; it is configured when you use SharePoint Central Administration to point a SharePoint Web application to a report server and set the trusted accounts. In contrast with the report server connection to its own databases, which you can set or modify using the Reporting Services Configuration tool, you cannot explicitly configure or manage the report server connection to the SharePoint databases.

Running a report server in SharePoint integrated mode introduces constraints on how you configure the service accounts in Reporting Services. Use these guidelines when configuring service accounts:

  • Choose accounts that have network logon permissions if the Report Server service accounts must connect to the SharePoint databases on a remote computer.

  • Do not use built-in accounts (such as Local System or Network Service) if the report server and the SharePoint databases are on one computer, and the SharePoint Web application is on a remote computer. When SharePoint databases run on a remote computer, the SharePoint Web application explicitly denies database access to built-in accounts that are defined on that remote computer. This means that if the report server is running under a built-in account, then it cannot connect to SharePoint databases because it is running on the same computer as the SharePoint databases.

  • For all other topologies that place the servers and databases on the same computer or different computers, the Reporting Services service accounts can be configured as domain accounts or built-in accounts.

Errors Connecting to the SharePoint Databases

If the report server cannot access the SharePoint databases and there is a configuration error (for example, if the service accounts or passwords are not valid or if a local instance of the Windows SharePoint object model is not installed), an rsServerConfigurationError error occurs. For all other connection errors, the rsSharePointError error is returned, along with additional error information from the local SharePoint instance.

SharePoint and SSRS Authentication Topologies

The following table lists supported combinations of SharePoint and SSRS authentication methods and usage.

SharePoint and SSRS on the same computer

SharePoint Authentication

SSRS integration mode

SSRS Authentication

Account accessing SSRS

Data source credentials

Yes

Kerberos

Integrated

Negotiate

User, can delegate the user's security context

Integrated, Stored, Prompt

Yes

Kerberos

Integrated

NTLM

Not supported

Yes

Kerberos

Trusted

Negotiate or NTLM

Site Service Account

Stored, Prompt, Integrated (+)

Yes

NTLM

Integrated

Negotiate

Not supported

Yes

NTLM

Integrated

NTLM

User, can NOT delegate the user's security context

Stored, Prompt, Integrated, Local

Yes

NTLM

Trusted

Negotiate or NTLM

Site Service Account

Stored, Prompt, Integrated (+)

Yes

Forms

Integrated

IUSR

Not supported

Yes

Forms

Trusted

Negotiate or NTLM

Site Service Account

Stored, Prompt, Integrated (+)

No

Kerberos

Integrated

Negotiate

User Delegatable

Integrated, Stored, Prompt

No

Kerberos

Integrated

NTLM

Not supported

No

Kerberos

Trusted (*)

Negotiate

Site Service Account

Stored, Prompt, Integrated (+)

No

Kerberos

Trusted (*)

Negotiate

Site Service Account

Stored, Prompt, Integrate, only if local to SSRS

No

NTLM

Integrated

Anonymous

Not supported

No

NTLM

Trusted (*)

Negotiate

Site Service account

Store, Prompt, Integrated (+)

No

NTLM

Trusted (*)

NTLM

Site Service Addount

Stored, Prompt, Integrated, only if local

No

Forms

Integrated

Anonymous

Not supported

No

Forms

Trusted (*)

Negotiate

Site service account

Stored, promt, integrated (+)

No

Forms

Trusted

NTLM

Site service account

Stored, prompt, integrated, only if local

(+) If the SharePoint site service account is a local account, then the data source must be local to the Report Server computer. If the site service account is a domain account, then the data source can be on another computer.

(*) SharePoint site service account must be a domain account.

Change History

Updated content

Added authentication topologies tables.