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:
- 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.
- 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.
- 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.
- 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 Fpweb.net is the URL. This is how our command would then look:
Stsadm.exe –o setpropery –url https://Fpweb.net -pn peoplepicker-searchadforests –pv “domain:FpwebON.local;domain:FpwebOFF.local,FpwebOFF\PPicker,Start321
- <web app URL> https://Fpweb.net
- <TrustingdomainFQDN> FpwebON.local
- <TrusteddomainFQDN> FpwebOFF.local
- <FullUsername> FpwebOFF\PPicker
- <Password> Start321
- 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.
- 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.)
- 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.