【问题标题】:Translate Group ID Principal SID to readable name将组 ID 主体 SID 转换为可读名称
【发布时间】:2017-02-23 22:42:40
【问题描述】:

ID 以“S-1-5-21”开头我想简单地翻译整个 ID,以便更好地了解真正的组名是什么。 这也只发生在安全组中。

我试过了:

$Name = "S-1-5-21-2068335789-*********-1256946392-1001"(New-Object System.Security.Principal.SecurityIdentifier($Name)).Translate([System.Security.Principal.NTAccount]).value`

但它会产生错误:

“使用“1”个参数调用“翻译”的异常:“无法翻译部分或全部身份引用。”

此 id 来自安全组或用户名下的共享文件夹:

【问题讨论】:

  • 这可能意味着您的 ActiveDirectory 不一致,需要清理并使其保持一致。通常,您使用的技术足以获取 SG/用户/计算机的帐户名,但是当我们在企业中看到相同的东西时,这意味着某些内容被删除了,可能是不正确的,并且 SID 赢了't resolve(否则它会被解析并且你会看到组名而不是 SID)。
  • 所以我无法通过运行命令来跟踪 SID 并在不需要时通过删除这些 SID 来清理 AD?如何确定这些安全组可能被删除并转换为 SID?

标签: powershell powershell-2.0


【解决方案1】:

您看到的是一个“孤立的 SID”,很可能来自已从 AD 中删除的用户帐户。

文件夹 ACL(权限)不会与用户帐户一起删除。权限仍然包含该帐户的条目,该条目显示为其 SID,因为它无法像其他对象一样解析为人类可读的名称

有一个名为SetACL 的漂亮工具可以为您查找和删除这些条目。

【讨论】:

  • 如果我从共享文件夹安全组中删除孤立的 SID,如我上传的图片所示,它会影响 AD 中的任何内容吗?另外,我们如何确定这个孤立的 SID 肯定是禁用/删除的用户帐户而不是安全组??
  • “我们如何确定这个孤立的 SID 肯定是禁用/删除的用户帐户而不是安全组” - 这没关系。目录中不再存在安全主体。这就是访问控制列表查看器显示 SID 而不是安全主体名称的原因。
  • 正如比尔所说,没有必要检查...除非您的 AD 环境处于严重不良状态并且无法解析 SID,但是您需要担心的不仅仅是文件/文件夹权限!
  • 好的,谢谢大家!我试图更好地理解。因此,当组名/用户名转换为 SID 时,这绝对意味着该帐户已被删除。因此,如果我从安全列表中删除该 SID,则有权访问该文件夹的人会失去他们拥有的权限。我的总体目标是从这些共享文件夹中清除这些 SID 并建立适当的安全组。前任。 RW(读,写) RO(只读)。
  • 所有权限都保存为底层 NTFS 文件系统上的 SID,Windows 查找并显示对象名称(用户/组/计算机),因为我们人类更喜欢名称而不是一长串数字,例如西德。只有当对象不存在时无法解析对象名称时,它才会显示 SID。所以.. 如果您在其他正确显示的对象旁边看到一个 SID,则该 SID 可能什么都不做。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-08-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-11-29
  • 2017-06-17
相关资源
最近更新 更多