让我以“没有简单的解决方案”作为开头可能会是一个冗长的答案。
解决这个问题需要一些战略性的工作（这就是为什么我建议不要将它转移到 SF）。

现在我将解释原因。

Windows 的核心主要基于访问控制的DAC 模型。
操作系统中的所有内容都可以通过 ACL 保护 - 文件、文件夹、注册表、命名管道、套接字、共享等。

使用 AD 组可以将其抽象为 RBAC 类型的模型，但在内部它仍然是 DAC 模型。（我的意思是，您可以为组（即角色）创建一个 ACE（访问控制条目），但您仍在创建一个 ACE——这将在访问时得到验证）。

强调“大部分”。
有几个明显的例外：

1. MAC 有一些实现 - 即完整性级别（在 Vista/7/2008 中）。
   但是，这通常是内部操作系统保护机制，通常不用于真正的访问控制（内置 UAC 除外）。通常.
2. 操作系统级别的权限。（虽然可以指定一个特定的用户来授予这些权限，但它的目的和功能是 RBAC 模型）。

但是等等，这只是在操作系统本身...
Windows 作为一个平台，允许并鼓励应用程序（第 3 方、MS 产品和操作系统插件）使用 AD 组成员身份作为 RBAC 机制：

1. 3rd 方应用程序可以通过简单的 AD/LDAP 查找来验证组成员身份——这些应用程序可能会存储组名并对其进行解析，或者保存组的 SID 并直接查询。
2. 不要忘记 SQL Server - 这主要基于（几种不同类型的）角色，但是通常建议最佳实践将 AD组添加到这些角色，而不是直接添加用户。
3. 只要我们使用它，COM+ 还可以通过 RBAC 管理访问，但最佳实践还是将组而不是用户添加到 COM+ 角色。
4. Sharepoint 还根据角色/组/和邮件列表管理对站点的访问...

开始明白我的意思了吗？
我不想说这毫无希望，但是...

回顾一下：
为了找到特定组拥有的最终权限列表，您（或工具）需要递归检查以下所有内容（并且，不要忘记递归组成员身份）：

• 对于您组织中的每台服务器：
  • 递归检查所有文件夹和文件的 ACL
  • 递归检查所有文件夹和文件的SACL（系统访问控制列表 - 这些控制审计）
  • 递归检查所有文件夹和文件的所有者
  • 递归检查所有注册表项的 ACL、SACL 和所有者
  • 递归检查所有命名管道、进程和线程、服务、作业等的 ACL、SACL 和所有者。
  • 检查所有操作系统级别的权限（尽管使用 GPO 可能会更容易......）
  • 检查所有 COM+ 角色、MSMQ 角色等。
• 对于您的 AD 中的每个域：
  • 检查所有域级权限
  • 检查所有 GPO（组策略对象）
• 对于每个数据库服务器：
  • 检查所有服务器角色
  • 检查所有数据库角色
  • 检查所有应用程序角色（在 MSSQL 中）
• 对于每个 Sharepoint 门户：
  • 检查所有服务器级角色和权限
  • 检查所有站点级别和列表级别的角色和权限
• 对于每个第 3 方应用程序：
  • 检查是否使用了 AD 组
  • 验证应用程序如何使用这些角色：
    -> 组名与 DN 与组 SID 与...例如组 GUID
    -> 应用程序是否明确检查直接角色成员资格，还是使用“更智能”的递归方法？
  • 请注意，这既适用于第 3 方打包产品和平台（例如 Oracle、SAP、MQSeries、WebSphere...），也适用于定制开发的业务应用程序。

这是完整的吗？
可悲的是没有。例如，我没有包括审查组织中的所有桌面，因为这些桌面不应该设置特定的 AD 组级别权限（除了管理员和 HelpDesk）——但请注意，他们经常这样做。
但这不是一个完整的列表......

这是使用 DAC 模型的一大缺点——“ D”也可以用于“分布式”，因为没有中心位置可以查找所有这些 ACL。
正如我在 RBAC 和 DAC/ACL 之间有什么区别？：

• DAC 定义通常附加到数据/资源，而 RBAC 通常在两个地方定义：代码/配置/元数据（角色访问）和用户对象（或表 - 每个用户拥有的角色）。

