这是对文件服务器权限的推荐/有效方法吗？

文件服务器是IT部门不可或缺的事实，我很好奇是否存在关于如何创建组并应用权限来管理对共享文件夹的客户端访问的权限的通用做法（我不愿意在这里使用“最佳”一词）。文件服务器。

在我目前的工作中，我最终继承了许多不同的方式来做到这一点，从ACL上的数十个组到仅将单个用户直接放在文件系统上。我的任务是清理混乱并提出某种标准化的方法来解决整个公司的问题（大型环境，15万员工，9万客户端计算机，100多个文件服务器）。

根据我对问题的了解，似乎每个安全资源的每个所需访问级别至少需要一个组。该模型似乎提供了最大的灵活性，因为您无需再次触摸文件系统权限，除非您需要支持其他访问级别。缺点是，与在多个共享资源中重复使用同一组相比，您将创建更多的组。

这是显示我的意思的示例：

在名为FILE01的文件服务器上有一个名为“测试结果”的共享，并且您需要只读访问，读写访问和完全控制权。1个安全资源* 3个访问级别= 3个安全组。在我们的AD环境中，我们将它们创建为通用组，以便我们可以轻松地添加林中任何域中的用户/组。由于每个组唯一地引用一个共享文件夹和访问级别，因此组名合并了那些“关键”数据，因此权限为：

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

通常，我们还将包括具有“完全控制”访问权限的内置SYSTEM帐户和内置Administrators。现在，可以使用组成员身份来处理对实际有权访问此共享的人员的任何更改，而不必触摸ACL（通过添加代表特定业务角色（例如经理，技术人员，质量检查分析师等）的“角色”组，或者仅添加个人用户一次访问）。

两个问题：

1）这实际上是处理权限的推荐或有效方法，还是我缺少一些更简单，更优雅的解决方案？对于使用继承但仍然保留灵活性的任何解决方案，我都将特别感兴趣，因为在情况发生变化时不必重新对文件系统的大部分进行ACL。

2）您如何在环境中处理文件服务器权限和组结构？对于在大型环境中工作的人也有奖励积分。

我的方法是不使用文件/目录级别的文件权限。使用文件共享级别权限，并将整个服务器文件系统数据驱动器设置为“所有人完全控制”（将变得毫无意义）。

多年来（10多年来），我发现NTFS权限更加复杂，并导致更多错误。如果权限设置错误或继承被破坏，则您将公开数据，并且很难找到和看到它。另外，您还遇到了移动/复制问题...移动文件的用户也会移动文件的ACL，而复制会继承目标ACL。

使用相同的读/写组，但是使用Comp Mgmt MMC在整个文件共享上使用。不要做的全部……用户会以部分知识/最佳意图来开枪。

这种方法还不错。通常，切勿使用单个用户添加权限-使用组。但是，可以跨资源使用组。例如，HR可能具有对文件的RW访问权限，而MANAGERS可能具有R。您还可以设置基于访问的枚举。请看以下网络广播：

TechNet网络广播：Windows Server 2003管理系列（第12部分，共4部分）：组管理（级别200）

基于访问的枚举可以使生活更轻松，请参见：

基于访问的枚举

ABE可以帮助减少您必须管理的不同共享的数量。

您的方法基本上就是我所采用的方法。
我唯一要添加的是这些：

1）我将通过评估跨服务器的需求来增加您的“角色”方案，而不只是在一台服务器上，您可能会对此产生异常，但是我的理论是当您遇到它们时，创建另一组。根据我的经验，离群值很多。

2）当您将通用组中的成员和组复制到全局编录服务器时，我强烈建议重新评估通用组的所有需求，而将本地组和全局域中的唯一组复制到全局编录服务器中复制到全局编录服务器。因此，如果在通用组中进行更改，它将启动复制，而对于全局和域本地则不会。

您为每个访问级别使用资源组的方法是正确的。我唯一要考虑的是使用域本地组作为资源。如果要创建服务器特定的资源组，则不必使用通用组。

使用“域本地组”获取资源的不利之处在于最终会产生更多的组。正如Zypher所指出的那样，好处是复制方面的问题更少。

提议的方法似乎很可靠。需要注意的一件事是您最初设置文件共享的方式。推荐的做法是拥有一个单个的顶级共享，其中包含子文件夹，然后您可以向其分配组权限。然后，NTFS可以绕过顶级文件夹上的“遍历文件夹/执行文件”，并授予对该子文件夹的访问权限。

