Configuring People Picker in a One-Way Trust Environment

Hello there, readers! Today we’ll discuss a topic that is infamous for giving Admins problems: People Picker configuration, (particularly in One-Way Trust environments).

One reason that I think this particular topic causes issues is do the many caveats of People Picker and the lack of documentation or feedback provided during configuration. Nevertheless, after many trials and tribulations, I believe I have compiled a document that will navigate around these waters.

The People Picker control is used to find and “pick” users, groups and claims when assigning permissions in SharePoint 2013. It can be configured at the zone level for a farm with Stsadm.exe tool.

How to Configure People Picker in SharePoint 2013:

  1. First things first, we need a User account to be the “People Picker account”. The only real requirement of this account is to have Read privileges to the Active Directory membership on the Trusted Domain. CAVEAT: Do not use “special characters” such as * in your password for this account.
  1. Login to each Web Front End, (any server with SharePoint installed), and run the following on EACH server:

Stsadm.exe –o setapppassword –password <key>

Where <key> is the password you wish to set. The best practice for this would probably be to set it the same as the account password from step 1. CAVEAT: Must be the same on each server.

  1. While still on each Web Front End server, we need to check permissions on a registry setting. Open regedit and locate the following key:

HKLM > Software > Microsoft > Shared Tools > Web Server Extensions > 14.0 > Secure

The WSS_WPG account, (both local and domain if both apply), must have full access to this key.

  1. The next step can be done from any Web Front End server, (as long as it can communicate through the Trust which it should already be configured to do if the Trust is setup properly). Type the following command from command prompt:

Stsadm.exe –o setpropery –url https://<web app URL> -pn peoplepicker-searchadforests –pv  “domain:<TrustingdomainFQDN>;domain:<TrusteddomainFQDN>,<FullUsername>,<Password>


  • <web app URL> is the URL of the SharePoint Web Application
  • <TrustingdomainFQDN> is the full domain name of the Trusting Domain
  • <TrusteddomainFQDN> is the full domain name of the Trusted Domain
  • <FullUsername> is the domain/username of the User created in step 1.
  • <Password> is the password issued to the User you created in step 1.

Now this is quite a bit to chew on so I’ll also provide an example scenario to correlate with the above. In this example, FpwebON.local is our Trusting Domain and FpwebOFF.local is the Trusted Domain. Our Username/Password will be PPicker/Start321 and is the URL. This is how our command would then look:

Stsadm.exe –o setpropery –url -pn peoplepicker-searchadforests –pv  “domain:FpwebON.local;domain:FpwebOFF.local,FpwebOFF\PPicker,Start321


  • <web app URL>
  • <TrustingdomainFQDN> FpwebON.local
  • <TrusteddomainFQDN> FpwebOFF.local
  • <FullUsername> FpwebOFF\PPicker
  • <Password> Start321
  1. Now when you run the command, it will always tell you it is successful whether it truly is or not. To ensure the property was set correctly, verify by using the following command:

Stsadm.exe –o getproperty –pn peoplepicker-searchadforests –url <web app URL>

This command should return the appropriate domain names if successful.

If, for any reason, you need additional commands to restrict what people picker views by OU, etc; please visit this Microsoft blog.

  1. Run an IISReset. This step isn’t actually necessary, but is something I will usually do before testing the site to ensure I am seeing the newest rendered page. (I also use a browser set to not cache.)
  1. Test it! On the site itself.

I hope this article helps some folks out there. The same process can be used for any number of scenarios with or without Trusts, but the One-Way Trust is the one that people seem to have the most difficulty with. As always, thank you for reading.

