SharePoint – People Picker: PeoplePickerSearchInMultipleForests

Posted On November 17, 2019

Today I’m writing about a little-known SharePoint People Picker property that can influence your People Picker results.

First some background:

In SharePoint 2010, People Picker searched all two-way trusted Active Directory (AD) forests by default.

In SharePoint 2013 and above, only the local forest is queried, but similar to Exchange, we also leverage the mxExchMasterAccountSid AD attribute (if it’s populated). Instead of querying all trusted forests, we’ll use the Global Catalog to search for all replicated users in the local forest by using msExchMasterAccountSid (if available).

How this works:

As always, People Picking is a two-step process.

1. Using an LDAP query, find AD user objects that match the value entered into the People Picker.

2. Using the SID value obtained from #1, call Windows API “LsarlookupSIDs3” to resolve the SID back to its account name. In the default configuration, the SID used for that resolution will be the value for mxExchMasterAccountSid, if it’s available. If not, it will use the value for objectSID.

Some problems:

This change in functionality can be beneficial for People Picker performance, and works fine in 90+% of environments, but can also cause undesirable behavior in a few scenarios (that I know of).

Scenario 1:

Account Forest / Resource forest. Consider the following environment:

Resource Forest: Contoso — SharePoint is in this forest.

Account Forest: Fabrikam — User accounts are in this forest.

SIDs from account forest (Fabrikam) have been synched to the msExchMasterAccountSid value of their respective accounts in the resource (Contoso) forest.

You try to add Fabrikam\user1 to SharePoint site permissions, but instead Contoso\user1 gets added.

Scenario 2:

Forest 1: Contoso
Forest 2: Fabrikam

Users from Fabrikam have “Contact” objects in the Contoso domain for Exchange purposes. The msExchMasterAccountSid value for those contact objects has been populated with the SID belonging to its respective user object from the Fabrikam domain.

You only want People Picker to find users in the Contoso domain, so you set the PeoplePickerSettings.SearchActiveDirectoryDomains (peoplepicker-searchadforests) web application property to only point to Contoso. However, when you search for a user, it shows results from both Contoso and Fabrikam.

Cause:

The cause for both of the above scenarios is the same.

As we found out in the “How this works” section, in its default configuration, People Picker will use the value of msExchMasterAccountSid if it’s available. If not, it will use the value for ObjectSID. The Windows API (LsarLookupSIDs3) that is used to resolve that SID has no information about which domain / forest it should resolve it from. All it knows is that it has a SID to resolve, and passes it to a domain controller in the local domain. It will always search the local forest first and will match on values for the ObjectSID, msExchMasterAccountSid, and SidHistory AD attributes. As soon as a single match is found, it quits looking.

 

For scenario 1, we get an ObjectSID value from the Fabrikam user object, but that gets matched to the msExchMasterAccountSid value for the Contoso user object, and therefore gets resolved as the Contoso account.

 

In Scenario 2, we get an msExchMasterAccountSid value from the Contoso contact object and resolve that to an ObjectSID value for the Fabrikam user object.

 

Avoid these potential problems:

You can easily go back to the SharePoint 2010 functionality where the “msExchMasterAccountSid” attribute is ignored, and all two-way trusted forests are queried. Like pretty much all People Picker settings, this is done per-web application.

 

#Update PeoplePickerSearchInMultipleForests, this will cause People Picker to ignore the “msExchMasterAccountSid” attribute.

$webapp = Get-SPWebApplication “https://teams.contoso.com”

$ws = $webapp.WebService

$ws.PeoplePickerSearchInMultipleForests = $True

$ws.update()

 

After setting that, you’ll want to evaluate the forests and domains you actually want to search and set them explicitly in the searchactivedirectorydomains People Picker property.

#Set web app to only search Contoso Forest

$wa = get-spwebapplication “https://teams.contoso.com”

$searchad = $wa.peoplepickersettings.searchactivedirectorydomains

$newdomain1 = new-object Microsoft.SharePoint.Administration.sppeoplepickersearchactivedirectorydomain

$newdomain1.domainname = “contoso.com”

$newdomain1.Isforest = $true

$searchad.add($newdomain1)

$wa.update()

 

Extra credit:

Lets say you want the default functionality (PeoplePickerSearchInMultipleForests = $false), but you want to leverage an attribute other than msExchMasterAccountSid. In that case, you can update the PeoplePickerSearchReplicatedMasterSIDPropertyName property to use whichever AD attribute you want. Example setting to use ObjectSID instead:

 

#Update PeoplePickerSearchReplicatedMasterSIDPropertyName to use ObjectSID

$webapp = Get-SPWebApplication “https://teams.contoso.com”

$ws = $webapp.WebService

$ws.PeoplePickerSearchReplicatedMasterSIDPropertyName = “objectSid”

$ws.update()

Important! If you set PeoplePickerSearchReplicatedMasterSIDPropertyName to use “objectSid”, you will then be able to resolve disabled Active Directory accounts, which is almost always an undesirable behavior. More info here.