Filtering the SharePoint People Picker Results
Someone asked in the comments on another post how to filter the responses to the People Picker to only show active users. Its an unusual question, in that “Active Users” is so difficult to define. The People Picker’s default behaviour includes a check to make sure that the account is enabled in Active Directory, so disabled accounts are hidden. Perhaps it means just users, not groups, or just those users granted access to the Site Collection.
I actually favor the option in the people picker to only return users which have been granted permissions on the Site collection. This instantly means users in one site collection don’t know about the existence of others by default, and is easy to implement. Just run:
stsadm -o setproperty –url http://<server> –pn peoplepicker-onlysearchwithinsitecollection –pv yes
You can add specific users to the site collection by searching for the fully qualified logon name, but the people picker will only return users on the site.
If you need slightly more unusual options though, you’ll need to alter the query itself. It’ll also potentially affect the ability to add any users to the site, so be very, very careful - I’d really recommend not trying this unless you are pretty confident with LDAP queries.
There are several ways of doing this – first, you can set the People Picker to use a custom LDAP query, and select exactly what you need from the AD. The alternative is that you can allow the People Picker to use standard querys, and then filter the result set. You can also restrict queries to a particular OU, which would obviously limit the response.
The first is best if you need to limit the query to a specific OU or search for a custom field flagging people as a SharePoint Site user, but be wanred – performanced on a non indexed field will be appalling. I’d avoid it if possible. The second is better if you need to hide certain user accounts (like service accounts) from the returned queries. The last option is quite neat, but its rare that you structure AD for your SharePoint web applications. Synergy online covers all these options in detail here.
Incidentally, I believe the LDAP query to filter for only active users is:
(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))
So to only return active users, not groups, you could use the following filter:
stsadm -o setproperty -url http://server/sites/vp-site -pn peoplepicker-searchadcustomfilter -pv “(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))”
One final note – the AD filter and limiting the queries to an OU are only available from SharePoint SP1 onwards – make sure you’re patched!
I have one query related with people picker.
I want to allow to search only those users who are assigned for respective project in people picker.
I am explaining you my requirement in details:
I have tow custom lists.
One is CustomList_Project:
In CustomList_Project custom list, i have following columns:
1) Project name: Textbox(User enter project name)
2) Assigned To: People picker(User assigned for this project)
Second is: CustomList_Second
1) Project name(which is lookup control and whose values come from CustomList_Project(which is custom list)
2) GetProjectOwner : People picker: When i select project name then it would only allow to search those users who have assigned for this project.
(By default it is comming all users)
Regards,
Viraj Vashi
Viraj – If you want to carry out totally custom queries based on lists with SharePoint itself, you’ll need to write a custom component to return the user list, not the People Picker. By its nature, the People Picker is designed to work with SharePoint and Active Directory Security – users assigned to the Site Collection, or in certain groups in AD, for example. Writing a dedicated webpart to return people for security based on lists should be pretty straightforward, but its a task I’d hand over to my development team.
@Rob
I have an issue where we are using subsite for different customers. When people participate on these separate subsites they can view all contacts (all of our customers) when searching using the people picker. Very Bad. Is there a way to only return results based on who has access ot that subsite?
Thanks
Greg
@Greg
Bad news, Greg. The security model (as relates to the peeople picker) is based around the Site Collection, not subsites. If you use site collections, then
stsadm -o setproperty –url http:// –pn peoplepicker-onlysearchwithinsitecollection –pv yes
would do exactly what you need. I’m not an LDAP specialist, and altering the query will affect the entire web application, so you need to be careful, but it might be possible to write custom LDAP scripts to return an appropriate subset of users with either the custom filter or custom query options, depending on your directory services configuration.
Out of the tin, SharePoint seems designed to work with Site Collections being the security scope, though, not subsites within them. Sorry for the negative response – I think you’d be better off working with site collections for customers, not subsites.
@Greg
Actually, Greg, on reflection, the situation is even worse for you than I first thought! The PeoplePicker actually returns users from two locations – from a direct query against Active Directory (or whatever directory services you’ve set up), and against users that have actually “hit” the site collection … not subsite. Even if you wrote a specific LDAP query that managed to overcome the issue, you’ll still have incorrect users returned, I believe
A redesign based on site collections, writing a custom plugin to replace the people picker, or simply locking down the entire people picker from external access would seem to be your only options, in my opinion, of course.
Another option, again limited to site collections, is to specify the OU for users for the site:
stsadm -o setsiteuseraccountdirectorypath -path “CN=Sales,DC=ContosoCorp,DC=local” –url http://server_name
which is great for locking down the users with access to a particular site. Sorry I can’t help with subsites though!