Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

We currently have SharePoint 2010 running a single server farm, single domain. We have it configured to authenticate using ADFS 2.0. Users have no problem authenticating, but we have noticed a very strange issue within Central Administration. SharePoint People Picker only returns user search results for one account. And let me be very clear. The issue is NOT that it returns a search result of one user, but that it returns all users properly, but only does this for a single account. It also appears the proper function of the People Picker is somehow restricted to that user's SID.

Example:

User A: People Picker Returns Results

User B: People Picker Does Not Return Results

If I log in to the SharePoint desktop via RDP as User A, and sign-in Central Administration as User A, People Picker works fine.

If I log in to the SharePoint desktop via RDP as User A, and sign-in Central Administration as User B, People Picker works fine (Somehow ???).

If I log in to the SharePoint desktop via RDP as User B, and sign-in Central Administration as User A, People Picker doesn't return any results at all.

If I log in to the SharePoint desktop via RDP as User B, and sign-in Central Administration as User B, People Picker doesn't return any results at all.

For some reason it seems it is only dependent on the user logged into the desktop, and only works for that one user. I've compared file, folder, and registry permissions between accounts using dumpsec, disabled group policy settings, compared group membership between accounts, and verified that the service accounts have permissions/credentials they supposedly need. I also checked that there were no filters affecting the people picker.

It is unclear which user accounts were initially used to setup and farm admin SharePoint as one of my coworkers was tasked with it. He supposedly changed the accounts afterward. I can say I’ve gone through and systematically given proper permissions to the account we appointed, but even that account doesn't receive search results from AD/ADFS through the People Picker.

What else might cause issues with the People Picker only working for one user? Does the People Picker rely on the User Profile (Synchronization) Services or Search services at all? Is there the possibility that the People Picker might function for one user, but fail for others without these services running?

I'm really grasping at straws here. I've not located any errors in the SharePoint or Windows Event Logs.

Thanks

UPDATE 1:

Auth Config:

Central Admin:  
Zone: Default  
Client Object Model Permission Requirement: Require Use Remote Interfaces permission - Enabled  
IIS Authentication Settings: Integrated Windows authentication - Enabled - NTLM  
Client Integration: Enable Client Integration? - Yes  

Site:  
Zone: Default  
Anonymous Access: Enable Anonymous Access - Disabled  
Client Object Model Permission Requirement: Require Use Remote Interfaces permission - Disabled  
Claims Authentication Types: Trusted Identity provider - ADFS  
Sign In Page URL: Default Sign In Page  
Client Integration: Enable Client Integration? - Yes  

Zone: Intranet  
Anonymous Access: Enable Anonymous Access - Disabled  
Client Object Model Permission Requirement: Require Use Remote Interfaces permission - Disabled  
Claims Authentication Types: Enable Windows Authentication - Enabled  
Integrated Windows Authentication - Enabled - NTLM  
Sign In Page URL: Default Sign In Page  
Client Integration: Enable Client Integration? - Yes  

UPDATE 2:

I was looking at the dev console in IE11 while messing with the PeoplePicker and the one user that still received search results, and in the middle of this, the PeoplePicker stopped working for this user...

UPDATE 3:

I reverted to a prior snapshot, and that user is now working again, but the original issue remains.

UPDATE 4:

I found this nifty powershell script and used it to compare SharePoint permissions of the user that works to mine, but there were no differences.

I am currently looking into the Microsoft SharePoint 2010 Administration Toolkit v2.0 to see if the Diagnostic tool might help.

UPDATE 5:

The diagnostic tool didn't really provide any other information. There aren't any errors or web traffic being generated due to the picker not even attempting a search. I found these powershell commands that sounded interesting. The Repair-SPManagedAccountDeployment command did help resolve an issue with the farm account and a password mismatch, but that did not fix the people picker issue. I've not attempted the other two commands yet.

Repair-SPManagedAccountDeployment

http://technet.microsoft.com/en-us/library/ff607627(v=office.14).aspx

Initialize-SPResourceSecurity

http://technet.microsoft.com/en-us/library/ff607583(v=office.14).aspx

Update-SPFarmEncryptionKey

http://technet.microsoft.com/en-us/library/ff607594(v=office.14).aspx

