我已经和几位同事谈了在我们的环境中使用组pipe理服务帐户的最佳做法。
理想情况下，我们将为每个服务器（例如SQLDEV01）创build每个服务1个gMSA（例如SQL Agent服务）。
这样可以最大限度地分散担忧，如果任何服务帐户（受损，删除，locking，损坏等）出现任何问题，只会影响与其关联的单个服务和单个服务器。
这种方法唯一的缺点就是可能会有大量的gMSA来创build。 但是有了这个说法，一旦创build，就没有太多的需要去pipe理它们了。
我遇到的另一个问题是命名gMSA（我相信它必须是15个字符或更less）。 想出一个名字来表示这个账户是gMSA，是为了一个特定的服务，还是为一个特定的服务器，这似乎是非常困难的。
例如，遵循典型约定的通用名称可能如下所示：
它可以缩写为：
上面的例子恰好是15个字符，没有空余空间用于其他可能更长的服务器或服务名称。
有没有最好的做法或方法来处理这些情况：
关注点的分离将主要取决于您的环境，并在某些情况下权衡分离事务与简单共享帐户的麻烦。 我的意思是与原始MSA相比，gMSA的主要function之一是它们可以被多个系统使用。
关于长名字…
你可以通过不给它一个像gmsa这样的前缀来轻松释放一些空间。 虽然它在与普通用户帐户相关的objectClass属性中共享了很多通用类，但它也包含了自己唯一一个名为msDS-GroupManagedServiceAccount的通用类，它使您可以轻松地在要包含或排除它们的filter中使用。 gMSA在GUI工具（如ADUC等）中在视觉上也是不同的。 所以假设，人们不会在日常活动中将其与普通的用户帐户相混淆。
在玩这个的时候我也注意到了另一件事情。 即使New-ADServiceAccount cmdlet实际上对-SamAccountName强制实施了15个字符的限制， -SamAccountName使用ADSIEdit手动创buildmsDS-GroupManagedServiceAccount对象只会强制实施20个字符的限制。
我没有得到任何testing我的20字符长度的gMSA。 所以我不知道，如果它实际上与任何东西。 但是如果你想要在你的命名约定中有更多的空间，那么你可能还需要进一步的testing。