By: Scott Murray | Comments (36) | Related: > Reporting Services Security
Problem
As you begin developing reports for deployment to a Report Server, what security considerations need to be taken into account in order to grant users access to run a report.
Solution
Securing Reporting Services can be a daunting task for a rookie report developer. In this tip, we will focus on SQL Server Reporting Services 2012 (SSRS), although many of the items also apply to SSRS 2008 R2. Security consists of two main components: security and access at the Report Server level and authentication and permission at the data source level. Within this tip, we will cover Report Server Permissions first and then move on to database level security. Coverage of permission needed for a SSRS server in SharePoint integrated mode will be covered in a later tip.
SQL Report Server Permissions
Within the SSRS website, the first item to setup is to create system level permissions; these permissions are assigned to the main administrators of SSRS and the "power" users who publish reports. Similar to SSAS, SSRS uses a role concept. Two main roles, System Administrator and System User are predefined. Assignment to these roles is made by clicking on Site Setting in the upper right corner of the report server site; next click on the Security link from the left menu. Local and active directory groups and users can be assigned to either of these roles; however SQL Server logins cannot.
Clicking on the Edit option allows you to add, edit, or remove the roles assigned to the user or group as displayed in the below figure. Generally the System Administrator role is reserved for those who need to have full control over the Report Server whereas the System User role is applied to users / groups who are power users of the Report Server.
Moving beyond the system level roles, permissions must also be applied at the folder and report level on the Report Server. Similar to the System Assignments, a local or active directory user or group can be assigned to one or more roles. SSRS includes 5 predefined roles that should suffice in most circumstances. These roles include:
- Browser-allows users to run reports and browse folders; this role will be used by most end users
- Content Manager-allows users to manage and define folders and reports and to grant permissions
- Report Builder-allows users to create Report Builder reports
- Publisher-allows users to deploy / upload reports and create folders
- My Reports-allows users to create and maintain personal MyReports folders
More details on each of these predefined roles can be found at: http://msdn.microsoft.com/en-us/library/ms157363.aspx.
In order to assign permissions to a report or folder, first select the desired report or folder and then click the down arrow on the right side of the report or folder name. Then select the security option from the left hand menu.
In the Group or User name textbox, enter the group or user name (prefixed with the appropriate domain if needed). Next, the appropriate role or roles must be selected and then last, click OK. As noted previously, most day to day users will only need the Browser role. Most high level power users will need to be assigned to either the Content Manager or Publisher role.
Some additional attention needs to directed to how permissions are inherited by subfolders and reports. First, the role assignments use a waterfall methodology. Thus, starting at the home page, all folders, subfolders, or reports underneath the home page in the hierarchy will have the same permission that are assigned to the home page UNLESS the permission chain is broken, either at the folder, subfolder, or report level. Clicking on the Edit Item Security button, as displayed below, will break the permission chain and allow for the customization of the security for that individual folder or report.
Selecting this option prompts the following warning to be displayed. After clicking OK, permissions must be maintained for that individual folder or report; changes to folders above this level including the home page are no longer utilized or considered.
Fortunately, if at some point you would like to go back to having your folder or report inherit its permission from a parent structure, you can click on the Revert to Parent Security button.
In addition to using the predefined roles in SSRS, customized roles can be created and used. Furthermore, the current set of the predefined roles can be altered; however, I highly recommend leaving the predefined roles as is, and create new roles with the appropriate permissions. Contrary to some older version of SSRS, in SSRS 2012, new roles and adjustments to existing roles must be performed in SQL Server Management studio, SSMS. After opening up SSMS, change the server type to Reporting Services, enter your Server Name, and login information and then click Connect. After connecting to the Report Server, open the Security Folder, as noted in the following screen print. Notice under the security tab, two Role Types Exist, one for the System Roles and one for the "regular user" Roles.
Right mouse clicking on Roles and Selecting New Role opens the New User Role window, which allows for the naming of the role and selection of particular tasks to assign to this new role.
Once created, these custom roles will now appear in the role assignment list as displayed in the below figure.
Once the SSRS report and folder level security has been planned and implemented, a second area of security must also be handled; as discussed next, this task centers around the security ramifications of the actual data itself and what access is granted to that data.
Database Level Security
For many DBA's and DWA's this second area of consideration is likely a more familiar topic. Specifically, for all data objects (ie tables, views, stored procedures) used in a particular report, the user running the report must have appropriate permissions to access the data and its related object (ie select permissions for tables and view and execute permissions for stored procedures). One decision that must be made early on in the report design process is whether the reporting user to be authenticated by SSRS will be a SQL Server Login or a Windows / Active Directory login. This decision is made in BIDS (Visual Studio 2010 using the Business Intelligence Development addin), specifically during the creation of the DataSource for the project, as noted in the below image.
The advantages of using Windows Authentication center around ease of maintenance and administration of the user whereas the use of the SQL Server login allows for the avoidance of the double hop issue ( see http://blogs.technet.com/b/rob/archive/2011/11/23/enabling-kerberos-authentication-for-reporting-services.aspx for details about the double hop issues).
Once the decision is made about which authentication method is used, the next step includes granting the appropriate privileges, whether to a windows user or group or a SQL Server login, for all objects involved in the dataset queries for the report. Of course these grants could include execute permissions on a stored procedure or select permissions for a group of tables and views.
At this point, I will make the assumption that the reader is familiar with granting such permission (if not please see these tips from Brian Kelly--> http://www.mssqltips.com/sqlservertip/1718/database-level-permissions-for-sql-server-2005-and-2008/ or http://www.mssqltips.com/sqlservertip/2739/issues-determining-an-individual-sql-server-users-permissions/ or from Greg Robidoux --> http://www.mssqltips.com/sqlservertip/1138/giving-and-removing-permissions-in-sql-server/ ).
One strategy that I have heard has had success is the utilization of a User Group instead of individual users role assignment. For example, a group is granted database object permissions, such as executing a particular stored procedure, and that same group is assigned to the Browser role on the Report Server. Users are then added to this group, and their permissions automatically flow through to both the appropriate database objects and to the appropriate report server folders.
Conclusion-SSRS 2012 Security
Implementing SSRS Security requires a two step approach. Object permissions must be granted at the database level while SSRS folder and report level permissions requires that a user be assigned to one or more SSRS roles. Several predefined roles exist and will suffice for much of your permission needs. However, customized roles can also be generated.
Next Steps
- Roles Items Level Task Details: http://msdn.microsoft.com/en-us/library/ms160344.aspx
About the author
Scott Murray has a passion for crafting BI Solutions with SharePoint, SSAS, OLAP and SSRS.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
