据我了解，最佳实践建议将安全组与 Windows 域一起使用来分配文件和文件夹的权限。也就是说，您应该在 Active Directory 中创建组，在其中填充用户，然后通过组而不是单个用户为文件夹和文件分配权限。我可以看到这种方法的好处，但是：
在我的组织中，我们使用企业信息系统进行日常运营。每个项目和部门都记录在系统中，系统知道每个部门和项目的所属人员。我们正在实施文件夹同步机制，通过该机制，系统可以将权限应用于文件服务器中的共享文件夹，以复制我们的组织结构。例如，如果我们有一个“销售”部门，成员有 Alice 和 Bob，系统将创建一个共享文件夹“销售”，并向 Alice 和 Bob 授予该文件夹的权限。这很有效，并且实际上消除了手动为文件夹和用户分配权限的需要。
问题是，我们不确定 Active Directory 组在这种情况下是否仍然有意义。原则上，我们假设将为每个部门和项目创建一个或多个 AD 组，并像往常一样为其分配权限。例如，将有 Dept-Sales-Head 和 Dept-Sales-Members 组，每个组都有自己的成员，用于销售部门的负责人和成员，并通过这些组分配权限。我们的自动化系统能够创建和管理 AD 组。但我们担心，随着公司组织实体数量的增长，我们最终会拥有太多的组。我似乎记得，不建议每个域拥有超过 5000 个组，而且我们很可能在几年内接近这个数字，所以这种方法不可扩展。
我们正在考虑的另一个选择是放弃安全组，让自动化系统使用单个用户帐户为文件夹分配权限。这将消除上述问题，但我们担心这种无组安全方法可能会产生我们现在无法预料的不良后果。
所以我的问题是：这种无组文件系统权限分配方法是否有意义？从长远来看，您是否预见到任何不良后果？
答案1
这种无组文件系统权限分配方法有意义吗？
在设计环境时，最佳实践是出发点，出于各种业务或技术原因，可以偏离此点。如果用户可能需要访问接近 1,000 个项目 - 这可能符合技术原因。
鉴于目前Active Directory 最大值（总对象超过 20 亿个；用户组成员最多约为 1000 人，组成员最多为 5000 人），我认为“我们担心最终会出现太多组”不是一个有效的技术原因。
但是，如果企业有另一个应用程序可以根据用户在组织中的角色更新对文件和资源的访问权限（这本质上是嵌套 AD 安全组试图实现的），这听起来像是跳过这一特定最佳实践的正当理由——或者至少指出它是通过其他方式实现的。这并不是说你在讨论在 Active Directory 中完全删除组，只是讨论用于控制对文件共享的访问的组。
诚然，如果您无论如何都要管理 Active Directory 中类似组成的组（GPO 的安全筛选、组策略首选项的项目级定位、服务器/工作站上的用户权限分配、对 Active Directory 中对象/分支的委派访问、对其他应用程序或资源的 AD 或 LDAP 身份验证访问），那么仅仅为了这一点而放弃组可能没有多大意义。但是，如果我正确阅读了您的问题，对组织中资源的一般访问与对这些基于“每个项目”的文件共享的受控访问不同。我说得对吗？
此外，当审查现在分配文件共享的访问权限时，我总是建议查看动态访问控制。
从长远来看，您是否预见到任何不良后果？
如果应用程序没有清理陈旧账户的条目，则 SACL 会变得没有必要那么长。
当没有实际数据发生变化时，需要进行不必要的复制以及更大或更长的备份，因为文件夹/文件上的 ACL 变化的频率比简单静态 ACL 所需的频率要高。
答案2
首先，自动化是件好事。你们尝试将这些繁琐的事情自动化管理，这很好。但是，我发现尝试直接向用户分配文件权限存在两个潜在问题。
文件系统性能影响。假设您有一个共享，其中包含数千或数十万个文件，并且您需要添加或删除员工对该共享的访问权限。即使共享权限中的所有内容都是从根文件夹继承的，操作系统仍然需要修改每个文件的 ACL 以更新这些权限。对于巨大的共享，这既需要很长时间，又会在处理时降低文件服务器的性能。将权限应用于组后，不会产生任何影响，因为 ACL 中实际上没有任何变化。
大型 ACL 的性能问题。诚然，我不知道这种情况的症状是什么。但我不得不相信，如果 ACL 包含数百个或更多单独的用户条目，将会产生负面影响。我猜你会看到客户端的延迟更长，因为服务器必须做更多的工作来处理 ACL。你还可能会看到服务器本身的负载更高，需要更强大的硬件来完成相同的任务。