Set People Picker Restrictions

Important Note: This article describes how to modify the default SharePoint People Picker settings, which is an advanced subject. Therefore, we recommend that you thoroughly read and understand the following background articles before proceeding with this article:

Explanation of Problem Scenario

Brief Explanation

Your company policy is to create a dedicated Site Collection for each extranet site (for instance, your policy might be that each customer gets a dedicated extranet Site Collection - typically for enhanced security and privacy reasons). The problem is that the SharePoint People Picker defaults to globally searching across all directories (AD, FBA, etc.) that are associated with the web application the Site Collection belongs to. So, there is the potential that unwanted user names would display in the People Picker controls.

Complete Explanation with Screen Shots

By default, SharePoint's People search controls will search for users across Active Directory and any other forms-based authentication directories (such as the ASP.NET Membership Provider SQL database that ExCM uses for storing external user accounts) that are enabled for your extranet web application.

For many organizations, this out-of-the-box SharePoint behavior is fine because they configure their permissions for extranet users such that an extranet user will never have access to any of the People search controls and therefore will not be able to do a search across all the directories enabled for the extranet web application. On the other hand, internal users typically have permissions to use the People search controls and are trusted to make the appropriate selections with they search for either external or internal users by using People search.

For example, consider that an internal employee is working in the extranet site (a dedicated Site Collection in this case) that has been provisioned to collaborate with the personnel of ABC Corp, an important customer:

There are a number of actions that the internal employee (we'll use Brenda in this example) could take on the site that would require her to use one of the People search features to find and resolve a user account. Depending on the action, she might use just the People Editor Control or also the People and Groups Search Dialog Box. Here is what each one looks like:

If Brenda wants to invite another internal employee (we'll use John Adams in this example) to join the site, she might use SharePoint's "Share" feature to invite him to join the site and would find his account by typing "john" in the People Editor control:

At first, she might be surprised by the results that she sees when she types "john" into the People Editor control. The control returns three results and she needs to understand the difference between the three in order to make the correct choice. One thing she can do is hover over any of the three items to see if she can learn more about the differences:

If she takes the time to do this and she knows what she is looking at, she can determine the following:

She might also wonder why she sees at the top of the dialog an indication that the site has already been shared with John Adams? If she hovers over that name, she sees this:

This tells her that the site has already been shared with the external user "john@abccorp.com", but it is actually displaying his first and last name instead of his account name in the link.

So, now with all of this information, she can go ahead and safely select the first John Adams in the search because that user is the internal John Adams that she wants to invite to the site.

Well, john@xyzcorp is going to get a standard SharePoint email invitation to access the site:

And, John is going to be able to login to the site and will have Contribute permissions to the site.

People Editor Control	People and Groups Search Dialog Box
Or:

This could be a real problem for Brenda's company because they probably do not want a person from XYZ Corp to EVER have any access to the ABC Corp extranet site! What if ABC Corp and XYZ Corp are competitors?!

So, this briefly describes one of the problem scenarios that could occur when the People Picker is left configured as it comes out-of-the-box with SharePoint. Read on to learn about a possible solution.

Explanation of Solution and Configuration Steps

SharePoint provides a possible solution to the problem described above and it involves tweaking the user resolution settings for the People Editor control andor the search scope settings for the People and Groups Search Dialog Box. (See this page on TechNet for more details: https://technet.microsoft.com/en-us/library/gg602075.aspx).

ExCM makes it convenient for you to make these settings changes by providing a People Picker Restrictions page in Central Administration. Navigate there by going to Central Administration > General Application Settings > Extranet Collaboration Manager > People Picker Restrictions:

The use of this feature is very easy - just select the web application you would like to apply the restricted settings to, then check the box for either or both of the settings.

What may not be so easy (or clear) is what the end result will be if you make these changes to the out-of-the-box settings. To help you understand, let's walk through our previous example to see the effect of making one or both of these restrictions.

The expected result is that the People Picker search scope should be restricted to the members of the current Site Collection.

Searching for "john" only returns 1 result (as opposed to 3 results previously) and it is for the external user "john@abccorp.com". The reason his account is returned in the results is that he is already a member of this Site Collection:

So, the good news is that the People Picker search now EXCLUDES "john@xyzcorp.com" because he is not a member of this Site Collection. Overall, that is the primary goal we are trying to achieve in order to enhance security and privacy. Now, Brenda doesn't have to worry about inadvertently granting access to the site to someone who is not an ABC Corp employee.

But, what if she wants to add John Adams, the internal user, to the site? He no longer shows up in the People Picker search either.

There is good news and bad news when it comes to adding internal users from Active Directory to this site. The good news is that it can be done. The bad news is that Brenda must type the full domain name and user name of the AD user she wants to give permissions to the site - it will no longer find AD users via search.

So, to add the AD user John Adams, she would type "swtestjohn" and assuming that is John's full AD name, she could click Share and he would be invited to the site:

John would then receive the normal SharePoint email letting him know he has been given access to the site. Also, we can see that he shows up as having permissions in the site:

What happens if we enable the other People Picker restriction in Central Administration?:

This actually tightens down the People Picker even further. It causes the ability to share and resolve user names to be restricted to only existing members of the Site Collection. You can't even type the full domainuser name of an internal AD user and share the site with them:

With this setting enabled, you can no longer resolve users from any directory (AD, FBA, etc.), unless the user is already a member of the Site Collection.

This second restriction may have very few scenarios where it is useful, while the first restriction might be useful in a number of different scenarios.

In any event, the settings are there and are easy to turn on and off for testing purposes.

(Note: these settings become effective immediately and can be toggled on and off whenever needed. No IISReset should be required. However, you may have to empty the cache and cookies of the browser you are testing with as an end user.)