文件服务器是IT生活中的事实，我很好奇，如果有任何普遍接受的做法（我不愿意在这里使用“最好”一词）如何创build组和申请权限来pipe理客户端访问共享文件夹一个文件服务器。
在我目前的工作中，我最终inheritance了很多不同的方式，从ACL上的几十个组到将各个用户直接放在文件系统上。 我的任务是清理混乱，并在整个公司（大型环境，15万人员，90万台客户端计算机，100多台文件服务器）中提出某种标准化的方法。
从我对这个问题的理解来看，您至less需要每个安全资源所需访问级别为一个组。 这种模式似乎给了最大的灵活性，除非需要支持不同的访问级别，否则不需要再次访问文件系统权限。 缺点是您将创build更多的组，而不是跨多个共享资源重复使用相同的组。
这里是一个例子，显示我的意思：
在名为FILE01的文件服务器上有一个称为“testing结果”的共享，您需要只读访问，读写访问和完全控制的人员。 1个安全资源* 3个访问级别= 3个安全组。 在我们的AD环境中，我们将它们创build为通用组，以便我们可以轻松地添加林中任何域的用户/组。 由于每个组唯一地指向共享文件夹和访问级别，因此组名称包含这些“关键”数据片段，因此权限为：
"FILE01-Test Results-FC" -- Full Control "FILE01-Test Results-RW" -- Read & Write "FILE01-Test Results-RO" -- Read Only 通常，我们还将包含内置的SYSTEM帐户和内置的具有完全控制权限的pipe理员。 现在可以使用组成员身份来处理谁实际获得访问此共享的任何更改，而不必访问ACL（通过添加代表特定业务angular色（如经理，技术人员，质量保证分析师等）的“angular色”用户一次性访问）。
两个问题：
1）这实际上是一个处理权限的build议或有效的方法，或者我错过了一些更简单，更优雅的解决scheme？ 我会特别感兴趣的是使用inheritance的任何解决scheme，但仍然保持灵活性，在事情发生变化时不必重新ACL大部分文件系统。
2）你如何处理你的环境中的文件服务器权限和组结构？ 对于那些也在大型环境中工作的人员的奖励积分。
我的做法是不使用文件/目录级文件的权限; 使用文件共享级别权限，并将整个服务器文件系统数据驱动器设置为“每个人完全控制”（这将成为模拟）。
多年来（10+），我发现NTFS权限更复杂，导致更多的错误。 如果权限设置错误，或者inheritance被破坏，那么您将暴露数据，并且很难find并查看它。 此外，您将面临移动/复制问题…用户移动文件也移动文件的ACL，而副本inheritance目标ACL。
使用您的读/写组相同，但在整个文件共享使用Comp Mgmt MMC。 不要做全面的…用户将用部分知识/最好的意图自己开枪。
这个方法不错。 作为一个规则，不要使用个人用户添加权限 – 使用一个组。 但是，组可以跨资源使用。 例如，人力资源部门可能拥有对文件的RW访问权限，而pipe理员可能拥有R权限。您还可以设置基于访问的枚举。 看看下面的networking广播：
TechNetnetworking广播：Windows Server 2003pipe理系列（第4部分，共12部分）：组pipe理（级别200）
基于访问的枚举可以使生活更容易看到：
基于访问的枚举
ABE可以帮助减less您必须pipe理的不同份额的数量。
你的方法基本上是我的方式。
我会添加的唯一的东西是这些：
1）我会添加到你的“angular色”计划，通过评估他们需要跨服务器，而不是在一台服务器上，你可能会遇到exception，但我的理论是当你遇到他们，创build另一个组。 根据我的经验，有一个exception值有很多。
2）当通用组中的成员和组被复制到全局编录服务器时，我将强烈地重新评估通用组的所有需求，因为通用组中的成员和组将被复制到全局编录服务器，而只有组本身复制到全局编录服务器。 所以，如果你在一个通用组中进行了改变，它将开始复制，而在全局和域本地则不能。
您为每个访问级别使用资源组的方法是正确的。 我只考虑使用域本地组的资源。 如果要创build特定于服务器的资源组，则不一定需要使用通用组。
使用“域本地组”来获取资源的缺点是，最终会得到更多的总体组。 Zypher指出，好处在于复制的问题较less。
所提出的方法似乎相当稳固。 有一件事要注意，就是你最初设置文件共享的方式。 build议的做法是拥有一个顶级共享，其中包含您然后将组权限分配给的子文件夹。 然后，NTFS可以绕过顶层文件夹上的“遍历文件夹/执行文件”，并授予访问子文件夹的权限。
然后，该结构将看起来像\ servername \ sharename \ group-folder，只需在“sharename”文件夹中设置共享权限，然后在“group-folder”文件夹中设置实际的NTFS权限。
您的文件服务器也可以使用这种设置更好地执行。
一般情况下，我会做的其他事情是有一个命名约定的组，使组名称是相同的组文件夹名称（FC / RW / RO如果需要附加），并将UNC到该文件夹粘贴到组描述（这样您的login脚本就可以读取它并设置驱动器映射，也可以更容易地看到共享文件夹适用于哪些组）。
自Windows 2000以来，我一直使用Windows文件服务器的标准做法（在Mark Minasi的Mastering Windows Server系列中进行了介绍，所以请查看更多信息）是使用本地文件服务器本身的组进行嵌套。
例如，考虑名为MUPPETS的域中名为KERMIT的文件服务器。
说KERMIT有几个文件共享：
\\KERMIT\Applications \\KERMIT\Finance \\KERMIT\Sales \\KERMIT\Manufacturing
创buildKERMIT本地组访问权限，并按照您指定的方式为其授予文件系统权限（即每个访问级别每个组一个组）
KERMIT\Applications-RO KERMIT\Applications-RW KERMIT\Applications-FC KERMIT\Finance-RO [...]
因为这些是本地组，所以您可以将任何其他组或用户放入其中 – 域本地组，全局组，通用组，来自林中任何域的用户帐户。 权限pipe理现在是文件服务器组的本地，而不是文件系统或AD。
这确实为您的组pipe理添加了一个额外的层，但是它具有允许（比方说）站点本地pipe理员pipe理他们自己的文件服务器的好处，而不需要任何超过该文件服务器的pipe理权限。 如果你有一个联合式的分支机构结构，每个办公室都有自己的服务器，这可能是一个真正的好处。 您可能不希望将ADpipe理员权限授予几十个本地站点pipe理员。
它还可以让您的AD避免与许多组混淆（每个服务器每个访问级别每个访问级别的一个组可以快速加起来），并最小化GC之间的组复制。 它允许您为angular色而不是权限保留您的AD组。
如果你的环境是严格标准化的，所有的文件服务器都是相同的，那么这显然是你不需要的一个组。 另外，如果你知道你需要一个特定的AD组来在每个文件服务器上存在的共享上拥有相同的权限，那么你将需要一些自动化来维护这个。
简而言之，您的文件服务器彼此之间的差异越大，使用本地机器组越有意义。 他们越相似，你越想使用你正在使用的系统。
我正在研究从NetWare到Windows Server 2008的迁移，所以近来我一直在思考这个问题。 Server 2008（以及某种程度上Server 2003R2）有一些非常好的function，真正简化了这个过渡。 Server 2008自带基于访问的枚举。 这是一个非常好的function，允许用户只能看到他们有权访问的目录。 如果你有一个像…
\\用户家-SRV \家庭\
如果没有ABE，最终用户将会看到数十/数百/数千个目录。 使用ABE，最终用户只能看到一个。 共享股份也是如此。 使用ABE，如果您愿意，您可以为所有部门目录创build一个巨大的卷，而不会将用户无法访问的目录中的垃圾邮件发送给用户。 虽然不是ACL问题，但它有点相关，所以我把它提出来。
Server 2008似乎比早期版本更好的另一件事是ACLinheritance。 在传播到树的顶部的一个ACL变化的叶子似乎更快。
由于我们的Netware遗留下来，我们有大量的组是以他们的名字命名的，有几个组是以他们提供的访问权限命名的。 对于有访问权限的目录，我们也使用“RO”“Full”命名法。
我们有一个单一的“共享”卷（仍然在NetWare上，但是我们打算把它移植到Windows上时是单片的），它是所有4,400名工作者的单一共享卷，并且上面有超过350万个文件。 顶级目录是所有部门名称，每个部门都pipe理其内部的内容。 对于真正的大型部门来说有一些例外，那就是具有ACL的第二级目录。
在我上一份工作中，我们甚至可以设置权限，因此申请职位的HR员工将无法在其服务器上看到自己的应用程序数据。 它采取了一些inheritance权利filter来做到这一点，它类似于Windows上的“块inheritance”标签。 那里棘手的部分是logging这一切，但它的工作 。
最好的情况是每个用户只需添加一个用户angular色的安全组。 那么angular色就是在需要时委派访问。
同样，应该使用“资源”安全组授予共享文件夹的访问权限，例如“FILE01-Test Results-RW”示例。 这将包含工作angular色，部门angular色或其他适用的组。
这种devise的优势在于，您可以按组（团队，部门等）授予访问权限，而不是一次性访问，难以跟踪。 当用户转移到另一个部门时，您需要清理所有旧访问。
缺点是团体可能被滥用。 明确区分这些小组是如何使用的，以便分配给一个份额的资源组不被重复使用，就好像它们是部门小组一样，造成了混乱的访问。