ssrs批量权限管理

So much has changed with Reporting Services 2016 but in terms of security it’s the same under the hood and that’s not necessarily a bad thing. SSRS has long had a robust folder & item level security model with the ability to inherit permissions from parent folders, much like SharePoint and windows in general.

Reporting Services 2016发生了很大变化，但就安全性而言，它是完全相同的，这不一定是一件坏事。 长期以来，SSRS一直具有可靠的文件夹和项目级别安全模型，能够从父文件夹继承权限，就像通常的SharePoint和Windows一样。

Managing this security model, however, can become difficult as the use of SSRS expands over years & even versions. 5 folders & 40 reports quickly become 30 folders, 200 reports and many different business units or even clients in the same environment. Once you introduce processes to move databases down to non-production environments, it quickly becomes a difficult task to maintain security never mind implement any changes or improvements. I want to outline some tips that have helped me over the years and some PowerShell scripts that will save you hours of clicking!

但是，随着SSRS的使用扩展了多年甚至是版本，管理此安全模型可能会变得困难。 5个文件夹和40个报告Swift变为30个文件夹，200个报告以及同一环境中的许多不同业务部门甚至客户。 一旦引入了将数据库移至非生产环境的流程，维护安全就变得困难重重，不必进行任何更改或改进。 我想概述一些多年来为我提供帮助的技巧，以及一些PowerShell脚本，这些脚本可以节省您的点击时间！

最佳做法和提示 (Best Practices & tips)

AD Groups reduce maintenance

广告组减少维护

It might be an obvious one, but it’s a basic rule in my opinion. Wherever possible, grant security in SSRS (& your database too) to AD groups and fill those groups with the relevant users. This gives you a single place to add/remove people, whether that’s a quarterly task or once every decade. Using AD groups may give you one more step to check “who has access to what” but it makes finding & maintaining those users significantly easier.

这可能是显而易见的，但我认为这是一条基本规则。 只要有可能，就将SSRS（和数据库也是如此）的安全性授予AD组，并用相关用户填充这些组。 无论是每季度一次还是每十年一次，这都使您可以在一个地方添加/删除人员。 使用广告组可以使您更进一步地检查“谁有权访问哪些内容”，但这使查找和维护这些用户变得更加容易。

Keep permissions to a minimum

保持最小权限

Reporting Services has several “out of the box” roles to choose from. If none of those fit the bill or a user needs wants slightly more than Browser access (i.e. View Data Sources) don’t just bump them up to full Content Manager.

Reporting Services具有多个“开箱即用”角色可供选择。 如果这些都不适合您，或者用户需要的内容比浏览器访问权限（即“查看数据源”）略多，请不要仅仅将它们添加到完整的Content Manager中。

By connecting to your Reporting Services instance via Management Studio (SSMS) you can View the built in security roles. From here you can Add permissions to an existing role or create a whole new role, if only a subset of users need the extra permissions.

通过Management Studio（SSMS）连接到Reporting Services实例，您可以查看内置的安全角色。 如果只有一部分用户需要额外的权限，则可以从此处向现有角色添加权限或创建一个全新的角色。

Some further reading on SSRS roles: Role Definitions – Predefined Roles

有关SSRS角色的进一步阅读： 角色定义–预定义角色

Clean up default Permissions

清理默认权限

You may have noticed that by Default, BUILTIN\Administrators is added as a Content Manager to the Home folder (and every inherited folder!). This is great for initial setup. It allows the server admin(s) to access Report Manager & get started without any security prerequisites.

您可能已经注意到，默认情况下， BUILTIN \ Administrators作为内容管理器添加到Home文件夹（以及每个继承的文件夹！）中。 这对于初始设置非常有用。 它使服务器管理员无需任何安全先决条件即可访问报表管理器并开始使用。

Beyond “Day 1” setup this should be removed. In the vast majority of implementations, the server admin will not be the Reporting Services admin, or there will always be people in one group who shouldn’t be in the other.

除“第1天”设置外，应将其删除。 在绝大多数实现中，服务器管理员将不是Reporting Services管理员，或者总是会有一个人不在一个组中。

If you leave this in place you are giving everyone who has administrator rights of the SSRS server full Content Manager access. This is best to remove at first implementation before your instance grows, folders get unique permissions and it’s no longer a single click to fix (though I’ll give you a fast way to fix it later!)

如果将其保留在原位，则将为拥有SSRS服务器管理员权限的每个人提供完全的Content Manager访问权限。 最好在实例增长之前首先删除它，文件夹获得唯一权限，并且不再需要单击即可修复（尽管稍后我会为您提供快速修复方法！）

Plan your Security Model

计划您的安全模型

