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: 3% [?]