Security Overview for Reporting Services in SharePoint Integration Mode

Článek
12/03/2008

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:

How connections and requests are made between the two servers. The authentication provider used in the SharePoint Web application determines whether you can subsequently use the Windows integrated security option to access external data sources used by a report.
How to use default security to add, manage, and access report server items and operations. For more information, see Managing Permissions and Security for Report Server Items on a SharePoint Site and Using Built-in Security in Windows SharePoint Services for Report Server Items in SQL Server Books Online.
How to override default security by setting permissions on specific reports or operations. For more information, see How to: Set Permissions for Report Server Items on a SharePoint Site in SQL Server Books Online.

Before you can set permissions, you must configure each server for integration. For more information, see Configuring Reporting Services for SharePoint 3.0 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 with integrated security (where Kerberos authentication is enabled)
Windows authentication, without impersonation or delegation (where Kerberos authentication is not enabled)
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 (with Kerberos authentication enabled)	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.
Windows authentication (without Kerberos enabled) or Forms authentication	Works with Kerberos and all non-Kerberos authentication scenarios.	Does not support Windows integrated credentials for external data sources.

Windows authentication (with Kerberos authentication enabled)

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.

Windows authentication (without Kerberos enabled) or Forms authentication

Works with Kerberos and all non-Kerberos authentication scenarios.

Does not support Windows integrated credentials for external data sources.

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

If the SharePoint Web application is configured for Windows authentication with Kerberos authentication enabled, the connection from the SharePoint Web application to the report server is through the impersonated or delegated credentials of the current Windows user. 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 authentication enabled.

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 Windows identity of the user. The report server validates whether the user has permission to access the report server.

Connection 3
If the validation is successful, the report server will verify that the user has permission to access the item or operation.

A report server uses an internal security extension to verify user permissions. The report server uses the extension to call in to the Windows SharePoint Services object model to check the permissions that are stored in the SharePoint content databases. You cannot configure or manage this security extension. It is an internal component used for report servers that run in SharePoint integrated mode.

If the user has permission to access the report or other item or operation, the request is serviced.

By using Windows integrated security, 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. If the Windows user identity is used to connect to the report server, the report server can use that identity 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 in SQL Server Books Online.

Windows or Forms Authentication and Trusted Accounts

If the SharePoint Web application is configured for Forms authentication, 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 same approach is used if the SharePoint Web application is configured for Windows authentication and Kerberos is not enabled. The following diagram shows the connections when trusted accounts and SharePoint user identities are used.

User connection and custom authentication

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 impersonates the SharePoint user identity on the request to the report server. The connection request is sent that uses a trusted account. The account is the process identity of the SharePoint Web application.

The report server validates whether 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 SharePoint Web application. It is used only to impersonate SPUser. It is not allowed access to report server items and operations.

Connection 3
If the validation is successful, the report server will verify that SPUser has permission to access the item or operation.

The report server uses an internal security extension to verify user permissions, call in to the Windows SharePoint Services object model, and check the permissions that are stored in the SharePoint content databases. If the user has permission to access the report or other item or operation, the request is serviced.

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. For more information about service account requirements and recommendations, see Plan for administrative and service accounts in the Windows SharePoint Services 3.0 product documentation.

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 or technology, 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.

Server connections to backend data stores

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.
Avoid 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 all services that run under built-in accounts on that computer cannot connect to 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 Windows SharePoint Services instance.

Change History

Release	History
17 November 2008	New content: Added table with benefits and drawbacks of the authentication providers in the Authentication Providers in SharePoint Technologies section. Added new section "Best Practices for Configuring Authentication Providers in a Scale-Out Deployment."

Sdílet prostřednictvím