When implementing Reporting Services from scratch, or any new technology/app, it can be too easy to just use a select few “service accounts” for multiple functions & tasks. Usually it’s a case of “whatever gets this fixed/online the fastest”. Using a single AD account for each function within SSRS is good practice & minimises security risk.

从零开始或任何新技术/应用程序实施Reporting Services时，仅使用少数几个“服务帐户”来实现多种功能和任务可能太容易了。 通常情况是“无论什么方式都能最快地解决这个问题。” 对SSRS中的每个功能使用单个AD帐户是一种很好的做法，并且可以最大程度地降低安全风险。

An example of accounts used in a production environment:

生产环境中使用的帐户示例：

• Domain\DataAccess for stored credentials in datasources. This account doesn’t need any access in SSRS or any server permissions. It may be granted db_datareader or more on the datasources it needed to access to. Domain \ DataAccess 。 此帐户不需要任何SSRS访问权限或任何服务器权限。 可以在需要访问的数据源上为它授予db_datareader或更多权限。
• Domain\Deploy would be used to deploy content to Reporting Services. This would only need the Publisher role in SSRS. It could also be a group of senior developers or a dev manager. Domain \ Deploy将用于将内容部署到Reporting Services。 这仅需要SSRS中的发布者角色。 也可以是一组高级开发人员或开发经理。
• Domain\Service is the account Reporting Services would run under. This would need the RSExecRole on the ReportServer DB (this is granted during configuration/install). This account would have no data access or Reporting services access. Domain \ Service是Reporting Services将在其下运行的帐户。 这将需要ReportServer DB上的RSExecRole（在配置/安装期间授予）。 此帐户将没有数据访问权限或Reporting Services访问权限。
• Domain\rsAdmins is an AD group with the admins who manage content & permissions. Generally, this group would not need data access Domain \ rsAdmins是一个AD组，其中包含管理内容和权限的管理员。 通常，该组不需要数据访问

Now, this level of separation isn’t always possible and in some smaller organizations a single person covers most of these functions so don’t take the above as a hard requirement. Using these separate domain accounts reduces a single point of failure caused by password lockouts & resets or compromised accounts.

现在，这种级别的分离并不总是可能的，在一些较小的组织中，一个人可以担负大部分这些职能，因此不要将上述作为硬性要求。 使用这些单独的域帐户可以减少由于密码锁定和重置或帐户遭到破坏而导致的单点故障。

PowerShell自动化 (PowerShell Automation)

There’s a great deal of automation that can be achieved with PowerShell in Reporting Services., I’ve detailed a few scripts below specific to this security topic, but there’s an abundance of content out there for many tasks, such as deploying reports, folders, data sources etc. Although I’ve focused primarily on native mode Reporting Services, there are also scripts that work with SharePoint integrated mode too.

在Reporting Services中使用PowerShell可以实现很多自动化。我在下面详细介绍了一些特定于此安全主题的脚本，但是其中有很多内容可用于许多任务，例如部署报告，文件夹，数据源等。尽管我主要侧重于本机模式Reporting Services，但也有一些脚本也可用于SharePoint集成模式。

Development environment security

开发环境安全

Unlike your production environment you may want to simplify your dev environment’s security to make it easier for developers to deploy & test without running into permissions issues. This is a good place to utilize Reporting Services’ inherit functionality. Setting all folders to “Revert to Parent Security” makes it easy to add/remove permissions to the whole environment from the top level folder.

与生产环境不同，您可能希望简化开发环境的安全性，以使开发人员更容易部署和测试而不会遇到权限问题。 这是利用Reporting Services继承功能的好地方。 将所有文件夹设置为“还原到父级安全性”可以轻松地从顶级文件夹向整个环境添加/删除权限。

If you ever need to copy down your production database this can be a mammoth task to update. This is where PowerShell comes in handy. The following simple script will revert all subfolders in an SSRS environment to Revert to Parent Security.

如果您需要复制生产数据库，这可能是一项艰巨的任务。 这就是PowerShell派上用场的地方。 以下简单脚本将还原SSRS环境中的所有子文件夹，以还原为“父级安全性” 。

#---------------------------------------------
# Author:   Craig Porteous
#       @cporteous
# Synopsis:     Revert all SSRS (native mode)
#       folders to inherit from Parent
#       Security
#---------------------------------------------Clear-Host
$ReportServerUri = 'http://PorteousSQL1/ReportServer/ReportService2010.asmx?wsdl'
$InheritParent = $true$rsProxy = New-WebServiceProxy -Uri $ReportServerUri -UseDefaultCredential
#List out all subfolders under the parent directory
$items = $rsProxy.ListChildren("/", $true) | `select TypeName, Path, ID, Name | `Where-Object {$_.typeName -eq "Folder"}
#Iterate through every folder
foreach($item in $items)
{$Policies = $rsProxy.GetPolicies($Item.Path, [ref]$InheritParent)#Skip over folders already marked to Inherit permissions. No changes needed.if(-not $InheritParent){#Set folder to inherit from Parent security$rsProxy.InheritParentSecurity($item.Path)}
}

