SharePoint People Picker Hidden Fact

Over the past few years we have seen greater traction in the Extranet game for SharePoint. With extranets there are greater security implications that come to mind, but one that seems to come up more than most is authentication. For those that are debating on having your SharePoint extranet environment live in a DMZ domain that trusts your internal corporate domain, but your corporate domain doesn’t trust the DMZ domain (otherwise known as a one-way trust, and the way you should do it if you are having multiple AD domains involved) you will learn to have a love/hate relationship with the people picker.

Now there are a lot of different articles and blogs about the people picker and one-way trusts, but I wanted to bring together a lot of that information in one place. First, you will need to identify an account in your corporate domain that SharePoint can use to lookup users. This account really just needs to have read rights to the domain, nothing special here. Then on EVERY SharePoint server you will need to run a command that sets an encryption key, for which all of the servers need to have the SAME key set. In order to set this, I still use STSADM like this:

stsadm -o setapppassword -password Th!s1saPwd

Simple enough, but make sure that you have this on ALL machines and document this as you’ll need it if you ever add a new server to the farm. The fun part about this command is it writes the encryption key into the registry which your application pool accounts need access to in order to work properly. To give credit where credit is due, the only place I could find reference to this online was Steve Schofield’s blog here. The key lives at:

HKLM\MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure

What I would recommend so that you don’t have to worry about the permissions on this key after you verify / set the permissions for the first time is set the local WSS_WPG group with read rights to that key. The WSS_WPG local server group gets auto populated with all application pool accounts through SharePoint, so your permissions should be taken care of.

Now that we have that straight, it’s time to set the lookup from the DMZ domain to the corporate domain using STSADM again and the peoplepicker-searchadforests property where you can find a good amount of information on TechNet here. My example looks something like this:

stsadm -o setproperty -url https://extranet.company.com -pn peoplepicker-searchadforests -pv “domain:corp.company.com,CORP\peoplepickerlookupuser,Th!s1san0therPwd”

You only have to run this command ONCE (and can specify multiple domains and forests if needed) for each web application that you want the lookup to happen from (potentially including Central Administration as well for site collection administrators). Generally I process an IISReset on each server after setting both of these commands to make sure nothing is cached and then it’s off to the races with setting permissions from a non-trusted domain.

Are you running into other people picker issues or solutions that you have run across? Let us know.