现在，关于解决方案：

• 有几种工具可以收集上述列表的不同部分，例如@Ian 的回答使用 powershell 脚本收集文件夹 ACL。还有许多其他工具（我过去曾使用过 CACLS），其中一些在此处注明。
  要为列表的特定部分请求工具/脚本，您可能会在 ServerFault 获得更好的想法。但是请考虑到它只是列表的一部分。
• 有来自一些大供应商的“角色管理”和“角色发现”产品，通常在身份管理领域 - 我不能特别推荐一个，但值得研究：CA（以前的 Eurekify，它是一个不错的（虽然不完整）工具），IBM，甲骨文。
  当然还有其他的，我会非常倾向于寻找最好的小型供应商，即使是从初创公司（好吧，也许我有偏见；））。我的意思是，从那些没有被更大的供应商收购的人那里。
• 您可以（并且可能应该，尽管这远非微不足道）开始规划组织、业务需求等的过程——瞄准他们应该获得的特权，而不仅仅是现在的现状。上一点中提到的一些工具在这里可以提供帮助。
• 如果之前的角色分析和建模进展顺利，请考虑采用成熟的 IdM/IAM/EAM 解决方案。同样，我对供应商的评论仍然有效。
• 无论如何，目标是尽量减少 ACL 在各地的分布，并推动尽可能集中的 RBAC。

并且，对那些有幸在您当前发现自己的不愉快情况之前出现的最后一个警告：
一定要考虑集中式授权平台，例如 IdM/IAM/EAM 产品。（请注意，有些比其他的要好得多，有些甚至也无法解决这种情况。）

tl; 博士：你是正确和真正搞砸的。往上看。;)
（但所有的希望都没有失去......）

答案取决于您希望如何查看/管理这些数据。我的建议是 PowerShell 来获得所有这些。

如果您确实选择使用 PowerShell，则可以使用本机 AD Cmdlet 或 Quest 的免费 Cmdlet (http://www.quest.com/powershell/activeroles-server.aspx)。要使用本机 Cmdlet，您的域中必须至少有一个 Windows Server 2008 R2 域控制器，或者在 Windows Server 2008 R2 服务器上运行的 AD LDS 配置集中至少有一个实例 - 请参阅http://technet。 microsoft.com/en-us/library/ee617195.aspx了解详情。

实际上，您所要做的就是递归检查特定组访问级别的文件夹 ACL。人们在几个地方（这里和这里）进行尝试，但考虑到这可能是脚本必须导航的大量文件结构，这肯定需要一些时间。对于嵌套组，它变得更加复杂。

编辑：@AviD 对原始命令语法很准确，而且它完全做错了事！编辑为更切题。

这可以通过 Windows 命令提示符完成，如下所示：

• 转到您要保存报告的目录，如果没有选择它应该默认为登录用户的目录。一个例子是cd C:\Users\Administrator\Desktop

• 使用以下命令生成报告：

  gpresult /s servername /user INTERNAL\user1 /h gpreport.html
  

• 上述命令将根据 GPOS 和应用于选择报告的用户的规则生成报告。该用户应该是某个组的成员，或者您可以创建一个测试用户来测试某个组的设置。

• 找到此信息的另一种方法是编辑 GPO，在 Windows 2008 上，您应该可以选择查看所有设置并按状态对其进行排序，然后您可以记录 GPO 的所有启用设置。

对于您提供的示例，IMO 最快的 DIY 方式是：

1. 查看您知道已在Internet 限制组中的现有用户帐户，并检查他们是哪些组的成员。
2. 创建一个测试帐户。
3. 将此测试帐户设为步骤 1 中找到的同一组之一的成员。
4. 在另一台 PC 上，登录测试帐户并检查Internet 限制组是否已启动。
5. 继续一次添加一个组，直到找到Internet 限制组。

请注意，每次添加组时都需要注销/登录。此外，根据组织的规模，您可能需要稍等片刻才能在服务器集群中传播权限，然后才能测试成功添加的每个组。要了解这可能需要多长时间，请创建您自己的安全组来执行诸如阻止启动 MS Word 或创建 PST 之类的操作，并查看在测试帐户上实施安全组需要多长时间。