2014-11-10T09:20:30+00:00 November 10th, 2014|


  1. Hardik November 17, 2014 at 9:05 am - Reply

    Hi Eric, Thanks for the great post. Our demographic is we are looking up EMEA user from Americas website. I followed the steps you suggested and i was able to lookup user from one-way trusted domain in EMEA. However I cannot add some specific users from EMEA AD to our website. Can you provide some thoughts here…

  2. Eric Lough January 27, 2015 at 9:18 am - Reply

    Hi Hardik and sorry for the late reply. Typically, if people picker is working at all which it sounds like it is, but still cannot locate particular users, you will have a permissions or DNS issue. Make sure the account you are using for People Picker has Read permissions to those Users or can at least traverse to those Users. Also, make sure you have the proper DNS forwarders for your trust so that they can actually contact those Users AD structure. If you can see other Users from that domain, then I would assume this to be permissions to those Users specifically, (or their OU). If you are using a specialized security software, this can also stop requests from moving between domains, so you may wish to contact the vendor of said software if this is the case in your environment. I hope this helps!

  3. Sreejitha February 24, 2015 at 1:28 pm - Reply

    Hey Eric,

    Thanks for the article. I have an https site, and I am trying the setproperty peoplepicker command you mentioned. I am getting the error that system cannot find path specified. I could not find any other article on how to deal with an https site. What could be the reason for this?


  4. Eric Lough February 24, 2015 at 1:36 pm - Reply

    Hello Sreejitha,

    This is most likely due to running the command outside of the directory stsadm lives in. (Whether the site is http or https should not matter for this function). Typically the proper directory is C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN however the 12 in the path can be a variety of numbers depending on what version of SharePoint you are using. You will know you have the correct directory if you can open it with Explorer and see stsadm. In the event you have trouble finding stsadm, do a windows search for it on your server and find the directory from there. Once you have the location, navigate to this directory in your command prompt before running the command and that should fix it.

    I hope this helps!

  5. Sreejitha February 24, 2015 at 5:03 pm - Reply

    Thanks again Eric for the prompt response. Path for stsadm is not the issue. The issue is this: My sharepoint application can be accessed via an external gateway (CISCO) from both inside and outside the network via an https url and only from inside the network via a different http url.

    This internal http url is http://192.168.etc etc. I got the error I first mentioned when I tried with the external gateway enabled url. I thought maybe issue is related to using the gateway so should try with the internal url. The command I wrote is this:-

    C:Windowssystem32>stsadm.exe -o setproperty -url http://192.168.etc.etc -pn peoplepicker-searchadforests -pv “domain:trustingdomainFQDN;domain:trusteddomainFQDN,trusteddomainFQDNFARM_Account,Farm_Account_Pwd”

    No luck with that either, this time I am getting:-

    The Server Administration Programs and WSS Web applications are not compatible (yeah this site SharePoint 2007 :-/ )

    When I searched this one out, it seems that url is the likely culprit (which does not help me much). Any new suggestions?

  6. Eric Lough February 25, 2015 at 9:19 am - Reply

    This does indeed seem to indicate a URL problem. I would make sure that you can ping any URL that you decide to use, and that the URL used is listed in Alternate Access Mappings for that site. I would further check to ensure both domains are reachable/pingable as well just to be safe.

  7. Sreejitha February 25, 2015 at 3:29 pm - Reply

    Hey Eric,

    Yes it looks like the url, and I am unable to figure it out. I see that it is an optional parameter for this command, so if I skip the url part, would people picker search the required domain for every application?

    Thanks so much for your help thus far.


  8. Eric Lough February 25, 2015 at 4:05 pm - Reply

    I have never attempted it without the URL parameter, so I couldn’t really recommend that as a workaround. I would definitely look into the Alternate Access Mapping of the site in Central Administration and compare it to the url parameter you are using. The URL should be listed.

  9. Swanl March 10, 2015 at 11:07 pm - Reply

    I am confused.
    which domain in which you referred as trusted domain and trusting domain have SharePoint installed.


  10. Eric Lough March 11, 2015 at 9:21 am - Reply

    Hello Swanl,

    In this scenario, the trusting domain is the “side” SharePoint is installed in. This would be done so that you can login to your SharePoint environment with logins from the trusted domain.

  11. Gosia November 3, 2015 at 9:00 am - Reply

    This worked great! thanks!

Leave A Comment