Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

SharePoint: People-Picker and Active Directory Part 2

Leave a comment

SharePoint 2007 SharePoint 2010 SharePoint 2013

[UPDATED on 12/04/2012]

First, I’d like to thank all the people who took time to send me their feedbacks, comments or questions regarding my first post about the People Picker in SharePoint.

Now let’s go for the second part, covering the following topics:

  • Additional filtering capabilities and control
  • Detailed configuration for each AD scenario
  • how people picker is related to authentication and profile import SharePoint Server only)
  • Guidance to optimize people-picker

Once again, it is important to remind you that these posts are covering people picker used exclusively with Windows-based authentication provider/Classic Mode.

Additional Filtering Capabilities and Control


This setting allows to specify extra criteria to the existing built-in search query. Be very careful when you use this option because the results can be sometimes unexpected or there are no results at all. Moreover, if you target multiple forests or domains, the same criteria will be applied to all targets! It is highly recommended to test and validate your query using LDP.exe, Active Directory Users & Computer “Query” function or any other LDAP-client in order to make sure it behaves as expected.

A real-life usage can be the following: your organization is also working with MS Exchange and you wish to excluded from the people-picker people also hidden from address list. In this case, you can add this extra condition:

  • (!msExchHideFromAddressLists=TRUE)


As far as I could experience it, this one’s behavior is rather funny: it will query the target AD as configured by the administrator and then refine the results by comparing them to the users already present in the site collection. So using this option will not really increase query performance since it performs queries against the configured AD anyway and then performs additional operations afterwards.

Typically, it would be used in site collections where membership is highly controlled or in hosting environments.


This setting control the timeout option for a query operation against a given target AD. So it is not an overall timeout but a per-target timeout value. So to calculate the maximum time it would take to perform a people picker query, you have to multiple the value set by the number of forests/domains specified.

Increasing the timeout obviously makes sense in a scenario’s where target domain controllers are located behind low-bandwidth/high-latency network connections OR if they are particularly busy (for example, also intensively used by MS Exchange and MS Exchange Clients such as Outlook)


This setting is to be primarily used by hosting companies wishing to 1) place all users from a given customer in a given AD container (organizational unit for example) 2) make a site collection or a web application available to that customer and 3) Restricting what users from that customer can see in the people picker to the users present in that container.

The parameter passed in the distinguished name of the organizational unit (example: OU=contoso,ou=customers,dc=litware,dc=local). The parameter is used as the start location for a search (the “base path” in correct terms). if this setting is no set, the base path is always the root of a forest or domain. With the parameter set, it will start at the level of the container specified.

Since the distinguished name contains the name of the domain where the container exists, is does not make a lot of sense to combine this setting with the query of multiple forests/domains since only one will contain the container specified. From my own experience, I can tell that using this paremter with multiple forests/domains equals to shooting yourself in the foot.


Not really appropriately named, this parameter will do the same as the previous setting but will only apply to Farm administrators. Still mostly applicable to hosting companies, it will usually prevent administrators to be restricted when then want to use the people picker.

Detailed Configuration for each AD Scenario

OK, my basic assumptions are always the following:

  • The SharePoint server performing people picker queries is always member of the domain “avatar.local”
  • The application pool identity running used by the sharepoint web application is wheterh “Local System”, “Network Service” or a domain account of “avatar.local”

“Simple” 2-way trust

  • Trust type: external or forest
  • Trust direction: 2-way

Possible configurations to search “watertribes.local” exclusively

  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:watertribes.local”

Possible configurations to search both “avatar.local” and “watertribes.local”

  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;domain:watertribes.local”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;forest:watertribes.local”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;domain:watertribes.local”

“Simple” 1-way trust

  • Trust type: external or forest
  • Trust direction: 1-way


The configurations are identical as for the first scenario except that to search “watertribes.local”, the people picker must provide credentials explicitly

To search “watertribes.local” exclusively

  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local,WATERTRIBESKATARA,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:watertribes.local,WATERTRIBESKATARA,PASSWORD”

To search both “avatar.local” and “watertribes.local”

  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local,WATERTRIBESKATARA,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;domain:watertribes.local,WATERTRIBESKATARA,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;forest:watertribes.local,WATERTRIBESKATARA,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;domain:watertribes.local,WATERTRIBESKATARA,PASSWORD”

