我有一个Windows Server 2003框充当文件服务器。 它承载了许多共享文件夹与不同的权限。 2003盒子不是域控制器/ Active Directory主机; Active Directory运行在我们控制之外的服务器上，但我们相信它是Server 2008 R2。
我发现通过远程桌面协议（RDP）保持login到Windows Server 2003框会导致Windows资源pipe理器中的安全权限变得过时，就像服务器正在caching之前的权限一样。
重现步骤：
转到在Windows资源pipe理器中托pipe共享驱动器的磁盘，例如Z：
select共享的文件夹，右键单击并转到“属性”，然后单击“安全”选项卡。
观察那里的权限。
注销您的RDP会话，然后重新连接。
重复步骤2 – 3。
请注意，权限不匹配。
我100％确定没有其他用户或pipe理员正在修改权限。 共享文件夹的权限仅由login到此框的一位pipe理员修改。 在Windows资源pipe理器中按“F5”（刷新）不刷新权限。 这会使pipe理员相信文件夹上的权限不同于客户端看到的实际有效权限。
最让人困惑的是连接到共享文件夹的客户端（最终用户）可以看到实际的权限。 例如，如果用户实际上被拒绝访问文件夹，则授予其访问权限的caching权限可能会显示在服务器上，但客户端将无法访问该文件夹。 但是，权限更改将不会显示在服务器上，直到pipe理员注销，然后重新login。
有没有办法迫使系统自动更新权限，而不是caching它们，或手动这样做？ 这是一个服务包解决的错误，还是这是一个“devise”function？
在用户被“caching”并且似乎被添加到文件夹的自定义权限列表的情况下，行为是最奇怪的：您可以更改用户的权限，例如从完全控制到拒绝所有权限并返回，没有操作系统报告的错误。 但是，进行这些更改并单击“应用”将不会对客户端产生可见的影响 ，并且在注销后重新login到服务器时，用户将不会出现在具有自定义权限的用户列表中！
嗯。 假设像Zoredache指出的那样，您正在讨论NTFS文件系统DAC列表，那么问题几乎肯定不会与您的域控制器有关。
在文件系统上设置权限时，服务器使用您授予权限的安全主体的SID来标记文件系统对象。 如果您正在使用本地用户帐户/本地组，则SID将是服务器专用的一个。 但是，在域模型中，可能引用了域全局或域本地组，在这种情况下，基于域的安全主体的SID将被标记到文件系统对象上。
另外，最佳做法仍然规定您应该在文件系统上使用本地组，并在本地组中使用域全局/域本地组。 这从理论上减less了服务器到DC / GC SID的查找。
一旦SID标签被应用，即使DC / GC离线或不可达，它仍然会持续; 你只会被提出一个未解决的SID。
所以，build议：
我（我们？）等待更多信息…