The Part 1 of this series talks about how People Picker works under the default configuration . In this post I will focus on what changes when we have SharePoint servers in the farm & principals ( users or groups ) belong to Different Active directory Domains & Forests .
Review & evaluate your current AD infrastructure to determine the existing trust relationships as this information would be critical to determine the behavior of People Picker & configuration required . If you need assistance to figure out the type of Trust or Transitivity , please refer to TechNet articles in References section
Querying Additional Forest or Domains
Scenario 1 : The SharePoint server belongs to a forest and/or domain that has 2-way trusts established with other forests or domain
The accounts of the users accessing SharePoint therefore belong to those trusted domains and since the trust is 2 way, the identity of the IIS application pool is also capable of authenticating against those trusted domains. Hence all domains and forests with a two-way trust relationship are available without any additional configuration steps as People Picker searches all two-way trusted forests and all two-way trusted domains by default .
Note : If there is a Forest wide Trust between two forests & users and/or resources belong to Child domains , still no configuration is required at the SharePoint level as Forest Trust creates a transitive trust relationship between every domain in both forests.
Scenario 2 : The SharePoint server belongs to a forest and/or domain that has 1-way trusts established with other forests or domain
In order to instruct SharePoint to query those trusted domain or forests we need to configure access to them by using the Stsadm command-line tool and selecting an account to use when accessing each forest or domain. Those credentials must be from the forest/domain to be queried or from a trusted domain, as long as it is allowed to authenticate and is not denied to logon remotely.
You can use a different account for each target domain or forest, or the same account for all domains and forests.
1. 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
Note: The account and password used to access each domain or forest is stored on each front-end Web server in the farm . This key is an encryption string that is used to encrypt the password for the account that is used to access the forest or domain . This encryption string must be the same for all servers in the farm, and unique for each server farm in a deployment with multiple farms.
2. On a front-end Web server, at a command prompt, type the following command, and then press ENTER,
STSADM.exe -o setproperty-propertyname peoplepicker-searchadforests -propertyvalue <Valid list of forests or domains> -url <URL of the Web application>
Note : You have to provide a valid list of forest/domains to be queried as well as the credentials to do so, this can be specified as below .
You can add multiple forests and or domains by listing multiple domains or forests in the format Forest/Domain:DnsName,LoginName,Password separated by semicolons. For e.g.
STSADM.exe -o setproperty-propertyname peoplepicker-searchadforests -propertyvalue“forest:Contoso.com,Contoso\User1,PasswordofUser1; domain:Fabrikam.com,Fabrikam\User2,PasswordofUser2” -url http://webapp
Note : You can omit the username and password if the application pool identity already has access to Target domain or forest, this would be the case where application pool identity is from the Trusted forest or domain itself .
Special Case : If the application pool identity is from the Target forest or Domain you would be able to resolve all users from target domain & forest but unable to resolve users from local SharePoint domain using the Browse option ( Checkname will still work **) & would require to specify the local Domain or Forest via the STSADM Command ,although without a username & password .
Key Observations & Considerations :
- In the above example notice how each block is separated by semi-colons and each element in a block is separated by comma.
- There is no space between peoplepicker and -searchadforests .
- Ensure that you have valid credentials for each forest/domain & passwords do not contain commas.
- If you need to query a forest the “forest” argument is specified, a forest-trust must be in place and/or if you need to query a domain the "domain" argument is specified , an external trust will suffice .
- If you configure a forest to be queried, it is not necessary to declare all or some child domains separately, they will be queried anyway .
- If “forest” is specified, the Global Catalog Service will be used to perform the query, if “Domain” is specified, the LDAP service will be used instead.
- The DC Locator process used as discussed in Default configuration is still applicable BUT is extended beyond the local forest boundaries. This means that the SharePoint servers must be able to resolve names of remote forests/domains domain controllers (SRV records and A records) , hence DNS must be correctly configured .
- Once you have configured peoplepicker for a web app & If you still wish to query the forest/domain SharePoint belongs to, you’ll have to add it as part of the parameter too.
- If you use “Selective authentication” or “SID Filtering” in order to restrict authentication through trusts, you must make sure that the IIS application pool identity is allowed to authenticate against the remote forest/domain it queries.
- If you add a cross Forest /Domain user to SharePoint Site there is an entry for the same in the Userinfo table for that web application . If later the trust is removed , you my still be able to Checkname that user as it already exists in SQL but cannot add it to the site & assign permissions etc .
To Remove the People Picker entry for a web Application , Run the STSADM command with blank property value i.e. Start & End double quotes with no space .
STSADM.exe -o setproperty-propertyname peoplepicker-searchadforests -propertyvalue“” -url http://webapp
Here is flow Chart which depicts the process flow of configuring People Picker for cross forest scenarios .
**Note: The people picker settings added by Stsadm peoplepicker-searchadforests command are honored by Browse feature while the checkname still would query all domains local & trusted & would be able to enumerate users provided the application pool identity has access to it . Once you add the People picker entry the ability to query local share point Domain /Forest is lost & that too needs to be added in the list of peoplepicker-searchadforests command.
Coming in Subsequent blogs other Peoplepicker configuration commands & troubleshooting Peoplepicker issues . Hang On!