Day 1: People-Picker: Behaviour and configuration across several domains.

Sometimes, People-Picker is a part very ignored when administrator is designing and developing the Sharepoint infrastructure... In fact, when Servers are in one domain and users in other this is a crucial task... Wrong setup would be a headache if domains don´t have bidirectional trusted relationship... But we must go step by step...

First thing: ¿What is People-Picker? People-Picker is the module of Sharepoint that allows administrators find and pick up domain users in order to give them several access rights to Sharepoint Site Collections...

In the this image you can see People-Picker...

Let´s take a look to default behaviour of People-Picker... How it works?

1. Admin site or other user with appropiate rights makes one query to People-Picker web control.
2. The web front server makes a DNS query to locate one Domain Controller that have Global Catalog Service.
3.  Once the DC is targeted, the server tries to connect it.. First connection is anonymous and returns extra information about conected DC.
4.  If AD requires autentification, Sharepoint uses IIS Application Pool Security Context of Web Front server that hosts the Web Application.
5.  The Web Front server sends one LDAP Global Catalog request to AD asking for matching results in the subtree for users/objects. The search criterion is the following:

• Users objects in 'name', 'displayName', 'cn', 'sn', 'SamAccountName', 'mail', ‘SMTP’ or 'proxyAddresses' attributes.
•  Group objects in 'name', 'displayName', 'cn', or 'SamAccountName' attibutes.

Once the process is finish People-Picker returns the results....

Let's start the adventure!!! Or how to setup the People-Picker...

When you have Sharepoint in different domain from the domain where you have the users we can find two scenarios:

1. Bidirectional trusted relationship between domains: User of domain A can be authenticated in domain B and viceversa. In this case, we don´t need to do anything...
2. Unidirectional trusted relationship between domains. One specified user of domain A is allowed to be authenticated in domain B but it is not valid backward case... So we must create one search user in every other domains. 

When the user has been created we must follow the following steps:

It´s very important to keep in mind there isn´t any powershell cmdlet to do this task... So we have to take a look to old stsadm.exe.

STEP 1: Run this command line in EVERY FRONT WEB SERVER:

STSADM.exe -o setapppassword -password <PASSWORD>

The search user and password for each domain is stored and encrypted in every front web server. All servers must have the same password established with this command. This task is at farm level.

STEP 2: Run the following commands ONLY IN ONE SERVER and they are at Web Application level:

STSADM.exe -o getproperty -url http://webapplication -pn peoplepicker-searchadforests

With this command, we collect all users established in People-Picker before... It´s very important that we must have all users and passwords because with the following command we are going to REPLACE all values. This means the following commands must include all values established before.

With this command we set to null the property. It´s not necessary but Microsoft recommends it:

stsadm.exe -o setproperty -url http://webapplication -pn peoplepicker-searchadforests -pv ""

Finally, the last command... It will configure the People-Picker correctly:

stsadm.exe -o setproperty -pn peoplepicker-searchadforests -pv forest:FOREST1,FOREST1\forest1user,UserPassword1;forest:FOREST2,FOREST2\forest2user,UserPassword2; forest:FOREST3,FOREST3\forest3user,UserPassword3 -url http://webapplication

NOTE: Every credential will be with the format DOMAIN/FOREST, USER, PASSWORD. Every set of values must be separated with the ";" character.

With this last command we finished the job. All that remains it´s test the sites of Web Application.

I hope you enjoy it!!!!