然后，该结构将类似于\ servername \ sharename \ group-folder，只需在“ sharename”文件夹中设置共享权限，并在“ group-folder”文件夹中设置实际的NTFS权限。

使用这种设置，您的文件服务器也将能够更好地执行。

我要做的一般其他事情是为组指定命名约定，以使组名称与组文件夹名称相同（如果需要，可以附加FC / RW / RO），然后将UNC粘贴到该文件夹​​中，并放入组描述中（以便您的登录脚本可以将其读回并以这种方式设置驱动器映射，还可以使您更轻松地查看哪些共享文件夹应用于哪些组）。

自Windows 2000以来，我一直在使用Windows文件服务器的标准做法（在Mark Minasi的Mastering Windows Server系列中进行了布局，因此请查看此处以获取更多信息）是使用文件服务器本身本地的组进行嵌套。

例如，考虑在名为MUPPETS的域中名为KERMIT的文件服务器。

说KERMIT有一些文件共享：

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

在KERMIT中创建本地访问组，并完全按照您指定的权限授予他们对文件系统的权限（即，每个访问级别每个共享一个组）

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

由于这些是本地组，因此您可以将所需的任何其他组或用户放在其中-域本地组，全局组，通用组，林中任何域中的用户帐户。权限管理现在位于文件服务器的组本地，而不是文件系统或AD。

这确实为您的网上论坛管理增加了一层，但是它的好处是允许（例如）站点本地管理员管理自己的文件服务器，而无需对该文件服务器拥有管理员权限。如果您有一个联邦分支机构结构，其中每个办公室都使用其服务器来做自己的事情，那么这将是真正的好处。您可能不需要将AD管理员权限授予几十个本地站点管理员。

这也可以防止您的AD杂乱无章（每个服务器每个共享访问级别一个组可以非常快地累加起来），并最大程度地减少GC之间的组复制。它允许您为角色而不是权限保留AD组。

如果您的环境经过严格的标准化，并且所有文件服务器都相同且已复制，那么显然这是您不需要的另一层组。另外，如果您知道需要特定的AD组对每个文件服务器上存在的共享具有相同的权限，则将需要一些自动化来维护该权限。

简而言之，文件服务器彼此之间的差异越多，使用计算机本地组越有意义。它们越相似，您就越想使用当前使用的系统。

我正在寻找从NetWare到Windows Server 2008的迁移，因此最近我一直在想这件事。Server 2008（在某种程度上是Server 2003R2）具有一些非常好的功能，可以真正简化此过渡。Server 2008开箱即用。这是一个非常好的功能，它允许用户仅查看他们有权访问的目录。如果您有类似...

\\ user-home-srv \ homes \

如果没有ABE，最终用户将看到数以万计的目录。使用ABE，最终用户将只能看到一个。共享股份也是如此。使用ABE，您可以根据需要为所有部门目录提供一个庞大的卷，而不会向用户发送他们无法进入的目录的垃圾邮件。虽然不是ACL问题，但它有些相关，因此我提出了。

Server 2008似乎比其早期版本做得更好的另一件事是ACL继承。在大树顶部传播ACL更改到叶子的速度似乎更快。

由于我们的Netware遗留问题，我们有大量的组是根据其中的人来命名的，其中一些是根据他们可以访问的内容来命名的。对于有访问权限的目录，我们也使用“ RO”“ Full”命名法。

我们有一个整体的“共享”卷（仍在NetWare上，但是我们计划在移动到Windows时使其整体），它是所有4,400个工作人员的单个共享卷，上面有350万个文件。顶级目录都是部门名称，每个部门都对其中的内容进行管理。对于大型部门，有一些例外，它们具有带有ACL的第二级目录。

在我的上一份工作中，我们甚至还可以设置权限，因此申请工作的HR员工将无法在服务器上看到自己的应用程序数据。它需要一些继承权限过滤器来完成，这类似于Windows上的“阻止继承”标记。那里最棘手的部分是全部记录在案，但它确实起作用。

最好的情况是将每个用户添加到该用户的工作角色的一个安全组中。然后，在需要时向角色委派访问。

同样，应该使用“资源”安全组授予共享文件夹访问权限，例如“ FILE01-Test Results-RW”示例。这将包含工作角色，部门角色或其他适用的组。

这种设计的好处是，您可以按组（团队，部门等）委派访问权限，而不是难以跟踪的一次性访问权限。当用户转移到另一个部门时，您需要清理所有旧的访问权限。

不利的一面是群体可能被滥用。明确区分组的用途，以便分配给共享的资源组不会像部门组那样重复使用，从而造成混乱的访问混乱。