Multiple 2-way trusts

  • Trust type: external or forest
  • Trust direction: 2-way


The possible configurations are almost identical to the first scenario except that “firenation.local” must be appended to the list of forest/domains. Examples:

  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local,WATERTRIBESKATARA,PASSWORD;forest:firenation.local,FIRENATIONZUKO,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local,WATERTRIBESKATARA,PASSWORD;forest:firenation.local,FIRENATIONZUKO,PASSWORD”

Note: some people might say that it is not wise to trust the fire nation but since Zuko is the new fire lord, it should not be a problem anymore.

Multiple 1-way trusts

  • Trust type: external or forest
  • Trust direction: 1-way

The configuration is the same as above except that explicit credentials must be provided for each trusted forest or domain to be queried:

  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local,forest:firenation.local”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local;forest:firenation.local”

Once again, depending on the type of query you wish to use (LDAP or GC), specify domain or forest as prefix)

Forest 2-way trusts

  • Trust type: forest. By transitivity North will be trusted too
  • Trust direction: 1-way

In this special case, let’s say that you want the people picker to query both “watertribes.local” and its child domain “North.watertribes.local”. The easiest and most efficient way to proceed is to use the “forest” prefix, this will force the people picker to use the global catalog service to query the whole “watertribe.local” forest, thus including its child domain but this using a single connection and a single query.

  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local”

Finally, if the trust was one-way, simply provide the credentials:

  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local,WATERTRIBESKATARA,PASSWORD”

Note: if you used the “domain” prefix instead, the query would be limoited to the domain “watertribes.local”

How People Picker is Related to Authentication/Authorization and Profile Import (SharePoint Server only)

I’ve often met people who were convinced that the people picker is impacted by the configuration applied to the Profile Import component present in SharePoint Server SSP’s/User Profile Service Application. This is not the case.

While the people picker is used to define permissions or other element by using AD security principals (users and groups) and storing them in content databases, the profile import is “only” responsible for updating informational properties of those users or groups when they already exist in content databases. The profile import will not “touch” any security-related information or change the way people picker behaves when querying AD.

On the other hand, the people picker is directly linked to the authentication or should I say authorization (to be accurate) mechanism in WSS/MOSS because one a user is authenticated by Windows/IIS, SharePoint will then verify if the authenticated user is authorized to access the page requested. The information being used for that purpose being the user’s token (SID, group membership…).

Another important thing is the relationship between the trust type and the authentication protocol used by Windows. In order to use Kerberos, a forest trust must be in place. On the other hand, an “external” trust (domain-based) will always imply NTLM authentication.

Guidance to optimize people-picker

From a purely SharePoint perspective, there is little you can do to optimize people picker:

  • Reduce as much as possible the number of domain or forest to query. If you target multiple domains from the same forest, considered targeting the whole forest instead in a single query
  • Do not use extra criteria (customadsearchfilter) or extra processing (onlysearchwithinsitecollection) if possible
  • Try not to mix queries against very responsive AD’s and less responsive AD’s (not easy I know) because then the less responsive will impact the whole query process

In combination with the AD administrator, you can improve the performances and availability by:

  • Placing a DC of the target domain “close to” the SharePoint server, and put in place the a&appropriate AD topology configuration. Ideally the SharePoint server and the target DC should “see” each other as member of the same Active Directory site even though they do not belong to the same forest (this means naming the sites identically in the resource and the user forests). Generally speaking, low-latency matters more than high-bandwidth in the perception of responsiveness
  • Making sure the targeted DC’s are available and responsive (not too busy with other LDAP-oriented operations or near capacity in general)
  • It’s a detail, but since DNS resolution is used to reach DC’s, make sure it is also efficient and why not, ideally cached (not too short but not too long, in case of failover to another DC). Of course, the SharePoint server MUST be able to resolves all AD-related domains appropriately. Use suffixes search order wisely and only if necessary

Note: the recommendations above will also be beneficial to authentication mechanisms used by Windows/IIS

Additional information’s

Due to the massive feedback of non-infrastructure readers (developers…) or people with limited AD skills, I have planned a third post over detailed troubleshooting.

Happy people-picking!



Author: Marc Lognoul

Relentless cloud professional. Restless rider. Happy husband. Proud father. Opinions are my own.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s