nope, not if you did your job right at the OU level and you don't care to see _anything_ underneath.
However, if you do want to show specific objects within the OU (say only a single child OU or only specific user accounts or groups within a parent OU), then you won't get around leveraging the list object mode => you'd then remove the list content permission (e.g. for Auth-Users) and only allow the list object permission on the parent OU so that every object underneath this OU that still has the default Auth-Users READ permissions (or has granted specific List Object permissions) will be visible by browsing or by querying AD. Thus, to hide those users which you don't want to be seen at all, you'll have to remove the default Auth-Users READ permission which is explicitely stamped on all (well most) objects in AD. Often mistaken: say you had a two-level OU structure (DOM-OU1-OU1.1) and you only remove the READ permissions for Auth-Users on the first OU-level (DOM-OU1), then users (or delegated admins) can't browse to the second-level OU (DOM-OU1-OU1.1), but this OU will still have those default READ permissions granted to Auth-Users => this allows all users in your domain (and trusted domains) to query for all objects _contained_ in that second-level OU1.1... Removing the default Auth-Usrs READ permission on the sub-OU will fix this problem (which is why I suggest to change the def. sec. descriptor for the OU class so that you don't have unwanted surprises at the sub-OU level for new OUs created here) /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Samstag, 23. Juli 2005 01:15 To: [email protected]; [email protected] Subject: RE: [ActiveDir] Hiding an OU Guido, Removing read for auth users they cannot go into the OU and List Object does not even show the OU. We agree on that one. However, if you don't remove the explicit auth users/everyone from the objects inside the OU, what happens if I query for specific object types inside the OUs? I thought for auth. users/everyone not being able to see those you also had to remove the explicit perms for auth. users/everyone on those objects Cheers, #JORGE# ________________________________ From: [EMAIL PROTECTED] on behalf of Grillenmeier, Guido Sent: Fri 7/22/2005 11:46 PM To: [email protected] Subject: RE: [ActiveDir] Hiding an OU if you're fine with other users seeing the existance of OUX, then there's no need to leverage DSHEURISTICS and the list object mode. but I'd suggest to change the def. sec. descriptor for OUs by removing Auth. Users from it - this way you'll be on the safe side that stuff in new OUs won't be readable or searchable by accident. You shouldn't need to remove the explicit auth. users read permissions from the objects contained _within_ the Sub-OUs, as long as you've removed the read-permissions for auth.users on all OUs... /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Freitag, 22. Juli 2005 15:52 To: [email protected]; [email protected] Subject: RE: [ActiveDir] Hiding an OU each time you create an OU beneath that OUx remove from the OUs authenticated users. The objects in the OU also have authenticated users and everyone explicitely defined. you also need to get rid of those too. Remove the members of the Pre-Windows 2000 compatible Access group (if possible and this depends if you have legacy apps or servers) remember that if you use the default MS admin groups (account operators,etc) those members can still see and do actions they have permissions configured for. Removing auth. users and everyone makes sure those groups do not have the ability to see the values of properties of those objects. However they will still see the objects itself (visual) to prevent that also you need to use the "list object" permission which is not availabel by default. Use List Object permissions, if users are not supposed to see the existance of specific objects To activate (for whole AD forest) change the DSHeuristics property on the Directory Service object to 001: cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=ForestRootDomain Use in combination with the LIST CONTENT permission on parent container (Caution: if used wrong, you could revoke access to sections or all of your Active Directory) Cheers #JORGE# ________________________________ From: [EMAIL PROTECTED] on behalf of Dave Fugleberg Sent: Fri 7/22/2005 3:16 PM To: [email protected] Subject: [ActiveDir] Hiding an OU I have an OU (call it OUX) that contains a bunch of OUs, which contain users. I want to hide the OU so that only administrators and members of one specific group can see it if they browse the directory (say with Windows 2000, or LDP). I also want any new OUs or other objects that I create under OUX to get the same treatment. I don't care if others can see OUX itself. I know that Authenticated Users gets lots of read permissions on new objects from the default security descriptors (these have not been changed). This domain also has Everyone still in the Pre-Windows 2000 Compatible Access group, because nobody has taken time to figure out if it can be removed without screwing anything up. The domain is W2K native with some W2K3 DCs and no clients below NT4 SP4. I figured out a way to do most of this, but I was hoping the experts here could tell me how they would approach the issue. My solution ended up blocking inheritance and removing the read permission for each sub-OU manually... Thanks! ________________________________ Start your day with Yahoo! - make it your home page <http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs> This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
