Learn more about SQL Server tools


Latest SQL Server Tips

Free SQL Server Learning

World's Worst Performance Tuning Techniques

SQL Server backup automation and best practices

Providing High Availability to an Existing SQL Server Workload

Backup made easy with SQL Safe Backup

High Availability, Disaster Recovery, Low Cost Storage, and SIOS DataKeeper

SQL Server Performance Monitoring in the Cloud

SQL Server Reporting Services 2012 Permissions

MSSQLTips author Scott Murray By:   |   Read Comments (27)   |   Related Tips: > Reporting Services Security

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.


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.


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

join MSSQLTips for free SQL Server tips     

Learn more about SQL Server tools
Post a comment or let the author know this tip helped you.

       All comments are reviewed, so stay on subject or we may delete your comment.

*Name   *Email Notify for updates

       Note: your email address is not published. Required fields are marked with an asterisk (*)

Get free SQL tips:

*Enter Code refresh code     

Friday, February 27, 2015 - 7:58:36 AM - Scott Read The Tip

I would recommend taking a look at:


https://technet.microsoft.com/en-us/library/ms160330%28v=sql.110%29.aspx which talks about the SQL authentication details

Thursday, February 26, 2015 - 4:56:37 PM - Andrew Read The Tip

Can you elaborate a bit on teh pros and cons of using windows authentication vs a SQL Login in yoru datasource? The double hop complicates setup, but once setup is there any benefit to having windows authentication in place? Thanks

Tuesday, January 20, 2015 - 11:49:20 AM - scott Read The Tip


I am not aware of any way to limit the drop down list without doing some backend coding (maybe).

Monday, January 19, 2015 - 7:26:01 PM - Manish Read The Tip

Great article. Thanks!

I use SSRS 2012. I run into issue of OOB drop down menu that lists options like "Move", "Delete", "Secutiry" etc for folders and reports. The issue is, this drop down menu with all options available to users even with "Browser" role. Browser role has limited access - view reports and view folders. I do not want to show options not available to users with "Browser" role like Move, Delete, Edit Report etc. I appreciate any suggestion.

Is there a way to disable this drop down manu for certain roles or make it available only to System Admins or completely disable it?

Wednesday, September 24, 2014 - 11:42:36 AM - Scott Murray Read The Tip

Dinesh...  you might want to check the urs... Named Instances require the full name.  Go to the SSRS configuration manager to see each of the exact URL for the Report Manager and Report Server.

Wednesday, September 24, 2014 - 11:38:15 AM - Scott Murray Read The Tip

You do not need to be a system user to acess folders / files.

Wednesday, September 24, 2014 - 11:36:06 AM - Scott Murray Read The Tip

No a user does need system admin to access to folders and reports.

Wednesday, September 24, 2014 - 11:13:53 AM - Dinesh DBA Read The Tip

Hi team,

 server URL :- http://localhost/Reports_Dinesh/Pages/Folder.aspx
client Url:- http://localhost/ReportServer

On Named  instance  above both url are working.

But default instance server is working and clint url is not working..

Please sugget feasible way...

Tuesday, August 05, 2014 - 6:14:43 AM - Marios Philippopoulos Read The Tip

Thank you Scott, I'll try that.


Friday, August 01, 2014 - 11:14:43 AM - Scott Read The Tip

Mario... I would take a look at the

dbo.PolicyUserRole dbo.Policies
tables in the ReportServer database


Friday, August 01, 2014 - 10:28:12 AM - Marios Philippopoulos Read The Tip


Is there a query we can run on the ReportServer db to get all folders for which parent-folder inheritance of permissions is broken?

Thank you for this post,

Marios Philippopoulos

Tuesday, July 29, 2014 - 1:34:37 PM - Scott Murray Read The Tip

Members of the content managers role should not be able to delete the system roles unless they are members of the local admin group. 

I would take a look at:









Tuesday, July 29, 2014 - 12:05:55 PM - Kathy Read The Tip

Do Content Managers have the ability to delete the BuiltIN\Administrators security? I'm setting up security for the first time. This is the first time our organization is using ssrs. Any pointers would be appreciated.




Tuesday, July 22, 2014 - 2:36:08 PM - Kenneth Baker Read The Tip

I displayed admin under site setting -> security

I found this article that restored the sub menus.


Browser/compatibility issue. I added the ssrs site to the list and seems to working.

Thank you for your time and your consideration.

Tuesday, July 22, 2014 - 12:54:38 PM - Scott Read The Tip

Kenneth... Sound like you are no longer an administrator.... go to site settings > Security. Is your id a system administrator.

Tuesday, July 22, 2014 - 12:37:42 PM - Kenneth Baker Read The Tip


article SQL Server Reporting Services 2012 Permissions


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.

my login has lost the ability to access the down arrow, i.e. the down arrow does not high light. Other logins can access the sub menu.

I cannot find any security settings or changes that prevent this


Any help would be greatly appreciated



Kenneth L. Baker

Applications Developer


(o) (817) 385-8342








United States Bowling Congress


621 Six Flags Drive, Arlington TX 76011


(800) 514-BOWL | BOWL.COM




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

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.

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


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

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?

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

Great post, thank you so much for sharing!

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, 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?


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


 However, I have not confirmed this item.

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.

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

No they do not need to be a system user.

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?

Sponsor Information