Scenario:
A user decides to give his colleague access to a document. He clicks the Add Users button to select his colleague, clicks the address book icon and types in John in the Select people and groups dialog box. On clicking the search icon he’s presented with a list of 50 different John’s – of which only 3 actually work for his company. The user is confused, talks to his manager, manager talks to his hosting provider – “If I can see other companies’ users they can see mine. Outrageous… and in direct violation of the Data Protection Act. “. What ensues is plenty of some embarrassing explaining to do…
Cause:
The people picker gets all users from the Active Directory where the WSS farm is deployed. By default no filters are applied when users search for people using the “Select People and Groups” dialog box. In an environment where there are multiple site collection the search box will display users from the whole Active Directory rather than, as you would expect, users from the site collection only.
This behaviour can not only be confusing for end users but can present a serious privacy issue in hosted environments where every site collection is used by a different company and employee information should not be revealed to unauthorised users (those belonging to other site collections/companies). You don’t want end users to be able to search the entire Active Directory
Solution:
Stsadm peoplepicker-onlysearchwithinsitecollection parameter
“The command below will set the people picker so it displays only users that are already added to the site collection. This prevents anyone from using the People Picker to browse a different user directory” [quote from the MS article]
stsadm -o setproperty -propertyname peoplepicker-onlysearchwithinsitecollection -propertyvalue yes -url http://<defualtzone.sitecollection.url>
For full syntax check the following MS article: Peoplepicker-onlysearchwithinsitecollection: Stsadm property
Gotcha
Ok, so the above command is mentioned in quite a few blogs – you could be easily forgiven to just run the command, check your People Picker see results are now trimmed to users from your site collection only and forget about the whole thing. There is one significant caveat to be aware of though – a small, easy to miss, note in the MS article mentioned above says:
“Users can search Active Directory using a fully qualified logon name, regardless of this property setting.”
WTF? Turns out even though users will no longer be able to use the People Picker to search for users outside their own site collection when searching by name they will still be able to snoop around if they use a fully qualified logon name (domainname\username). See the table in this article for the full list of name formats that will still return results from outside of the site collection
Solution:
Microsoft now offers a hotfix to address the issue – described in the following MS article: The Check Names function does not honor the Peoplepicker-onlysearchwithinsitecollection setting in Windows SharePoint Services 3.0
The hotfix will truly lock people picker down – even searches using a fully qualified logon names will not return results from outside of the site collection.
There is a small price to pay though – you will no longer be able to add users to the site collection using the GIU (as no users from outside the site collection will be displayed) and will instead have to rely on STSADM (or code).
Other notes:
For some reason the peoplepicker-onlysearchwithinsitecollection parameter would not work for me a few times – it turns out you seem to have to use the full command without abbreviations:
- this command will work:
stsadm -o setproperty -propertyname peoplepicker-onlysearchwithinsitecollection -propertyvalue yes -url http://<defualtzone.sitecollection.url
- this command will sometimes not
Stsadm.exe -o setproperty –pn peoplepicker-onlysearchwithinsitecollection –pv yes –url http://<defualtzone.sitecollection.url
Filed under: Uncategorized