UPDATE 6:

I tried all three of the above commands with no luck. I also spent time reading through the following:

Minimum permissions for peoplepicker-searchadforests and 1-way trust

Peoplepicker returning with "No exact match was found" for a 1-way trust

http://blogs.msdn.com/b/rajank/archive/2009/09/01/all-you-want-to-know-about-people-picker-in-sharepoint-functionality-configuration-troubleshooting-part-1.aspx

http://blogs.msdn.com/b/rajank/archive/2009/09/20/all-you-want-to-know-about-people-picker-in-sharepoint-functionality-configuration-troubleshooting-part-2.aspx

http://msdn.microsoft.com/en-us/library/dd357076.aspx

http://msdn.microsoft.com/en-us/library/jj574647(v=office.12).aspx

http://support.microsoft.com/kb/320528/en-us

I'm not sure I need to use stsadm to reconfigure the peoplepicker as it IS currently functioning and returning searches for one user. I've previously attempted clearing the filters. That hasn't made a difference. And all examples I see involve multiple domains. We are not using multiple domains.

With regard to the encryption key, I tried running that with the 3rd command listed above. It tried to update for all (objects/credentials?) and complained for one after a few moments asking me to manually update. I've not found guidance on doing a manual update, and I'm not even sure this will make a difference. Again, it works for one of our users already.

Are we required to configure Active Directory to allow anonymous queries? I don't think we need to, but just thought I'd ask...

I also verified the permissions again for the WSS_WPG group in above mentioned registry setting. This was already checked and addressed in the below links:

http://technet.microsoft.com/en-us/library/cc678863(v=office.14).aspx

http://technet.microsoft.com/en-us/library/ff607583%28v=office.14%29.aspx

What permissions am I missing? Is it group policy? A registry setting security permission? A sharepoint permission? A SQL permission? I feel like I've gone through everything.

share|improve this question
    
Can you post your web application authentication provider configuration? Central Admin --> Manage Web Apps --> Click on Web Apps and in Ribbon select authentication provider settings. –  Jesus Shelby May 1 at 21:30
    
@jesus-shelby, I appreciate the reply. I've added the requested info. Thanks –  nightsky30 May 2 at 15:54

3 Answers 3

We have the same problem like in the past but we tried the following and it solved the problem

  1. First i would ask the user to use different computer if the error persist
  2. Check if the user is belong to the same forest domain.
  3. Delete and re-add user.
share|improve this answer
    
Thank you for the suggestion Supermode, but this is happening for all users except one. We even tried duplicating the user for which the peoplepicker works, but the new copied user did not work with the peoplepicker. –  nightsky30 Jul 1 at 21:55

another useful link that you can try http://joelblogs.co.uk/2011/06/02/sharepoint-2010-peoplepicker-not-finding-active-directory-users/

share|improve this answer
    
Thank you for the suggestion Supermode. I attempted using stsadm along with the get and set property flags to show and reset the UserAccountDirectoryPath. It appears that property was not set prior, and is not set now after running said commands. Running: $site = get-spsite <mysite>; $site.UserAccountDirectoryPath Returns nothing. –  nightsky30 Jul 2 at 16:09
up vote 0 down vote accepted

For anyone else wondering, here's the answer...

Back in May I ran gpresult against user A and user B. I compared both users and noticed one difference. I'm still not sure why, but user A had a single registry key group policy preference that was not applied like the rest of the users in the entire domain. Thus, user B had all the same group membership, SharePoint, SQL Server settings as user A, and still didn't function properly with the peoplepicker.

Due to security posture, it was recommended we set the "State" REG_DWORD value to 10000 (Hex), or 65536 (Dec) using group policy, restricting the following registry keys:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing

HKEY_USERS.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing

HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing

NOTE: SIDs S-1-5-19 and S-1-5-20 had different, apparently less restrictive "State" values of 23c00 (Hex) and 146432 (Dec)

I did some searching and found another post where someone had a seemingly similar issue with Webex malfunctioning after restricting the same key values.

Upon reverting the above three keys to "State" values of 23c00 (Hex) and 146432 (Dec) on the AD box through Group Policy Management, and forcing a group policy update, peoplepicker started working properly again for all users in SharePoint.

\:D/

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.