存储私有“八位字节串”在活动目录中；默认情况下什么是安全的？
我本质上是在 Active Directory 中的任何 OctetString 属性中存储私钥（哈希）。
我的问题是，默认情况下什么属性是安全的并且可以将私有数据保留在那里？该值应被视为类似于密码，即使是管理员也不应具有访问权限（如果可能），就像当前的 AD 密码一样。
以下是 Windows 2008R2 + Exchange 2010 域上默认启用的属性列表的开头。
更新：
有谁知道不公开“read”的八位字节字符串属性默认情况下域中所有用户的权限？我不想公开存储我的哈希值并允许某人基于哈希值构建彩虹表。
I am essentially storing a private key (Hash) in any of the OctetString attributes within Active Directory.
My question is, what attribute is secure by default and makes sense to keep private data there? This value should be considered similar to a password, where even administrators shouldn't have access (if possible), just like the current AD Password.
Here is a start of a list of attributes that are enabled by default on a Windows 2008R2 + Exchange 2010 domain.
Update:
Does anyone know of an Octet String attribute that does not expose "read" permissions to all users in the domain by default? I don't want to store my hash publicly and allow someone to build a rainbow table based on the hashes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是对我的问题投赞成票的人的答案...这非常有趣：
Active Directory 中的默认权限是经过身份验证的用户对所有属性具有全面的读取访问权限。这使得引入应保护不被所有人读取的新属性变得困难。
为了缓解这种情况，Windows 2003 SP1 引入了一种将属性标记为机密的方法。此功能通过修改架构中属性的 searchFlags 值来实现。 SearchFlags 包含表示属性的各种特性的多个位。例如，位 1 表示该属性已被索引。新的第 128 位（第 7 位）将该属性指定为机密。
注意：您不能在基本架构属性（从“顶部”派生的属性，例如通用名称）上设置此标志。您可以通过使用LDP查看对象并检查对象的systemFlags属性来确定对象是否为基础架构对象。如果设置了第 10 位，则它是基本模式对象。
当目录服务执行读取访问检查时，它会检查机密属性。如果存在，那么除了 READ_PROPERTY 访问之外，目录服务还需要对属性或其属性集进行 CONTROL_ACCESS 访问。
默认情况下，只有管理员拥有对所有对象的 CONTROL_ACCESS 访问权限。因此，只有管理员才能读取机密属性。用户可以自由地将这一权利委托给他们想要的任何特定组。这可以使用 DSACL 工具、脚本或 LDP 的 R2 ADAM 版本来完成。截至撰写本文时，尚无法使用 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
Here is the answer for the fella who upvoted my question... it's pretty interesting:
The default permissions in Active Directory are such that Authenticated Users have blanket read access to all attributes. This makes it difficult to introduce a new attribute that should be protected from being read by everyone.
To mitigate this, Windows 2003 SP1 introduces a way to mark an attribute as CONFIDENTIAL. This feature achieved by modifying the searchFlags value on the attribute in the schema. SearchFlags contains multiple bits representing various properties of an attribute. E.g. bit 1 means that the attribute is indexed. The new bit 128 (7th bit) designates the attribute as confidential.
Note: you cannot set this flag on base-schema attributes (those derived from "top" such as common-name). You can determine if an object is a base schema object by using LDP to view the object and checking the systemFlags attribute of the object. If is the 10th bit is set it is a base schema object.
When the Directory Service performs a read access check, it checks for confidential attributes. If there are, then in addition to READ_PROPERTY access, the Directory Service will also require CONTROL_ACCESS access on the attribute or its property set.
By default, only Administrators have CONTROL_ACCESS access to all objects. Thus, only Administrators will be able to read confidential attributes. Users are free to delegate this right to any specific group they want. This can be done with DSACLs tool, scripting, or the R2 ADAM version of LDP. As of this writing is not possible to use ACL UI Editor to assign these permissions.
The process of marking an attribute Confidential and adding the users that need to view the attribute has 3 Steps
1.Determining what attribute to mark Confidential, or adding an attribute to mark Confidential.
2.Marking it confidential
3.Granting the correct users the Control_Access right so they can view the attribute.
For more details and step-by-step instructions, please refer to the following article:
922836 How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836
无论您使用 OctetString 语法的属性还是使用其他语法（例如 DirectoryString），实际上并不重要。从安全角度来看，重要的是分配给保存属性的条目或条目分支的安全描述符。换句话说，二进制属性值很难使您的系统更安全，除非为目录树分配适当的安全性。
您无法拥有类似于 unicodePwd 属性的安全性，因为它有点特殊。虽然您可以分配一个安全描述符来禁止访问您的属性值（即使是管理员），但您无法阻止管理员更改安全描述符并最终获取对该值的访问权限。
It doesn't actually important whether you use an attribute of OctetString syntax or somewhat else such as DirectoryString. What is important from the security point of view is the security descriptor assigned to the entry or branch of entries that hold your attributes. In other words, a binary attribute value hardly makes your system more secure, unless a proper security is assigned to the directory tree.
You cannot have security similar to unicodePwd attributes has, because it's kind of special. While you can assign a security descriptor that prohibits accessing your attribute values even by an administrator, you cannot disable administrator from changing security descriptor and ultimately acquiring the access to the value.
除非您完全打算将自己锁定在 AD 中，否则我建议您仅添加一个带有八位字节字符串属性的 Aux 类并使用它。 （即并非所有其他模式都可能具有具有相同语法的相同属性。刚刚遇到了destinationIndicator。SunOne 和 eDirectory 具有不同的模式语法。）
然后我会加密属性的内容，因为很难保证隐私否则数据。
Unless you totally plan to lock yourself into AD I would suggest just adding an Aux class with your Octet String attribute and use that. (I.e. Not all other schema's might have the same attribute with the same syntax. Just ran into that with destinationIndicator. SunOne and eDirectory have different schema syntaxes.)
Then I would encrypt the contents of the attribute, since it is too hard to guarantee privacy of the data otherwise.