Partager via

SharePoint People Picker is Not Resolving Users in One-Way Trust

  • Article

Scenario:

You have your SharePoint farm in a domain, e.g. ahmedamin.local, and you have one-way trust with another domain, e.g. contoso.local. Hereafter, you followed this article and configured your People Picker to retrieve the users from the trusted domain contoso.local. However, while searching for any user from the trusted domain contoso.local, you get no results.

 

Analysis:

While using the People Picker to resolve the user from the trusted domain, you collected SharePoint VerboseEx logs which showed the below error:

 09/18/2017 07:18:47.02 w3wp.exe (0x1120) 0x2610 SharePoint Foundation Performance ftq1 Verbose SearchFromGC name = contoso.local. start  7e781a9e-5196-5016-c835-9eeac8346420

09/18/2017 07:18:47.02 w3wp.exe (0x1120) 0x2610 SharePoint Foundation General ardb5 Verbose SearchFromGC query = (|(&(objectCategory=person)(|(anr=contoso*)(SamAccountName=contoso*)))(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)(|(anr=contoso*)(SamAccountName=contoso*)))) 7e781a9e-5196-5016-c835-9eeac8346420

09/18/2017 07:18:58.32 w3wp.exe (0x1120) 0x2610 SharePoint Foundation Performance ftq3 Verbose SearchFromGC name = contoso.local. Error Message: Access is denied 7e781a9e-5196-5016-c835-9eeac8346420

09/18/2017 07:18:58.32 w3wp.exe (0x1120) 0x2610 SharePoint Foundation General 7fbh Verbose Exception when search "contoso" from domain "contoso.local". Exception: "Access is denied", StackTrace: "   at Microsoft.SharePoint.Win32.SPNtDsApi32.SafeDirectoryServiceHandle.Bind(String domainControllerName, String dnsDomainName)     at Microsoft.SharePoint.Win32.SPNtDsApi32.TranslateUserName(String name, DS_NAME_FORMAT formatOffered, DS_NAME_FORMAT formatDesired)     at Microsoft.SharePoint.WebControls.PeopleEditor.SearchFromGC(SPActiveDirectoryDomain domain, String strFilter, String[] rgstrProp, Int32 nTimeout, Int32 nSizeLimit, SPUserCollection spUsers, ArrayList& rgResults)     at Microsoft.SharePoint.Utilities.SPUserUtility.SearchAgainstAD(String input, Boolean useUpnInResolve, SPActiveDirectoryDomain domainController, SPPrincipalType scopes, SPUserCollection usersContainer, Int32 maxCount, String customQuery, String customFilter, TimeSpan searchTimeout, Boolean& reachMaxCount)". 7e781a9e-5196-5016-c835-9eeac8346420

N.B., contoso.local is the trusted domain

 

As seen from the above ULS logs, this is failing with Access Denied error while contacting the trusted domain contoso.local. Specifically, this is failing while translating the returned usernames. Hence, if you collect network traces, you will find that SharePoint is sending LDAP query to the trusted domain which responds with the users. However, later SharePoint will try to contact the trusted domain again but with the SharePoint application pool account. As a result, this is going to fail with Access Denied error, as this is one-way trust and the SharePoint service account does not have permissions to access the trusted domain (contoso.local).

 

But why SharePoint is contacting the trusted domain with its service account, and not with the people picker configured account?! - In fact, this happens when you use the people picker property HideInactiveProfiles. So, what is this property?

 

HideInactiveProfiles is a people picker property that was introduced in SharePoint 2010 server (August 2012 CU) . This property was only released to handle the below scenario:

  • You are in the process of migrating your user accounts from domain A to domain B. Whereas, you have two way trust between the two domains.
  • You migrate the users but keep the same SIDs. Later, you disable the migrated accounts in the destination domain B.
  • When a SharePoint user uses people picker to search for any of the migrated users, the people picker will return the user from domain B although the user is disabled.
  • In fact this happens because the people picker is using the Windows API LookupAccountSid to resolve the returned users' SIDs to domain\user. However, this API does not consider if the returned users are disabled or not.
  • Hence, with this property HideInactiveProfiles, SharePoint is not going to use this API LookupAccountSid, but will use distinguishedName.
  • Normally, if you want to enable this property "HideInactiveProfiles", you have to run the below STSADM command.
 stsadm.exe -o setproperty -propertyname "HideInactiveProfiles" -propertyvalue "true"

N.B., the above property and value are case sensitive, and the command works for SharePoint 2013, and SharePoint 2016

 

However, unfortunately, this property "HideInactiveProfiles" is not supported with one-way trust.

 

Solution:

In order to fix this issue, verify first that the property HideInactiveProfiles is enabled in your farm by running the below command

 stsadm.exe -o getproperty -propertyname "HideInactiveProfiles"

 

If it's enabled, and you have one-way trust, then you will need to disable it by running the below command, and then restart IIS.

 stsadm.exe -o setproperty -propertyname "HideInactiveProfiles" -propertyvalue "false"

Comments

  • Anonymous
    April 03, 2018
    Nice post. Just what I needed.