Learn more about SQL Server tools

solving sql server problems for millions of dbas and developers since 2006
join MSSQLTips for free SQL Server tips














































SQL Server Reporting Services 2012 Permissions

MSSQLTips author Scott Murray By:   |   Read Comments (11)   |   Related Tips: > 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.

site settings

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.

edit site settings

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.

security alternative

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.

new 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.

edit item security

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.

edit item security

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.

parent revert

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.

SSMS role edit

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.

new role
new role detail

Once created, these custom roles will now appear in the role assignment list as displayed in the below figure.

new role created

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.

datasource\

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


Last Update: 10/23/2012


About the author
MSSQLTips author Scott Murray
Scott Murray has a passion for crafting BI Solutions with SharePoint, SSAS, OLAP and SSRS.

View all my tips
Related Resources


print tip Print  
Become a paid author




Recommended For You








Learn more about SQL Server tools
Comments and Feedback:
Tuesday, October 23, 2012 - 12:11:21 PM - sqlfriend Read The Tip

For the users to be setup to have folder and report level persmissions, do they have to be a system user first?


Tuesday, October 23, 2012 - 4:40:19 PM - Scott Murray Read The Tip

No they do not need to be a system user.


Wednesday, October 31, 2012 - 8:00:32 AM - RichB Read The Tip

 

Do SQL logins in 2012 still travel over the wire in plain text as they used to?

 

If so, I always like to recommend that this is mentioned as a caveat in any statement suggesting people consider using SQL logins.

 

Certainly the older versions went over the network in very clear and obvious plaintext that any sniffer - eg wireshark - could easily pick up and harvest for reuse.


Wednesday, October 31, 2012 - 9:46:01 AM - scott murray Read The Tip

RichB... You are absolutely correct in stating your caveat.  I should have included that warning.  In SQL 2012, stored creditials are supposed to be encrypted...per

http://msdn.microsoft.com/en-us/library/ms160330.aspx

 However, I have not confirmed this item.


Wednesday, October 31, 2012 - 11:36:00 AM - Wade Read The Tip

Does any use SSRS for reporting to users outside of the organization?  For example having a report that is accessable to a certain department within the organization and accessable to a few employees from a different company/organization.  Of course these outside employee are not in AD.  Anyone have any suggestions/pointers on how to set up security for outside employees?  Has anyone use Active Directory Lite for something like this?

Thanks


Wednesday, October 31, 2012 - 3:35:05 PM - Scott Murray Read The Tip

You may want to explore some forms based authentication...http://msdn.microsoft.com/en-us/library/cc281383.aspx.  I have not personally set up this item in production.


Wednesday, April 17, 2013 - 1:35:14 PM - Lyn Barr Read The Tip

Great post, thank you so much for sharing!


Monday, July 01, 2013 - 5:10:22 PM - Sri Read The Tip

Hi There,

Its very interesting blog!!

I have a query here about the reports assignments to users.

lets say we have creeated 20 reports and how can we link these 20 reports in the portal.

all the compannies have intranet and users would like to check the reports in the companys portal.

 

here my question is that how can we show all those reports in the portal and also how can we risitrict the access to the users to use only ceartain reports only?


Tuesday, July 02, 2013 - 7:16:04 AM - Scott Read The Tip

Sri,

Sounds like you need a separate security for each report..


Monday, January 13, 2014 - 6:26:33 AM - Jim Read The Tip

What are the best ways to handle security with the database and SSRS on different servers.  Integrated security especially.


Monday, April 14, 2014 - 2:43:14 AM - ufuk Read The Tip

i find a bug ssrs website. my pc name is "us"

this "http://localhost/Reports" is problem but "http://us/Reports" is not problem



Post a Comment or Question

Keep it clean and stay on the subject or we may delete your comment.
Your email address is not published. Required fields are marked with an asterisk (*)

*Name   *Email Notify for updates

Signup for our newsletter


Comments
*Enter Code refresh code


 
Sponsor Information







Copyright (c) 2006-2014 Edgewood Solutions, LLC All rights reserved
privacy | disclaimer | copyright | advertise | about
authors | contribute | feedback | giveaways | user groups | community | events | first timer?
Some names and products listed are the registered trademarks of their respective owners.