Multi Forest/Cross Forest People Picker peoplepicker-searchadcustomquery
stsadm -help setproperty
Here's a list of the people picker properties that can be set ()
peoplepicker-activedirectorysearchtimeout
peoplepicker-distributionlistsearchdomains
peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode
peoplepicker-onlysearchwithinsitecollection
peoplepicker-searchadcustomquery
peoplepicker-searchadforests
peoplepicker-searchadforests
The people picker is flexible. First, all servers in the farm need to all be within 1 domain. Users in the forest that the server is in (resource forest) will automatically show up. Forests that have at least a one way trust to that forest can be "searched" for adding users using the stsadm command in the blog post from Venky. The post also explains the scenario where users have more than one account with the same name or objects which reference their account using the ms-ds-Source-Object-DN an object introduced in Windows 2003 R2. Venky's post goes into more detail. In this scenario you would need to maintain the population of that attribute to show where the "real" account is.
If it is not a two way trust then you will need to specify an account and password, which are encrypted and stored in the config database. The "peoplepicker-searchadforests" stsadm property allows you to search multiple values when picking users. With the command you can add multiple forests, domains, and accounts and even specific property searching.
If it is not a two way trust then you will need to specify an account from the user forest. The "peoplepicker-searchadforests" property allows you to search that forest. You can add multiple forests, domains, and accounts. Note: you do need to specify the user password if there's a one way trust, so the picker can look it up. If this is something that's required in your environment, you'll need to remember to maintain these usernames/passwords.
stsadm.exe -o setproperty -url http://server:port -pn "peoplepicker-searchadforests" -pv "forest:foo.corp.com;domain:bar.foo.corp.com", LoginName, P@ssword
Another example.
peoplepicker-searchadcustomquery
Allows the administrator to set the custom query that is sent to Active Directory.
For example, we could set it to
stsadm.exe -o setproperty -pn peoplepicker-searchadcustomquery -pv "(physicalDeliveryOfficeName={0})"
to search users by office name. Then I could type in 16/3077 to search who is in office 16/3077
Some valid input are
(SomeAdAttribute={0})
(SomeAdAttribute={0}*)
(SomeAdAttribute={0})(AnotherAdAttribute={0})
where SomeAdAttribute or AnotherAdAttribute are the names of some indexed attributes in AD.
If it was set, the custom query and the SharePoint built-in query will be sent together to AD to search people.
*Please use it with caution. If the property value is not a correct AD query, it will causes people picker totally broken. Also, if the searched attribute is not an indexed attribute in AD, it will make AD very slow.*
Note: The People Picker can only do wildcard searches for AD Windows group names. With any role provider other than the out of the box AD one the role provider lookup is specific to the entire name. For example if you have a group called "Readers" and you enter "Read" in the People Picker search dialog, it will not find your group; if you enter "Readers" it will. The role provider doesn’t provide a good way to do wildcard group search. See "Multiple Auth Providers" for more info. As well Steven Fowler in figuring out a custom membership provider has some great insights, another post People Picker and Custom Membership provider has dev insights on the GetUser() method.
peoplepicker-onlysearchwithinsitecollection
This will restrict the picker to only people and groups that are in the site collection.
peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode
This could be used to turn off the windows lookup on a non AD web app. From here you'd be leveraging the customer provider
peoplepicker-activedirectorysearchtimeout
Allows you to manage the active directory search timeout for lower bandwidth/ higher latency environments
peoplepicker-distributionlistsearchdomains
I'm not sure. I'll try to find out more. Note: DLs cannot be used for securing a SharePoint site/list,etc...
<update 4/11/07>
Great Quote from Jim in comments:
To use peoplepicker-searchadforests with credentials, which you need to specify if you don’t have two-way trusts in place, you must first set an encryption key:
stsadm.exe -o setapppassword -password key
This sets a key that will be used to encrypt/decrypt the password in the content database. Failure to do this results in a “command line error” message.
Secondly, the peoplepicker runs under the credentials of the application pool the site is running in. Make sure the application pool identity is a domain account with the right permissions.
Joel: This security key is REQUIRED to be run on every server with extended web apps (WFEs AND any index servers that have the WFE role) otherwise it will not work.
</update>
Related resources:
Determining the Global Deployment Approach
Global & Multi Farm Deployments
Basic and Advanced Deployment in a Nutshell
Security Blog Post on WSS and Office SharePoint Server 2007
SharePoint Manageability and Governance
(Great info on variations, WSS and MOSS language packs)
