In this article, we will explore the functionality to secure reporting Services with Group Managed Service accounts ( GMSA)

在本文中，我们将探讨使用组托管服务帐户（GMSA）保护报告服务的功能。

With Reporting Services’ (SSRS) ability to scale out to multiple hosts, you may quickly come across the need to reuse domain accounts. Updating passwords for such accounts becomes a lengthy and risky process often requiring downtime. You may have a reliable process, set in stone for updating service account credentials every 30, 60 or 90 days or you could be stumbling across accounts that haven’t changed in 5 years and the passwords are in a shared text file somewhere. In either case, there’s risk that’s hard to mitigate without magically creating more hours in the day.

利用Reporting Services（SSRS）的能力可以扩展到多个主机，您可能会很快遇到重用域帐户的需求。 更新此类帐户的密码变得冗长而危险，通常需要停机。 您可能有一个可靠的过程，每30、60或90天都会更新服务帐户凭据，或者您可能遇到5年未更改的帐户，并且密码位于某个位置的共享文本文件中。 无论哪种情况，如果没有一天神奇地创造更多时间，就很难缓解这种风险。

The same trouble probably applies to other applications or components of SQL Server but I want to demonstrate how to better secure SSRS while simultaneously reducing administrative effort and service downtime. This holy grail can be achieved by utilizing a feature introduced in Windows Server 2012 called Group Managed Service Accounts (GMSA).

同样的问题可能也适用于SQL Server的其他应用程序或组件，但我想展示如何更好地保护SSRS，同时减少管理工作量和服务停机时间。 可以通过利用Windows Server 2012中引入的称为组托管服务帐户（GMSA）的功能来实现这一目标。

GMSA take the same functionality of Managed Service Accounts, introduced in Windows Server 2008 R2, and make it usable, most importantly, across multiple hosts. If this is all new information, I’ll explain a little about gMSAs:

GMSA具有Windows Server 2008 R2中引入的托管服务帐户的相同功能，最重要的是，它可以在多个主机上使用。 如果这是所有新信息，我将对gMSA进行一些解释：

A GMSA is an active directory (AD) account that requires no password. They can be “applied” to a group of host servers in AD and then used to run a service on all those hosts. Passwords are auto generated, managed, and reset every 30 days by Active Directory, requiring no user maintenance. You can find more specifics on how that all works on this great blog post by Doug Symalla.

GMSA是不需要密码的活动目录（AD）帐户。 它们可以“应用于” AD中的一组主机服务器，然后用于在所有这些主机上运行服务。 密码由Active Directory每30天自动生成，管理和重置一次，不需要用户维护。 在Doug Symalla撰写的出色博客文章中，您可以找到更多关于这些工作原理的详细信息 。

Unlike the first iteration of this technology in MSAs you can use GMSAs with SQL Server, its component applications (SSRS) and even run scheduled tasks. They are a little more complex to set up, so I’ll cover all of the steps here.

与MSA中此技术的第一次迭代不同，您可以将GMSA与SQL Server，其组件应用程序（SSRS）一起使用，甚至运行计划的任务。 它们的设置有点复杂，因此在这里我将介绍所有步骤。

制备 (Preparation)

To create and enable a GMSA, first ensure that the hosts that you would like to involve, exist in a Security Group that is the lowest domain level necessary. Typically, this would be a Domain Local group. Here’s one I created with my SSRS servers in it, called SSRSDEV.

要创建和启用GMSA，首先请确保您要参与的主机位于最低域级别所需的安全组中。 通常，这将是“本地域”组。 这是我使用SSRS服务器创建的，称为SSRSDEV。

If this is the first time using GMSAs or MSAs in your AD forest, we’ll need to also create the KDS Root Key. This is used by the KDS service to generate passwords. From a domain controller execute the following PowerShell command:

如果这是您的AD林中首次使用GMSA或MSA，则我们还需要创建KDS根密钥。 KDS服务使用它来生成密码。 从域控制器执行以下PowerShell命令：

Add-KDSRootKey –EffectiveImmediately

You can also use this command if you want to avoid the built-in 10-hour wait designed to ensure propagation to all other domain controllers:

如果要避免为确保传播到所有其他域控制器而设计的内置10小时等待，也可以使用此命令：

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

创建GMSA (Creating the GMSA)

We are now ready to create the gMSA using the following Powershell command from a domain controller:

现在，我们准备使用来自域控制器的以下Powershell命令来创建gMSA：

PS> New-AdServiceAccount –Name SSRSgMSA –DnsHostName myDNS.domain.com –PrincipalsAllowedToRetrieveManagedPassword SSRSDEV

You can see we have set the security group as the group that’s allowed to retrieve the password.

您可以看到我们已将安全组设置为允许检索密码的组。

We’ve now created our group managed service account and we’ve told it which hosts are allowed to use it. The next step is to install the GMSA on the hosts inside our security group, the ones we’ll use it on. Again, we can do this in PowerShell which is great but if you’re not a fan, there is no other method I’m afraid.

现在，我们已经创建了组托管服务帐户，并告诉它允许哪些主机使用它。 下一步是将GMSA安装在我们将在其上使用的安全组内的主机上。 同样，我们可以在PowerShell中执行此操作，这很棒，但如果您不是粉丝，那么恐怕没有其他方法。

Before running these commands we will need to ensure that the Active Directory module is installed. This can be added as a feature in the Server Manager:

在运行这些命令之前，我们需要确保已安装Active Directory模块。 可以将其作为功能添加到服务器管理器中：

Select Active Directory module for Windows PowerShell found under Remote Server Administration Tools > Role Administration Tools > AD DS and AD LDS Tools. Or you can do this with PowerShell:

