SharePoint People picker stops resolving users from other domains with one-way trust after SP2 is installed


On a SharePoint site users from other domains do not get resolved from People Picker.
You receive the error message "No match found"

With installation of SP2, suddenly the People Picker would not resolve users from other domains even if one way trust was enabled.


The SharePoint farm was recently upgraded to SP2 and this changes the peoplepicker functionality to respect the peoplepicker-searchadforests property.

SP2 enforces the security features with respect to People Picker and the peoplepicker-searchadforests property.


You need to set the peoplepicker-searchadforests property for each one-way trusted domain from a Sharepoint perspective. The following command was delivered to have the peoplepicker lookup users in all domains that are in trust relationship with the sharepoint local domain 

stsadm -o setproperty -propertyname peoplepicker-searchadforests

Details to select people and groups from multiple forests are available in

Use this procedure to enable selection of people and groups from multiple forests or domains that have a one-way trust relationship from the farm.

Enable selection of people and groups from multiple forests

If you want to search from a one-way trusted forest or a one-way trusted domain, you must run the setapppassword operation.

On every front-end Web server on a farm, at a command prompt, type the following command, and then press ENTER:

STSADM.exe -o setapppassword -password key

The syntax for the setproperty operation is:

stsadm -o setproperty

   -propertyname peoplepicker-searchadforests

   -propertyvalue <valid list of forests or domains>

   [-url] <URL>


SharePoint is in xyz domain. Users from Contoso domain need to be resolved from People Picker. There is a one way trust between domain xyz (resource domain) and Contoso (user domain) where xyz trusts Contoso i.e. Contoso users can access xyz resources like SharePoint but not vice versa. 

We need to run

stsadm -o setproperty -url http://<server:port> -pn peoplepicker-searchadforests -pv ", contoso\<account>, <Password>;, contoso\<account>, <Password>"

Here the <LoginName>, <Password>" refers to an account with read permissions to the user domain.Typically it is a user account from the trusted(user) domain e.g. contoso\account.

If there are multiple domains from which users need to be resolved, they need to be entered in a single stsadm command and not separate.

e.g. If you have 2 domains contoso and abc from which users need to be resolved.

Correct way - single stsadm command
stsadm -o setproperty -url http://<server:port> -pn peoplepicker-searchadforests -pv ", contoso\<account>, <Password>;, contoso\<account>, <Password>;, abc\<account>, <Password>;, abc\<account>, <Password>"

Wrong way - multiple stsadm commands
stsadm -o setproperty -url http://<server:port> -pn peoplepicker-searchadforests -pv ", contoso\<account>, <Password>;, contoso\<account>, <Password>"
stsadm -o setproperty -url http://<server:port> -pn peoplepicker-searchadforests -pv ", abc\<account>, <Password>;, abc\<account>, <Password>"

The second stsadm command which sets the property for abc domain would toggle off the property for Contoso domain. As a result, users from Contoso domain will no longer be resolved from the People Picker

More Information

Peoplepicker checknames respects the peoplepicker-searchadforests property after SP2. This was not the case prior to SP2.
After SP2 you will not be able to lookup users in an external domain that is in a one-way trust relationship with the sharepoint local domain.

Prior to SP2 the Peoplepicker Checknames function did not respect the peoplepicker-searchadforests property. Users could be resolved from other domains, even if there was only a one way trust.

Checknames used LSAT and LDAP to search and display a match prior to build 12.0000.6520.5000 as described in KB976396:

Checknames could use “LSAT” (Local Security Authority Translation) methods to resolve names from Windows NT 4.0 domains and other Active Directory Domains connected to the SharePoint local domain.

Article ID: 2384424 - Last Review: Jul 18, 2012 - Revision: 1