我应该在 Active Directory 中的哪里存储敏感数据?

我应该在 Active Directory 中的哪里存储敏感数据?

我本质上是将私钥(哈希)存储在 Active Directory 中的任何 OctetString 属性中。

我的问题是,哪个属性默认是安全的,并且适合将私人数据保存在那里?该值应被视为类似于密码,即使管理员也不应该有访问权限(如果可能),就像当前的 AD 密码一样。

以下是 Windows 2008R2 + Exchange 2010 域上默认启用的属性列表的开头。

替代文本

更新:

有谁知道默认情况下不会向域中的所有用户公开“读取”权限的八位字节字符串属性?我不想公开存储我的哈希值并允许某人根据哈希值构建彩虹表。

答案1

大多数人在 AD 中存储数据时面临的问题是

  • 扩展架构(通常具有公司政治影响)

  • 使用现有属性并编辑权限(这会导致 AD/ACL 膨胀,从而增加 DIT 和后续复制的大小)

还有另一种选择……我认为最好的选择是使用 AD 的这个鲜为人知的功能来获取现有属性并将其标记为机密。

以下是该过程的详细信息


Active Directory 中的默认权限是经过身份验证的用户对所有属性拥有全面的读取权限。这使得引入应受保护以防止任何人读取的新属性变得困难。

为了缓解这种情况,Windows 2003 SP1 引入了一种将属性标记为机密的方法。此功能通过修改架构中属性的 searchFlags 值来实现。SearchFlags 包含多个位,代表属性的各种特性。例如,位 1 表示该属性已编入索引。新的位 128(第 7 位)将属性指定为机密。

注意:您不能在基本架构属性(从“top”派生的属性,例如 common-name)上设置此标志。您可以使用 LDP 查看对象并检查对象的 systemFlags 属性来确定对象是否为基本架构对象。如果设置了第 10 位,则它为基本架构对象。

当目录服务执行读取访问检查时,它会检查机密属性。如果有,则除了 READ_PROPERTY 访问权限外,目录服务还将要求对属性或其属性集具有 CONTROL_ACCESS 访问权限。

默认情况下,只有管理员才具有对所有对象的 CONTROL_ACCESS 访问权限。因此,只有管理员才能读取机密属性。用户可以自由地将此权限委托给他们想要的任何特定组。这可以使用 DSACL 工具、脚本或 R2 ADAM 版本的 LDP 来完成。截至撰写本文时,无法使用 ACL UI 编辑器来分配这些权限。

将属性标记为机密并添加需要查看该属性的用户的过程分为 3 个步骤

  1. 确定将哪个属性标记为机密,或者添加一个属性来标记为机密。

  2. 标记为机密

  3. 授予正确的用户 Control_Access 权限,以便他们可以查看属性。

有关更多详细信息和分步说明,请参阅以下文章:

922836 如何在 Windows Server 2003 Service Pack 1 中将属性标记为机密

http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836

答案2

为了达到此目的,您可以随时用新字段扩展 Active Directory。

这里有一个文档其中包括有关添加新属性和限制该属性权限的说明。

答案3

这个值应该被认为类似于密码,即使管理员也不应该有访问权限(如果可能的话),就像当前的 AD 密码一样。

这不正确,甚至不算错误。密码没有被存储。哈希被存储,域管理员可以访问它。事实上,如果您愿意,您甚至可以配置 AD 以可逆加密方式存储密码。

在 AD 中,没有什么可以阻止域管理员。如果您删除权限甚至拒绝,域管理员可以取得所有权并将自己重新添加。这与 Novell 的 NDS 形成对比,在 Novell 的 NDS 中,OU 的管理员可以不可撤销地锁定更高级别的管理员。

您能做的最好的事情就是使用现有或新的属性,并限制访问权限。您可以阻止管理员访问,并且可以对属性启用审核,以便记录任何访问或权限更改。

相关内容