Storing private "octet string" in Active Directory; what is secure by default?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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