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.

alt text


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.


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


  • 1
    Downvoter: Why did this get a -1? – goodguys_activate Feb 13 '12 at 18:02
  • I heard that the confidential bit may impose a significant performance penalty. Do you know of any docs that support or refute that? – Nic Jul 20 '13 at 4:41
  • @Nic post that as a question... first I heard of it – goodguys_activate Jul 20 '13 at 10:45

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.

  • Thank you. My goal is to use an existing attribute if possible since my clients are beyond paranoid about doing this... they have too much FUD in that approach... I'm hoping for something native if possible. – goodguys_activate Sep 16 '10 at 6:28
  • I can understand their reluctance, but I don't believe there are any good candidate attributes that aren't used and secured as required. – Zoredache Sep 16 '10 at 18:42

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.

  • I am storing a one way hash of a password specific to my application. – goodguys_activate Sep 16 '10 at 13:29
  • This belongs as a comment, since it does not answer the question in any way. – MDMarra Sep 16 '10 at 13:31
  • Mark - my last two sentences are my answer to the question "Where do I store sensitive data within Active Directory?" – mfinni Sep 16 '10 at 13:33
  • @Maker - That makes sense, and it's a very similar scenario to the link that @Zoredache posted above. That is the native answer : use an existing or new attribute, and limit the access. My additional suggestion, if your client is focused on security, is to also enable auditing for that attribute. – mfinni Sep 16 '10 at 13:34
  • @Maker - if it's truly a one-way hash, then it's already fairly secure anyway, right? – mfinni Sep 16 '10 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.