选择位于“远程服务器管理工​​具”>“角色管理工具”>“ AD DS和AD LDS工具”下的Windows PowerShell Active Directory模块 。 或者，您可以使用PowerShell执行此操作：

PS> Add-WindowsFeature RSAT-AD-PowerShell

Now we can “Install” the gMSA on the server:

现在，我们可以在服务器上“安装” gMSA：

PS> Install-ADServiceAccount SSRSgMSA

We can then test that the account installed on the host correctly by running this:

然后，我们可以通过运行以下命令来测试主机上是否正确安装了该帐户：

PS> Test-ADServiceAccount SSRSgMSA

The test command should return True or you’ll receive a verbose error message.

测试命令应返回True，否则您将收到详细的错误消息。

With SSRS and most other applications, you’ll also need to consider setting Service Principal names if you want Kerberos authentication to work properly. With SQL Server the application does this for you so you don’t need to worry about that. As we’re setting up SSRS I’ll demonstrate what you need to do.

对于SSRS和大多数其他应用程序，如果希望Kerberos身份验证正常工作，则还需要考虑设置服务主体名称。 使用SQL Server，应用程序可以为您执行此操作，因此您无需担心。 在设置SSRS时，我将演示您需要做的事情。

This is the command to make changes to the service principal names on the gMSA. SPNs are passed through the -ServicePrincipalNames parameter as an array:

这是在gMSA上更改服务主体名称的命令。 SPN通过-ServicePrincipalNames参数作为数组传递：

Set-ADServiceAccount SSRSgMSA -ServicePrincipalNames @{Add=”value1”,”value2”,”...”}

You can also use this command to make other changes to the SPNs too

您也可以使用此命令对SPN进行其他更改

To remove values, use the following:

要删除值，请使用以下命令：

-ServicePrincipalNames @{Remove=”value1”,”value2”,”...”}

To replace values:

替换值：

-ServicePrincipalNames @{Replace=”value1”,”value2”,”...”}

To clear all values:

要清除所有值：

-ServicePrincipalNames $Null

You can specify more than one change by separating the arrays by semicolons. For example, use the following syntax to add and remove service principal names.

通过用分号分隔数组，可以指定多个更改。 例如，使用以下语法来添加和删除服务主体名称。

@{Add=”value1”,”value2”,”...”} ;@{Remove=”value1”,”value2”,”...”}

If you are making multiple changes to SPNs in a single command it’s worth noting that the operators are applied in the following order:

如果要在单个命令中对SPN进行多次更改，则值得注意的是，按以下顺序应用了运算符：

• Remove 去掉
• Add 加
• Replace 更换

You’ll also need to enable delegation for the new GMSA to utilize Kerberos authentication using the following PowerShell command:

您还需要使用以下PowerShell命令启用新GMSA的委派以利用Kerberos身份验证：

Set-ADServiceAccount –TrustedForDelegation $True –Identity SSRSgMSA

将GMSA添加到SSRS (Adding the GMSA to SSRS)

The last part of the process is to finally add the GMSA to the Reporting Services service.

该过程的最后一部分是最终将GMSA添加到Reporting Services服务中。

Open the Reporting Services Configuration Manager and from the Service Account tab delete the account info you have already and enter the GMSA name suffixed with a $ (dollar sign). This is important. Leave the password field blank and click Apply. (It will look like a password has been filled in once you Apply changes but you don’t provide this.

打开Reporting Services配置管理器，然后从“服务帐户”选项卡中删除您已经拥有的帐户信息，然后输入带有$（美元符号）后缀的GMSA名称。 这个很重要。 将密码字段保留为空白，然后单击“应用”。 （一旦您应用更改，但您未提供此密码，则好像已填写了密码。

If everything is configured correctly your SSRS host will now be using a group managed service account. Repeat this on each server in your scale-out deployment and you’re done.

如果一切配置正确，您的SSRS主机现在将使用组托管服务帐户。 在横向扩展部署中的每台服务器上重复此操作，操作完成。

将它带到云端 (Taking it to the cloud)

I’ve described how to setup and use gMSAs within an Active Directory domain but what if you have an SSRS Scale-out deployment in Azure, under Azure Active Directory? This great Docs article describes the steps required when using AAD and again, it’s easily setup using PowerShell.

我已经描述了如何在Active Directory域中设置和使用gMSA，但是如果您在Azure Active Directory下的Azure中有SSRS横向扩展部署，该怎么办？ 这篇出色的文档文章介绍了使用AAD时所需的步骤，再次介绍了使用PowerShell轻松进行设置的过程。

结论 (Conclusion)

GMSAs aren’t the simplest method to getting an environment set up and that probably doesn’t suit agile development or cases where environments are destroyed and created as needed, but the benefits in the long run outweigh the plethora of steps described above to get it up and running. Implementing this approach, if you don’t already employ gMSAs on other services shouldn’t be a hard sell to the business:

GMSA并不是设置环境的最简单方法，它可能不适合敏捷开发或根据需要销毁和创建环境的情况，但从长远来看，其好处远胜于上述获得它的众多步骤启动并运行。 如果您尚未在其他服务上使用gMSA，则实施此方法不应该对企业造成困难：

• Improved Security 增强安全性
• Reduced administration time 减少管理时间
• No downtime 无停机时间
• Elimination of human error in password update processes 消除密码更新过程中的人为错误

For some more in-depth detail on gMSAs and getting started with them check out this Docs page which goes into great detail on the security benefits, how to set a GMSA up and also how to remove it.

要详细了解gMSA并开始使用它们，请查看此“ 文档”页面 ，其中详细介绍了安全性优点，如何设置GMSA以及如何将其删除。

翻译自: https://www.sqlshack.com/how-to-secure-reporting-services-with-group-managed-service-accounts/