我与几位同事讨论了在我们的环境中使用组管理服务帐户的最佳实践。
理想情况下,我们应该为每个服务器(例如,gMSA )创建一个服务(例如SQL服务)。
这将允许最大限度地分离关注点,如果任何服务帐户(受损、删除、锁定、损坏等)出现任何问题,则只会影响与其关联的单个服务和单个服务器。
这种方法的唯一缺点之一是可以创建大量的gMSA。但话虽如此,一旦它们被创造出来,就没有什么必要去管理它们了。
我遇到的另一个问题是命名gMSA (我相信它必须是15个字符或更少)。想出一个名称来表示帐户是gMSA,用于特定的服务和特定的服务器,似乎是非常困难的。
例如,遵循典型约定的通用名称可能如下所示:
它可以缩短为以下内容:
上面的示例正好是15个字符,没有空间为其他可能更长的服务器或服务名称腾出空间。
是否有任何最佳做法或方法来处理这些情况:
发布于 2017-04-20 03:52:51
关注点的分离将在很大程度上取决于您的环境,并权衡在某些场景中分离事物的麻烦和共享帐户的简单性。我的意思是,gMSA相对于原始MSA的主要特性之一是,它们可以被多个系统使用。
关于长名字..。
您可以轻松地释放一些空间,方法是不给它提供像gmsa这样的前缀。虽然它在objectClass属性中共享许多与普通用户帐户相关的公共类,但它还包含自己的唯一类msDS-GroupManagedServiceAccount,这使得它很容易在筛选器中使用,在筛选器中您可能希望包含或排除它们。在GUI工具(如ADUC等)中,gMSA在视觉上也是不同的。所以假设,人们不会把他们和日常活动中的普通用户帐户混为一谈。
我在玩这个的时候也注意到了另一件事。尽管New-ADServiceAccount cmdlet确实对-SamAccountName强制执行了15个字符限制,但是使用ADSIEdit手动创建msDS-GroupManagedServiceAccount对象只会强制执行20个字符限制。
我并没有真正测试我的20个字符长度的gMSA。所以我不知道它是否真的适用于任何东西。但是,如果您想要在命名约定中有更多的喘息空间,那么您可能需要进一步的测试。
https://serverfault.com/questions/845416
复制相似问题