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
