SharePoint – Users from trusted forest are not found with People Picker

Posted On February 5, 2020

Update 8/13/20 – Added info about RPC Endpoint Mapper Client Authentication, which can break people picker in forest trust scenarios.

Consider the following scenario:

  • You have your SharePoint servers in the “Contoso.com” domain.
  • You have the peoplepickersettings.searchactivedirectorydomains (SearchADForests) People Picker property configured properly to search trusted forest “fabrikam.net”.
  • You search for a user that exists in the trusted forest and get “No results found” in the People Picker control.
  • If you set your SharePoint logging to Verbose and reproduce the behavior, you see a sequence like this in the logs from the web-front-end (where “fabrikam.net” is the trusted forest):

02/22/2020 08:59:35.88 w3wp.exe (-0x08E8) 0x17DC SharePoint Foundation Performance ftq1 Verbose SearchFromGC name = fabrikam.net. start d77ac29e-c980-d0c3-2e7c-c62587f91b01

02/22/2020 08:59:36.75 w3wp.exe (-0x08E8) 0x17DC SharePoint Foundation Performance ftq4 Verbose GetAccountNameFromSid “0x010500000000000515000000570148645227CB7F544C536EBBFF1C00” start d77ac29e-c980-d0c3-2e7c-c62587f91b01

02/22/2020 08:59:38.92 w3wp.exe (-0x08E8) 0x17DC SharePoint Foundation Performance ftq5 Verbose GetAccountNameFromSid “0x010500000000000515000000570148645227CB7F544C536EBBFF1C00” returned. returnValue=False d77ac29e-c980-d0c3-2e7c-c62587f91b01

02/22/2020 08:59:38.92 w3wp.exe (-0x08E8) 0x17DC SharePoint Foundation Performance ftq2 Verbose SearchFromGC name = fabrikam.net. returned.
Result count = 0 d77ac29e-c980-d0c3-2e7c-c62587f91b01

 

If you take a network trace (Network Monitor, Wireshark, etc) trace from the SharePoint web-front-end while reproducing the problem, the network traffic shows that the proper user information was successfully returned by the LDAP queries, yet People Picker does not show the results.

 

Cause:

Security Identifier (SID) resolution failed.

People Picker is a two-step process:

1. Use an LDAP query to find the user information, including their SID.

2. Take that SID and then resolve it back to the users account name.

 

You can tell that the SID resolution step failed from the above ULS log because GetAccountNameFromSid shows a value for SID (which it got from the step 1 LDAP call), but returns “False” (returnValue=False), which means it was not able to resolve that SID.

To further confirm SID resolution is the problem, you can test SID resolution functionality outside of SharePoint with PowerShell. First use the users account name to get their SID, then use the second script to resolve that SID back to the account name.

 

#Name to SID:

$objUser = New-Object System.Security.Principal.NTAccount(“fabrikam\user1“)

$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])

$strSID.Value

 

Take the SID that is returned by the above script and paste it into PowerShell like the example below:

#SID to Name:

$objSID = New-Object System.Security.Principal.SecurityIdentifier(“S-1-5-21-1682440535-2144020306-1850952788-1900475“)

$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])

$objUser.Value

 

Running that should resolve the SID to the users account name. It should work on the SharePoint servers, and also the local domain controllers.

If it fails with the following error, that’s another clue that SID resolution, and possibly cross-forest RPC is broken:

“Exception calling “Translate” with “1” argument(s): “The trust relationship between the primary domain and the trusted domain failed.”

 

What’s the problem?

In a domain / forest trust scenario, the most common culprit for SID resolution failure is firewall configuration. However, it can also be caused by a Group Policy that can cause cross-forest RPC calls to fail.

Here’s a high-level explanation of how People Picker works in a trusted domain scenario, and what you would see if a firewall between the local and trusted DCs was causing the problem:

 

  • SharePoint web-front-end (WFE) makes LDAP call (SearchFromGC in the ULS log) directly to the remote / trusted forest domain controller (DC).
    • Usually this is ok. In a network trace, you see the remote DC return results, including the user you were looking for.
  • SharePoint WFE takes the SID from the LDAP results and makes a LsarLookupSids3 (GetAccountNameFromSID in the ULS log) call to the local forest DC.
  • The local DC needs to forward that SID resolution request to a trusted forest DC. It does that via RPC call.
  • Local DC connects to the RPC endpoint mapper using TCP port 135 on the trusted DC and asks for a dynamic port to make the RPC call on.
  • Trusted DC responds with a port number (could be any port) between 49152 and 65535 (for Windows Server 2008 and above). For example, it may tell the local DC to use port 49156.
  • Local DC tries to connect to (for example) port 49156 on the trusted DC, but that port is not open on the firewall, so those network packets just disappear.
    • Note: this could happen in both one-way and two-way forest trust scenarios.
  • Local DC keeps trying this port (this is where a big time / performance delay in People Picker may occur) and eventually gives up and responds to the SharePoint server that it could not find any results.
    • You can tell the SID failed to resolve in the ULS logs when GetAccountNameFromSID shows returnValue=False.

Solution for the more common firewall scenario:

We need to allow RPC traffic to succeed between the local forest domain controllers and the trusted forest domain controllers.

Most network admins are not comfortable with opening up the entire RPC port range on the firewall. In that case, we need to restrict the ports that are used for dynamic RPC port mapping, and then we need to allow those ports through the firewall between the local forest domain controllers and the trusted forest domain controllers.

See the following articles for information on how to do that:

How to configure a firewall for domains and trusts: http://support.microsoft.com/kb/179442

Restricting Active Directory replication traffic and client RPC traffic to a specific port: http://support.microsoft.com/kb/224196

How to configure RPC dynamic port allocation to work with firewalls: http://support.microsoft.com/kb/154596

 

A slightly rarer cause:

Check if group policy: “Computer Configuration | Administrative Templates | System | Remote Procedure Call | Enable RPC Endpoint Mapper Client Authentication” is applied to the local domain controllers. If so, it should be disabled and the domain controllers should be rebooted.  See this for details: https://support.microsoft.com/en-us/help/3073942/

When SharePoint calls the GetAccountNameFromSid method, it makes a LsarLookupSids3 API call to the Local domain controller (DC). The Local DC then forwards that request as an RPC call to the Trusted DC. If “EnableAuthEPResolution” is set to 1, that RPC call can fail.

Note: This group policy is implemented in Registry key: HKLM\Software\Policies\Microsoft\Windows NT\RPC\EnableAuthEPResolution. If it’s set to a “1”, that means the policy is enabled, and RPC calls to trusted forest DCs may fail.

One Comment

Add a Comment