We're talking apples and fishes in this case (sure they're both foodstuffs, but they're vastly different otherwise.)
To address the particular point: it's not a security "problem" that you can read data that pertains to your function. Rather, it's an acceptable risk proposition - you need that data to do your job, therefore you must accept the risk else not accomplish the job.
That you can walk away with GPO data points to a fundamental design flaw with GPO's more than it does with the directory service concept. GPO's are stored in the directory by convenience (for convenience as well) and are not by default available to a non-authenticated user (and therefore not to just anybody that walks up and wants to see them.) In the example from earlier, GPO's are given to those with a need to know and no more. More specifically, data is given to a targeted audience that is as small as it can be and still accomplish the task.
Is it a risk? Yes. Is it something that should be stored in the directory yet not be viewable by everyone? Opinions vary; I'm interested to hear yours on this subject. I would say that if the authenticated user needs that data to do their job, then it's an accepted risk by default. You put that data in there for the user, so therefore you accepted that risk. You mitigated that risk by ensuring that only authenticated, and therefore those that are permitted to see that data, can see that data. The fact that it's everyone and every machine is a scope issue and beside the point of the data being put in the directory vs. the risk you assume.
GPO data is needed by every authenticated user and every authenticated principal. It's mobile because it gets cached to the device. There is no way to prevent that data from getting to those that need it and still function.
A phone number is an optional piece of data. An insurance number is an optional piece of data. A SSN is optional. Marital status is optional data. Pay base data. Those kinds of personal data are the kinds that regulatory compliance efforts will get stuck on. Technical data obtained in the course of getting your job done is not going to be a regulatory issue. If it is, the regulation needs to be revamped because it was never intended to put people out of work, but rather to protect them.
Technical data available to everyone is going to be a risk; no question that it can be risky for people to have that data on the mobile device only to have it walk out the doors where physical security is questionable or where that disgruntled worker can use it to mount an attack. I won't discount that. But it's a fish vs. an apple in this conversation and it's not the same as hiding data in the directory to prevent people from seeing it. I still see no valid reason I would store data intended for a subset of user in a directory intended for the whole. Makes no sense to me at all.
Keep in mind that the directory as a concept is designed from the ground up to be a repository of data. It is useful for serving up data quickly. Data such as attributes describing identity, certificates (some of the early uses certainly), as a white pages, or as a repository for commonly accessed data. If you step beyond that and try to segment off pieces of it, you're doing unnatural things. Notice I'm not saying you're pushing the boundaries. 'Cause you're not. You're turning the directory into an application that would normally be used to consume the directory serivce. That's what applications are expected to do in this ecosystem. They should consume the data stored in the directory. The service owners should not be placing confidential data in a directory service. They should be using the directory service data to base decisions on whether or not to deny or permit access to said data in an application. Don't let the concept of authentication in Active Directory fool you, that's a separate entity that consumes directory data but happens to live on the same host giving it the appearance of a single entity. Even so, it follows the rules of use for directories by being a separate application and consuming directory data. You won't have access to authentication data and that's by design.
FWIW, there is no directory service out there that's going protect the data to the level it needs to be (it's totally against the purpose of a directory). That's the application's job strictly speaking.
Al
On 6/2/06, Darren Mar-Elia <[EMAIL PROTECTED]> wrote:
Al-You make some good points and generally speaking I agree that, if possible, sensitive data should probably not reside in a general purpose directory. That may or may not be possible in certain scenarios. I guess what I'm trying to say is that there may be valid reasons why someone would want to have data in AD that should be hidden from "Authenticated Users", that does not also prevent proper operation of the OS. Yes, there is a good and granular access control system in AD that provides for many of these scenarios ( e.g. preventing read access on a PhoneNumber attribute or something like that) but when you go beyond the basics, it gets tricky and there are no good mechanisms in place to do this "naturally".
Here's an example that is close to home for me. As a normal user, authenticating to AD, I can fire up GPMC and, in most cases, view the settings on any and all GPOs in a domain. I can even back up those GPOs to my USB drive and take them home with me. All this because I have to have Read access to those GPOs in order to be able to properly process them. So here you have data that belongs in AD, that requires that all users be able to read it, but that compromises the security posture of an organization (at least, I would consider a normal user having access to an organization's security configuration to be something of a compromise).Darren
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Friday, June 02, 2006 10:16 AM
To: [email protected]
Subject: Re: [ActiveDir] HIDE OU
Darren, I see what you're saying but I have some serious issues with the idea of putting information in the directory and trying to hide it so that people won't misuse it. Hiding an OU is not a security a measure regardless of intent. If that's the way the bc dictates it to be done, then perhaps another tool should be considered.I know what you're talking about, and you caught me making a blanket statement with a very specific "requirement." I quote that because I strongly disagree with putting that type of information in a directory such as AD, Oracle, SunOne, etc. in most cases[1]. Why? What's the value? Is the right tool to use for that job? I have yet to personally run across a time where there was a real reason for that. I've been places that tried to tell me that phone numbers weren't to be accessible in the directory because some of the privacy laws in some of the countries prevented it. Not only was that BS, but my response was not to publish the data in the directory then. Know what they did? They built a searchable directory and put that information in there and made it available to all authenticated users under the guise that if they're authenticated, they could control the data and therefore it met regulatory requirements.If the HIPAA (put in whatever regulatory requirement you actually have) data needs to be protected, it likely is data that the data is not applicable nor appropriate for the entire organization to view. If that is the case, is it really a candidate for an org-wide directory? Or should it be used in an audience-specific way/application instead?As you consider that question, consider this as well: Regulatory compliance is going to continue. What's OK today may be prevented tomorrow. That's a given and because of that, use good practices today to save you the headache tomorrow. Putting information in places that it has no real need to be ( i.e. because you can put it there is not a real need) is not a good practice if you're ever going to be concerned about regulatory compliance. Things like tax id, SSN, insurance numbers, home phone number, out of office messages, etc can and should be protected for personal identity rights and safety. Taking it out of the protected HR system and putting into an org-wide directory system is not appropriate to that task. Further it goes against the KISS principal and has no demonstrable value that can't be obtained with obfuscated data. Similar to what that knucklehead at the VA did - he took the easy way and used live data at home. That was a convenience. He could have EASILY used obfuscated or relationship data to achieve his task. Wrong tools for the job IMHO. AD is not the tool to store HIPAA protected data.
Am I missing something in my view? If so, please let me know.[1] the one case that does come to mind is application specific. Because of that, the directory is not being used as a GP directory service as most AD deployments are but rather more like ADAM was intended to be used with a focused audience and focused application usage.
On 6/2/06, Darren Mar-Elia <[EMAIL PROTECTED] > wrote:Al-I agree with what you're saying except for, "I see absolutely no value in hiding the directory data from anyone that has authenticated as at least a user of the system"Today there are valid reasons why, just because you are authenticated to a system does not mean it is appropriate to be able to view the existence data. The new Access-based Enumeration feature in Server 2003, SP1 speaks to this problem. There are many regulations (HIPAA comes to mind) where just being able to view the name on a piece of data could constitute a breach of privacy. So I can see where, under certain circumstances, you want to be able to hide things from users who have every right, under normal authentication mechanisms, to see it. But I agree that AD does not make that easy. I think in those situations, that probably the best approach is to "obfuscate" by preventing the user from accessing directory data from any application other than one that is very controlled and only exposes the information they need based on their role. In other words, in the absence of a Hide ACE, you have to provide your own level of hiding.Darren
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al Mulnick
Sent: Friday, June 02, 2006 8:55 AMSubject: Re: [ActiveDir] HIDE OU
Interesting.If 'Microsoft' doesn't know why authenticated users need read access to that OU, I suggest that the wrong person was asked. :)I also suggest that if the OU was hidden for security reasons, that approach should be reconsidered. Security through obscurity is never a good idea and often, as you've seen, can cause issues such as DoS that defeat the purpose of security in the first place. Security should be opaque to be of value.I see absolutely no value in hiding the directory data from anyone that has authenticated as at least a user of the system inferring that person is an authorized user of the system. While I will agree that hackers prefer and even thrive on more information about systems (information gathering is one of the steps to a successful hack, right?), I don't agree that hiding something like a directory object is a security measure. It's likely to have the reverse effect in spades.
</rant>Thanks for posting the answer, Za.
On 6/2/06, Za Vue <[EMAIL PROTECTED]> wrote:Prying eyes of junior admins?
I managed my own AD environment and do not hide any OU or User and we are not trusted with our main campus AD, however, the undergraduate departments are part of the campus AD. It took a year to figure why no one can rename a computer. The computer have to disjoin the domain, rename, and and then rejoin the domain, that is the only way. The main AD guys just said that is the way it is so live with it. I was asked by 2 departments to test it in my domain. I have no problem renaming computer accounts in AD. So we renamed a whole lab w/o any issue.
They must have asked for Microsoft's help, and it turned out that the "Builtin" OU was hidden for security reason. For what reason I didn't ask. Authenticated users need READ access to that OU. Why? Microsoft does not know.
So after they figured it out I wanted to see how they hide that OU. One way to modify(hide) OUs and Users is to use ldifde.exe. I tested and it did work. So there is my solution.
-Z.V.
Al Mulnick wrote:I think that's a nice segueway back to asking, "why?"What is it you need to accomplish that you would hide the OU and it's objects?
On 6/1/06, Timo Ed <[EMAIL PROTECTED]> wrote:be careful doing that... if you have users in that container and you
do not give both the client machine and the user certain read props
then policy will break, among other things.
If your just trying to hide from AD mmc's then you can set the
ShowAdvanceViewOnly attrib which will hide the object unless the admin
has enabled 'Advanced View'.
Rgds,
Tim
On 6/2/06, Daniel Gilbert <[EMAIL PROTECTED]> wrote:
> We created OU's and removed all users except for Domain Admins (of
> course we left the SYSTEM access). The OU never shows up for
> non-Domain Admins.
>
> Domain Admins have full access to the OU and can add as many objects as
> they want.
>
> Dan
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
