我遇到过这种情况，一个用户曾经有权访问某个目录，但现在该用户已被删除。事实上，他们的帐户已从 AD 中完全删除。
通常，当发现某个用户已被删除，但在目录上定义了明确的 ACL 时，则会留下一个 SID，注明 ACL 在那里，并且不再引用所有其他 AD 属性，如名称等。本质上是一个孤立的 ACL 条目，我假设它是设计用来在需要取消删除用户时留在那里的。
然而，我遇到了一些不同的事情，如果我查看目录属性/安全选项卡，则不存在相关用户或该用户的 SID。
但是，如果我检查 CMDLET Get-ACL 返回的对象的访问属性，我会得到不同的结果。
如果我执行命令在文件服务器，我实际上获得了具有明确权限的 DOMAIN\username
如果我在另一个服务器（如域控制器）的同一目录上运行完全相同的命令，我会得到相同的列表，但在除本地之外的所有其他实例中，用户都显示为 SID。因此，我不得不假设文件服务器只是将他的 SID 缓存在某个地方，这解释了那方差，但它没有考虑到安全选项卡不显示相同权限条目的事实。
更糟糕的是，如果我深入多个级别，并使用 powershell 检查该目录的子对象，我会看到相同的结果，此权限已定义，但仅在 powershell 中，Windows 仍然不显示任何内容。
因此我寻求了第三种意见并使用了 sysinternals 的 accessenum，它没有显示无关的 ACL，但 CALCS 却显示！所以现在我们又回到了 1-1 的有/无设置比例，没有证据支持任何一种的有效性。
该目录直接位于驱动器的根目录下，没有方法 powershell、CACLS 等显示在驱动器本身上定义的权限，我也没有任何理由怀疑它在过去会存在。
如果不了解这里发生了什么，我犹豫是否要尝试使用 powershell 或 CACLS 删除 ACL。同样，典型的强制所有权/继承沿着目录树向下，删除所有权限并重新定义将是一项艰巨的任务，因为此目录下有一个大型文件结构，其 ACL 在许多地方分叉。
为了确保我没有处理磁盘损坏或无效数据，我对有问题的驱动器执行了 CHKDSK，没有报告任何错误。
我认为这要么是一个错误，要么是某个地方损坏了，但不知道该从哪里进一步查找，也许是磁盘本身上的十六进制编辑器？
所以我是否发现了一些错误、失误，或者只是忽略了一些显而易见的东西？