Re: how to restrict users to search in their own Organizational Unit



"Jorge Silva" <jorgesilva_pt@xxxxxxxxxxx> wrote in message news:%
I would like to say that Herb's suggestion doesn't sound an easy or Fast
solution, or more reliable than mine and sometimes can lead you to other
problems, without going into deep on this I would like to say to Herb that
maintaining the User group membership isn't not so hard, Lao can always
create a UserModel in the correct OUs and Just copy it from there, if the
user is in the correct groups it will be created with the necessary
groups.
--

Don't feel bad about saying this as you are absolutely
agreeing with me -- I advised against this whole idea,
and believe it to be a poor choice. Mostly I posted the
scripting idea to show all of the issues involved and
to indicate that any tedious and ugly process is a good
candidate for scripting IF the process makes sense at
all.

In a large domain, manually ensuring new users have
the correct group membership (when failure to do so
will expose a security hole rather than allow access
and thus have the user complaining) is a very easy
thing to mess up.

Only an automated process can be truly trusted when
security is really an issue AND something must be
done repetitively and frequently.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"Jorge Silva" <jorgesilva_pt@xxxxxxxxxxx> wrote in message
news:%239gfogkHHHA.924@xxxxxxxxxxxxxxxxxxxxxxx
Ok
Let me start by saying that I only knew the real scenario after Lao's
second post.
I also want to say that in fact you shouldn't deny the read permission to
anyone and this scenario the MOSS Administrators or who is responsible for
Add users to Your Sites should be carefull when performing this action.

Now, because you're dealing with many users, my recommendation is to
create THE NECESARY Security Groups in each OU and related them with your
MOSS2007 existing security groups, in future when someone creates some
user, you just have to add that user to the necessary group and that user
will be given the necessary permissions.

*************************************************
I hope that the information above helps you
Good Luck

Jorge Silva

MCSA + Exchange + MSCE
*************************************************

"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:eRkDTqhHHHA.1188@xxxxxxxxxxxxxxxxxxxxxxx
Just set up delegated permissions to deny read acces for the users to
the specific OU's

That was Jorge's original suggestion but it is not
a simple matter (that is, no "just set up").

Who would you DENY? (Authenticated users or
Everyone would include Admins and the system itself.)

Jorge indicated creating a group, but doing that is non
trivial -- how do you maintain this group -- and the
poster has MANY OUs and thus needs many such
groups to restrict access for each set to only the group
created for each OU.

This is NOT an easy problem, but once the solution is
decided a script can make it possible to accomplish,
even if it is messy and ugly.

Again, I recommend against the idea, but there is certainly
no "just" involved.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"MPerrault" <mperrault@xxxxxxxxxxxxxxx> wrote in message
news:1165944097.876342.276440@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Herb Martin wrote:
But, we have +/- 40 OU's with approximately 12000 users, how can I
handle this problem best?
If I need to create a security group per OU and then add all users
seperately then I will have alot of work...

Although I think the whole thing is a poor idea the
most likely approach to make this practical is to
write a SCRIPT.

[Admins need to be at least minimally competent at scripts
writing so that at least they will know the basics and can get
a true programmer to write the hard ones.]

You could also TRY removing the "Authenticated Users"
(technically it isn't Everyone with these permissions) at the
Domain level (and propagating) since using a lot of DENY
permissions is in and of itself a poor practice.

Even then, I suspect something will/might go wrong so
try this in a test domain, OR see if some AD expert will
comment who has actually DONE such things. (Windows
has a bad habit of going south when such sweeping
changes are made even though in principle they are
perfectly logical.)

General script logic:

Loop through each (top level) OU
1) removing Auth. Users from permissions*
2) create group of with OU users as members**
3) add this group to permissions for this OU

* Watch out for the effect on COMPUTER accounts etc.
(Unless this is a test domain, I would likely REPLACE
the Authenticated User permissions with an empty, 'place
holder' group so that putting this stuff back would be
practical.)

** Must be maintained over time by 1) creating a template
group and always created users through copying this
with OU-group membership OR by scripting creation
of users with this membership as there is no built-in
mechanism for granting/denying permissions based on
"OU" and these groups are a (semi-)manual thing.

You might have to periodically re-run this script to
rebuild the groups to prevent discrepancies from
growing over time (e.g., as users are moved from one
group to another.)

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

<lao.nightwolf@xxxxxxxxx> wrote in message
news:1165933306.200588.167530@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Jorge Silva schreef:

Hi
By default evryone has read-access to AD.
To deny that right you must create a security group and deny read
permission, then add the users to that security group.

--
*************************************************
I hope that the information above helps you
Good Luck

Jorge Silva

MCSA + Exchange + MSCE
*************************************************


Thanks that helps already!


Just set up delegated permissions to deny read acces for the users to
the specific OU's

Michael P. Perrault
MCSE, CCNA, A+, MBA
Senior Systems Engineer,
ScriptLogic Corporation


Michael.Perra...@xxxxxxxxxxxxxxx
www.scriptlogic.com
http://groups-beta.google.com/group/scriptlogic-desktop-authority






.

Relevant Pages

  • Re: how to restrict users to search in their own Organizational Unit
    ... decided a script can make it possible to accomplish, ... You could also TRY removing the "Authenticated Users" ... Domain level since using a lot of DENY ... permissions is in and of itself a poor practice. ...
    (microsoft.public.windows.server.active_directory)
  • Re: how to restrict users to search in their own Organizational Unit
    ... I also want to say that in fact you shouldn't deny the read permission to anyone and this scenario the MOSS Administrators or who is responsible for Add users to Your Sites should be carefull when performing this action. ... Now, because you're dealing with many users, my recommendation is to create THE NECESARY Security Groups in each OU and related them with your MOSS2007 existing security groups, in future when someone creates some user, you just have to add that user to the necessary group and that user will be given the necessary permissions. ... decided a script can make it possible to accomplish, ... > If I need to create a security group per OU and then add all users ...
    (microsoft.public.windows.server.active_directory)
  • Re: how to restrict users to search in their own Organizational Unit
    ... If I need to create a security group per OU and then add all users ... permissions is in and of itself a poor practice. ... General script logic: ... of users with this membership as there is no built-in ...
    (microsoft.public.windows.server.active_directory)
  • Re: how to restrict users to search in their own Organizational Unit
    ... If I need to create a security group per OU and then add all users ... Domain level since using a lot of DENY ... permissions is in and of itself a poor practice. ... General script logic: ...
    (microsoft.public.windows.server.active_directory)
  • Re: OU GPOs
    ... I checked and there are no "deny" permissions anywhere ... >> a security group and placed members in this group. ... >> created an OU GPO and set the policy and have given the ...
    (microsoft.public.win2000.security)