You may need to adjust the .asmx file for different versions of SSRS though this should work just fine in 2012 onwards.

您可能需要针对不同版本的SSRS调整.asmx文件，尽管从2012年起这应该可以正常工作。

Security auditing

安全审核

If you’re inheriting an existing environment or even want to overhaul/audit your current security, the following PowerShell script will allow you to quickly output every folder’s security to csv allowing you to analyse erroneous permissions without searching through folders in Report Manager.

如果您要继承现有环境，或者甚至想彻底检查/审核当前的安全性，则以下PowerShell脚本将使您可以将每个文件夹的安全性快速输出到csv，从而使您无需在报表管理器中搜索文件夹就可以分析错误的权限。

#---------------------------------------------
# Author:   Craig Porteous
#       @cporteous
# Synopsis:     List out all SSRS (native mode)
#       folders & their security policies
#       & output dataset to CSV file
#---------------------------------------------Clear-Host
$ReportServerUri = 'http://PorteousSQL1/ReportServer/ReportService2010.asmx?wsdl'
$InheritParent = $true
$SSRSroot = "/"
$rsPerms = @()
$rsResult = @()$rsProxy = New-WebServiceProxy -Uri $ReportServerUri -UseDefaultCredential
#List out all subfolders under the parent directory and Select their "Path"
$folderList = $rsProxy.ListChildren($SSRSroot, $InheritParent) | Select -Property Path, TypeName | Where-Object {$_.TypeName -eq "Folder"} | Select Path
#Iterate through every folder
foreach($folder in $folderList)
{#Return all policies on this folder$Policies = $rsProxy.GetPolicies( $folder.Path, [ref] $InheritParent )#For each policy, add details to an arrayforeach($rsPolicy in $Policies){[array]$rsResult = New-Object PSObject -Property @{"Path" = $folder.Path;"GroupUserName" = $rsPolicy.GroupUserName;"Role" = $rsPolicy.Roles[0].Name}$rsPerms += $rsResult}
}
#Output array to csv named after instance URL
$rsPerms | Export-Csv -Path "C:\$ReportServerUri.csv" -NoTypeInformation

Targeted Changes

目标变更

Following a security review, you may want to add or remove a single AD account/group across every folder in your environment. There may be many occasions that call for such a blanket change. Again, this would normally be a laboriously manual task without PowerShell. These little snippets show how it can be done & you can always edit these to target a specific folder (& all its sub-folders).

经过安全检查后，您可能希望在环境中的每个文件夹中添加或删除单个AD帐户/组。 在很多情况下，都需要进行这样的全面更改。 同样，如果没有PowerShell，这通常是一项费力的手动任务。 这些小片段显示了如何完成操作，您始终可以对其进行编辑以针对特定文件夹（及其所有子文件夹）。

#---------------------------------------------
# Author:   Craig Porteous
#       @cporteous
# Synopsis: Add a specific user/group to all
#       SSRS (native mode) folders with a
#       specified Role. Excludes inherited
#       folders
#---------------------------------------------Clear-Host
$ReportServerUri = 'http://PorteousSQL1/ReportServer/ReportService2010.asmx?wsdl'
$InheritParent = $true
$GroupUserName = 'Domain\Deploy'
$RoleName = 'Publisher'$rsProxy = New-WebServiceProxy -Uri $ReportServerUri -UseDefaultCredential
$type = $rsProxy.GetType().Namespace;
$policyType = "{0}.Policy" -f $type;
$roleType = "{0}.Role" -f $type;
#List out all subfolders under the parent directory
$items = $rsProxy.ListChildren("/", $true) | `SELECT TypeName, Path, ID, Name | `Where-Object {$_.typeName -eq "Folder"}
#Iterate through every folder
foreach($item in $items)
{$Policies = $rsProxy.GetPolicies($Item.Path, [ref]$InheritParent)#Skip over folders marked to Inherit permissions. No changes needed.if($InheritParent -eq $false){#Return all policies that contain the user/group we want to add$Policy = $Policies | Where-Object { $_.GroupUserName -eq $GroupUserName } | Select-Object -First 1#Add a new policy if doesnt existif (-not $Policy) {$Policy = New-Object ($policyType)$Policy.GroupUserName = $GroupUserName$Policy.Roles = @()#Add new policy to the folder's policies$Policies += $Policy}#Add the role to the new Policy$r = $Policy.Roles |Where-Object { $_.Name -eq $RoleName } |Select-Object -First 1if (-not $r) {$r = New-Object ($roleType)$r.Name = $RoleName$Policy.Roles += $r}#Set folder policies$rsProxy.SetPolicies($Item.Path, $Policies);}
}

