Limiting People Picker Scope in SharePoint
There are many cases where you do not want the people picker to show all users in your Active Directory or LDAP user store. For example if you have separate web applications in the same farm for intranet and extranet, you do not want the extranet users to appear in the intranet’s people picker. This is only one layer in the intranet security, but simply sending permissions-related e-mails to extranet users can be a big mistake and should be prevented by technological means.
Usually this is done by configuring people picker properties with stsadm.exe. It seems that the same method is used also with SharePoint 2010 as I could not found any related PowerShell commandlets. The stsadm properties can be set for each web application separately. But if you want to exclude some group and users from appearing in the people picker, you basically have to build a custom LDAP query which can in many cases be troublesome.
There is fortunately another method. A detailed MDSN blog post reveals the inner workings of the people picker. When querying the global catalog, the article states:
If the AD requires authentication, which is by default the case, SharePoint will authenticate using the context of the IIS application pool the SharePoint web application runs under.
And as the server administrators know, Active Directory permissions can be managed like any other NTFS permissions:
So to prevent some users or groups to show up in the people picker, simply remove read the permissions from the application pool account for the objects in question. It is best to do it by grouping such groups and accounts into a one or several organisational units (OU) and configure the permissions on the OU level.
So back to my original example, intranet and extranet in the same farm. In that case the application pools should have different accounts. The intranet application pool account should have read permissions only for the intranet users, and the extranet account should have read permissions for both intranet and extranet users. There can also be a case where the extranet users are located in a different AD forest with a forest trust. I assume my solution would be viable there as well, but that would require further testing.
Popularity: 4% [?]
The same trick can be used to prevent DL memberships to be synched to the user profile, and thus shown in My Site.
Hi,
In theory, your workaround makes sense, but…
When performing the above steps (moving the specific users to an OU and denying the App-Pool account ALL permissions including Read) i still see the specified account appearing in the People Picker.
So what is the time the People Picker will refresh or synchronize, so the actual users will disappear? For now, this proposed solution isn’t working.
Regards, Roberto
Thanks for your comments! Roberto: according to my knowledge, the pepole picker sends LDAP queries to Global Catalog, so the users should disappear when the Global Catalog refreshes its data. And that should happen quite fast. In my tests the proposed solution works fine, so it is hard to comment without specific knowledge about your setup. A good way to test the permissions is to run dsa.msc as app pool account and see if the OU is inaccessible.
This would of been great is I wasnt using a LDAP to my AD …. the stsadm commands dont seem to work either. The only other option is to write a script and dump it on the masterpage to remove [Active Directory] users.
Any other suggestions?
After all this years I found this article looking for the answer as well. Haven’t had a chance to verify the main part yet, but as for the comments, any redefining of the people picker might not seem to work if the site collection already contains users. Such users will be found no matter what. So to trully test such modification you have to make sure that the group isn’t already in the site users list (/_layouts/15/people.aspx?MembershipGroupId=0)
foscam fi9821w
Visit ao sex for your own free sexy chat experience!