Florian’s Blog

I’m still reading the Forums now and then, although I am not posting as much there as I have in the past. Reasons being, time, motivation and the overall quality of the Forums – but that is a different topic.
What I’ve come across lately at least twice, is a question that can be summed up to:
“How can I hide information in Active Directory (from specific users)?”

Since we’re a technical blog here, let’s discuss the technical possibilities first. There are

• The Active Directory confidentiality bit
• Permission assignment to objects/attributes in Active Directory.

As for (1), the confidentiality bit is a bit set for these attributes in the Schema, so that they are no longer readable to “normal” users. You essentially modify the searchFlags attribute. More on the confidentiality bit: http://blogs.dirteam.com/blogs/tomek/archive/2005/11/21/confidential-bit.aspx. If you have read the article and comments below, you’ll notice that the confidentiality bit is only half-way through a good idea. Admins and “Account Operators” still can read. And it won’t work for “Category 1” attributes (http://www.frickelsoft.net/blog/?p=227). If you have extended the Schema and store the secret stuff in your own attribute, this may be a way to go – granted that you have a very controlled Administrators League and know who “Account Operators” are and that they are OK to handle the information in there.

Otherwise, you’ll want to look at permission assignment on the objects. “Authenticated Users” have “Read” permissions all over the directory – that’s how the directory (I am tempted to say “a” or “any” directory) is designed. So you’ll want to restrict access to them. You can do this by restricting access to an OU you are concerned about (or the attributes of objects that are in there). You change security on the OU and its child objects so that people can’t read object’s attributes in this OU and all sub-OUs.
An alternative, a little more sophisticated, is changing the base security on objects or modify the base permissions on newly created objects, if you wanted. That’ll make sure your change is applied to any new object you create form that object class. Say, you want that for all new users created. A drastic change – and it’s a one-catch-it-all approach. You can decide whether an object is created this way (attributes protected) or the other way (attributes not-protected). You’re changing the Schema here.

While both ways technically work, they differ in impact and complexity. While (1) is just a small change in searchFlags, you’re likely to set a whole lot of security permissions with (2). That requires documentation, testing and verification. Changing a number of security permissions or the visibility of an attribute for an application might break just it – if the application expects the information to be there. You may have to talk to the vendor to be 100% sure. You’ll have to test all applications accordingly and make sure any new application that’s introduced that reads/writes data in AD is tested against this configuration (so you’ll have to configure your test environment in the same way). You might need to adjust your backup/restore process. There are a number of famous applications that just don’t like “messed up” Active Directory permissions – they expect to be allowed to read certain things off the directory.
While this is all technical, I’d like to step back and address a number of inconvenient questions around the topic. Where I say “information” here, I mean data that goes into the protected/hidden AD attribute:

(1) Does that kind of information belong (topic and relation-wise) into Active Directory, the access control namespace or account management? What is the data used for?
(2) Should that piece of information be spread/replicated around the globe to all Domain Controllers (if not specifically configured, to RODCs, too) in the domain?
(3) Who has legitimate access to this information? Is access required from everywhere (regions, departments)?
(4) Is the information tied to an Active Directory account, an AD object? Or is that information tied to a real person or an asset that might change AD accounts/AD objects over time?
(5) Who creates/manages/verifies that data?
(6) Is replicating that data all over the world a legal issue?
(7) Is the data type/structure suitable for AD?
(8) In case the AD team is now allowed to view the data (process-wise), do backup/restore processes have to be adjusted? What service accounts would need to be added to the “Allowed for read” list?
(9) Does access to the protected information (read, write, …) require auditing? Who would look at the auditing data? Who can be granted access to them? Whose responsibility is it?

Talking to customers, these are the “less famous” questions around the whole idea of storing data in Active Directory and how to secure them. Addressing this topic from a non-technical angle, people most of the times don’t have a good understanding of why they want the data in Active Directory, really. It’s convenient to store it there, as code is around that can read AD, it is backed up regularly, it is replicated to several places and other people (the AD team) care about the service.

Should you really dump all stuff in AD? Active Directory is not another relational database – so you should not try to make it one. It can store and handle requests for some type of data better than for other types. Sorting of data – as an example - is not one of the strengths when done server-side.

In addition, Active Directory is a directory, designed for broad “reading” capabilities. As built-in, “Authenticated Users” have a wide range of read permissions in the directory. Cutting them down might not be a good thing when third party applications rely on these capabilities.

Who’s responsible for the data? If it’s not the AD team – you’ll need additional delegation in Active Directory that allows the right people read/write access to the data. Possibly another tool to provide the data owners. With that – does changing the data require auditing? If so, who looks after the auditing data? The AD team?
Depending on what your answers for questions 1-9 are, you might want to re-consider using Active Directory for data storage. Or you are re-assured that AD is a good place to store the data. In case not, you should consider looking at a different data store:

• AD LDS – it’s still AD but easier to adjust/lock down – you may not have as many application dependencies in a fresh AD LDS instance
• SQL or any other database
• The HR system