我需要在200台服务器的Windows 2003/2008networking中设置一个组织系统pipe理员权限的计划。 服务器存在于通过双向信任连接的5个独立森林中。
目前，我主要关注如何最好地组织团队。 所有系统pipe理员在其中一个森林（森林A）中有一个pipe理员帐户，我希望他们使用此帐户来pipe理一切。
据我所知，通常的最佳做法是：
将资源授予其存在的本地林中的域本地组。 我已经通过创build像ForestB \ MemberServerAdmins，ForestB \ DCDNSAdmins，ForestC \ ExchangeReadOnlyAdmins等组来完成此操作，并且已经委派来自各种应用程序的这些组的访问权限。
按用户angular色将用户组织到林A中的全局组中，然后根据需要将这些全局组放到域本地组中。 我想这可能会被完成，例如，你有一个像ForestA \ Operations这样的组织的部门，他们可以访问一些资源组，而不是所有的资源组和另一个组，比如ForestA \ Admins，他们可以访问所有的资源组。 这只是一个例子。
问题是，我们确实需要将这些权限分配给个人。 我们是一家规模较小的公司，我没有批量的用户需要所有相同的权限。 这使得上面的步骤＃2似乎不适合我们。 我留下来的解决scheme是在ForestA中创build全局组，它们具有与各种资源组基本相同的名称，如下所示：
ForestA \ ForestB成员服务器pipe理员
ForestA \ ForestB DCDNSAdmins
ForestA \ ForestC ExchangeReadOnlyAdmins
然后将个人pipe理帐户放入这些组中。
我得到了这个两组解决scheme分配资源的灵活性，但是这样做是否合理呢？ 我喜欢它，因为那样我就可以pipe理ForestA中的所有权限，并轻松查看任何pipe理员帐户，以查看他们所在的组，以确定他们有权访问哪些组。 不过，我不确定这是最好的路线吗？
这样做的一个好处是当你有人事变动。 由于所有内容都是通过组设置的，因此您可以创build新帐户，在域A中填充全局组，然后进行设置。
我不确定你在想什么作为替代scheme，但是如果你只是直接把来自域A的用户对象放到其他域的域本地组中，你会失去一些可见性。 如果您查看位于域B中的域本地组中的域A中的用户对象，则不一定会在该用户的“成员”选项卡中看到该域本地组。 因此，要知道用户具有什么访问权限，您必须绕过寻找用户对象的各个域本地组。 如果您使用这里提到的全局/本地风格，则只需查看用户的全局组成员资格即可快速了解其访问权限。
另外，使用组结构使其更容易成长。 如果你从一开始就不把这些小组放在一起，最终的增长可能会让你想要他们，而后来做这些小组的时候可能会很痛苦。 （不一定是，但可以…）
只是一些想法，希望它有帮助。