Where do I store sensitive data within Active Directory?

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.

Solution 1:

The problem most people face when storing data in AD is

• Extending the Schema (which often has company-political implications)

• Using an existing attribute and editing the permissions (which results in AD/ACL bloat that increases your DIT and subsequent replication size)

There is an alternative... the best choice in my mind is to use this lesser known feature of AD to take an existing attribute and flag it as Confidential.

Here are details on the process

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

Solution 2:

You could always extend the Active Directory with a new field for this purpose.

Here is a document that includes instructions on adding a new attribute and limiting permissions on the attribute.

Solution 3:

This value should be considered similar to a password, where even administrators shouldn't have access (if possible), just like the current AD Password.

This isn't correct, it's not even wrong. The password is not stored. The hash is stored, and domain admins can access that. In fact, you can even configure AD to store the password in a reversible encryption if you wanted to.

There's nothing that you can keep domain admins out of, in AD. If you remove rights or even Deny, a domain admin can take ownership and add themselves back in. This is in contrast to Novell's NDS, where an admin of an OU could irrevocably lock out higher-level admins.

The best you can do is use an existing or new attribute, and restrict access. You can keep admins out of it, and you could enable auditing on the attribute so that any access or permissions change is logged.