You can then use the following script to remove a user/group or reverse the change made in the last script.

然后，您可以使用以下脚本删除用户/组或撤消在上一个脚本中所做的更改。

#---------------------------------------------
# Author:   Craig Porteous
#       @cporteous
# Synopsis: Remove a specific user/group from
#       all SSRS (native mode) folders.
#       Excludes inherited folders
#---------------------------------------------Clear-Host
$ReportServerUri = 'http://PorteousSQL1/ReportServer/ReportService2010.asmx?wsdl'
$InheritParent = $true
$GroupUserName = 'PORTEOUSSQL1\pInstall'$rsProxy = New-WebServiceProxy -Uri $ReportServerUri -UseDefaultCredential
#List out all subfolders under the parent directory
$items = $rsProxy.ListChildren("/", $true) | `SELECT TypeName, Path, ID, Name | `Where-Object {$_.typeName -eq "Folder"}
#Iterate through every folder
foreach($item in $items)
{$Policies = $rsProxy.GetPolicies($Item.Path, [ref]$InheritParent)#Skip over folders marked to Inherit permissions. No changes needed.if($InheritParent -eq $false){#List out ALL policies on folder but do not include the policy for the specified user/group$Policies = $Policies | Where-Object { $_.GroupUserName -ne $GroupUserName }#Set the folder's policies to this new set of policies$rsProxy.SetPolicies($Item.Path, $Policies);}
}

NOTE: The above targeted scripts won’t add or remove users or groups from the top level folder. This process can be easily added, though I’ve omitted it to reduce the risk of removing an admin user/group from the entire site and in the case of adding users, I’ve worked with RS instances where multiple clients share a single instance and only admin accounts have access to the top level “home”.

注意：上述目标脚本不会在顶层文件夹中添加或删除用户或组。 此过程可以轻松添加，尽管我省略了它以减少从整个站点中删除管理员用户/组的风险，并且在添加用户的情况下，我使用了多个客户端共享一个实例的RS实例并且只有管理员帐户才能访问顶级“主页”。

爱PowerShell！ (Love PowerShell!)

I hope I’ve provided a few examples of security practices in SSRS and some basic PowerShell scripts to automate administration of security in Reporting Services. You can build upon these scripts to do more advanced tasks such as setting instance wide security from an input file (good for refreshing other environments from production backups.

希望我提供了SSRS中的一些安全实践示例以及一些基本的PowerShell脚本，以在Reporting Services中自动进行安全性管理。 您可以在这些脚本的基础上执行更多高级任务，例如从输入文件设置实例范围的安全性（有益于从生产备份刷新其他环境）。

I know there is a lot of good work going into PowerShell for DBA tasks over at dbatools.io that shows PowerShell is something you want on your tool belt!

我知道在dbatools.io上可以完成许多用于DBA任务的PowerShell的工作，这表明PowerShell是您想要的工具！

Microsoft also put together a bunch of PowerShell scripts for Reporting Services late last year. You can find the article: Community contributions to the PowerShell scripts for Reporting Services & the scripts are on GitHub here: ReportingServicesTools

去年年底，Microsoft还为Reporting Services整理了一堆PowerShell脚本。 您可以找到以下文章： 社区对Reporting Services的PowerShell脚本的贡献以及这些脚本在GitHub上的此处： ReportingServicesTools

看更多 (See more)

For SSRS documentation, consider ApexSQL Doc, a tool that documents reports (*.rdl), shared datasets (*.rsd), shared data sources (*.rds) and projects (*.rptproj) from the file system and web services (native and SharePoint) in different output formats.

对于SSRS文档，请考虑ApexSQL Doc ，该工具可记录文件系统和Web服务中的报告（* .rdl），共享数据集（* .rsd），共享数据源（* .rds）和项目（* .rptproj）（本机和SharePoint）以不同的输出格式显示。

参考资料 (References)

• Role Definitions – Predefined Roles 角色定义–预定义角色
• DBATools page DBATools页面
• Community contributions to the PowerShell scripts for Reporting Services 社区对Reporting Services的PowerShell脚本的贡献
• Reporting Services Powershell Tools Reporting Services Powershell工具

翻译自: https://www.sqlshack.com/managing-ssrs-security-using-powershell-automation-scripts/

ssrs批量权限管理