There is no way to change  this default behavior  given your current
structure. If you don't want clients  to be able to see users  in other
sites the easiest way to prevent that would be to create the sites  in
different site  Collections. People and groups  will only show you the
users within the Site Collection. You can't do this retroactively, but
if you switch the Root managed path from a Wild Card to Exclusive
Managed Path you could have the exact same url structure you list below,
but have each site in its own Site Collection.

I'm not  sure that separate site  collections completely hides users  &
groups.


I can understand how separate site collections will hide sharepoint
groups that have been created within a site collection.


But wouldn't users come from the membership provider (eg Active
Directory, LDAP, SQL db etc)?

And therefore the 'people picker' would show ALL user  accounts that are
available across the entire farm (or web app)?

You are correct, People Picker would show any AD users  or AD groups. But I
think the People Picker is Impersonating the Logged in user  to AD, so users
placed in OUs that the user doesn't have access  to probably wouldn't show.
That's on the AD side of the fence and I haven't tested it, so you may be able
to ADD any AD user or AD Group no matter what Site Collection you are in.

But I thought the question was about the users and groups  that show in the
People and Groups list. Those are all SharePoint users and Groups. These would
be blocked by a separate Site Collection, because the SharePoint Users and
Groups are defined within the boundaries of a Site Collection. SharePoint Users
and Groups are all based on the user or group in the membership provider, but
don't show in People and Groups until added to SharePoint.

Interesting point about the people picker impersonating the logged in
users.

Definitely going to have to try that one.

I guess I was interpreting the question a little different.

Let me re-state in my terms (or I guess as a problem  I've been thinking
about for our environment)

Lets say I create a dedicated farm for an extranet sharepoint  site.

To keep things simple lets also say that I create a new AD forest for
creating the user  accounts in.

(I don't believe that user accounts can be created directly in
sharepoint, they have to come from some membership provider)

And in this AD forest I'm going to put in both my client user accounts
and my staff's users  (clearly will be duplicates, forest to forest trust
is probably a better way to go just keeping it simple for this example).



I create 2 x site  collections, one for client A and one for client B.

I don't want client A to know anything about client B and vice versa.

I can lock down both site collections with permissions and thats fine.

So they are not  going to be able to see each other people and groups
pages.

Where I think this falls down is if a person from client B is in the
client B site collection and say they can create a task and go to assign
that task,

I believe that the people picker (address book) will show all users
including the contact details of all the client A staff.

I don't think there is a way around this just a limitation.

I agree. Try a simple test. Create an OU, call it GroupA. Add some
users to it. Limit the rights to the GroupA OU so that a user  in
another OU has no rights to the GroupA OU. Log into SharePoint as one
of the users  in the other OU. Pull up a list of users to assign tasks
to and see if you can see the users in GroupA. I think there is a good
chance that you can't. At least that would be the theory if SharePoint
is impersonating the logged on User.

I'll try this when I get a chance and report back, but it may be a
couple days before I have time to pull up my MOSS image since I'm
teaching SPS 2003 this week.

I have confirmed the behaviour of the people picker.

It is security trimmed by the user  executing the query.

Created an OU=Restricted users,

Created a user=secure test

Created an OU=hidden users

Created a user=hidden user

In AD user and computers kept blindly removing permissions on the Hidden
users OU and user account until no access.

To test this go to the security tab of the 'hidden user' user object,
security tab, click  advanced, go to the effective permissions tab

Select the 'secure test' user account and effective permissions should
be all grey boxes with no ticks.

(in production some sort of permission design using explicit deny might
be a better way to do this, not  sure yet...)



So I created a site  collection and set 'secure test' as the site owner

Once the site collection was created, I just used the team template,

I logged in as 'secure test', browse to the site, create a task and
assign a user.

Launching the people browser (address book icon thingy!) search for
'hidden' or 'user' does not show any matched results.

So that is good.

Ok now on to test number 2, what happens with the profile import in the
SSP and what happens when the 'secure test' account does a people search
through a search centre site...... more to follow.

And others that have been reading this topic.

Just found  a further piece of info on this old topic that people may
find interesting.

In the technet2 doco there is a post on peoplepicker properties

http://tinyurl.com/3c43vh


one of the properties is

peoplepicker-onlysearchwithinsitecollection (yes : no)

Copying from the technet2 site

-----------------------------

Displays only users  that are members of the site  collection.

Only users that are already added to the site collection are displayed
in the People Picker. This prevents anyone from browsing your user
directory through the People Picker.

-----------------------------

This looks like a nice way to lock down those extranet sites.