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

Inline
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.

- LOL, why should I feel bad about any posted comment, in fact is always a pleasure to read different prespectives and opinions, especially from you. That's what I love most in the newsgroups, the possibility to read different opinions and to learn new methods and scenarios, we can all learn much more here than any other place or book.
- And of course I respect your position about this.

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.

I'm my opinion, at the end, even if you implement scripts, it's all about groups... You can't do this by user scope, you must use groups, so why mess with defaults when we can take advantage of MOSS capabilities.

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.

Yes I agree in this point, that's why I suggested to take advantage of MOSS Groups and AD Groups.
Pretty easy (In my opinion)

Create MOSS security groups, relate them with AD groups then when a new user is needed just place it in the correct group.
If MOSS Admins need to administer users and/or group membership, just create a mmc console and delegate the proper rights for them.
--
*************************************************
I hope that the information above helps you
Good Luck

Jorge Silva

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

"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message news:OEjzXSlHHHA.3676@xxxxxxxxxxxxxxxxxxxxxxx


"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: Public Folder Permissions
    ... Every time I try to provide rights based on group membership it ... permissions to successfully work. ... you must be in AD Native mode to use security groups for PF / ... Harking back to pain of running mixed-mode Exchange and mixed-mode AD ...
    (microsoft.public.exchange.admin)
  • Re: Creating Multiple FTP Users and Containers (2000 Server + IIS)
    ... > IIS Administrator for an FTP site. ... > complete Windows Scripting novice so I'm hoping that I can get some help ... > What I am even more unsure of is scripting the creation of Virtual Folders ... The permissions will need to be set to ...
    (microsoft.public.windows.server.scripting)
  • Re: Sql permissions headache
    ... By scripting all of your database objects and the permissions ... Knowing which permissions to assign each group is not going to be easy... ... creation (tables, views, stored procs, etc.), I put a GRANT statement to ...
    (microsoft.public.sqlserver.security)
  • Re: Creating Multiple FTP Users and Containers (2000 Server + IIS)
    ... >complete Windows Scripting novice so I’m hoping that I can get some help on ... >What I am even more unsure of is scripting the creation of Virtual Folders ... The permissions will need to be set to ... >account will need to be given ‘modify’ permissions (everything except ‘full ...
    (microsoft.public.windows.server.scripting)
  • Re: Login script based on group membership
    ... I have never seen a method to check group membership in a batch file unless ... Most of the examples map drives according to group membership. ... you select depends on the client OS's your logon scripts will support, ... Microsoft MVP Scripting and ADSI ...
    (microsoft.public.windows.server.scripting)