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 AM
To: [email protected]
Subject: 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
