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 Mulnick
Sent: 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
