I was setting up trusted domain for the people picker in SharePoint 2010. I was able to get it to work on one environment but not the other. On the environment that wasn’t working, the steps to set it up were all successful. The people picker however could not resolve any username, including those in the current domain.
Every time the people picker failed to resolve the username, there was this error message in the ULS:
An exception occurred in AD claim provider when calling SPClaimProvider.FillSearch(): Requested registry access is not allowed..
This is then followed by another message:
Claims Search call failed. Error Message: Requested registry access is not allowed. Callstack:
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
at Microsoft.SharePoint.Administration.SPCredentialManager.<>c__DisplayClass1.<get_ApplicationCredentialKey>b__0()…….
The first message also appears in the Event Viewer.
The messages clearly indicate that something did not have access to read something from the Registry. I downloaded Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645) from MS Sysinternals, which is an incredible tool that allows us to monitor all access to the Registry (among other things).
Run this tool and set it to Show Registry Activity only, and filter it down to Process = “w3wp.exe” and Result = “access denied” as below:
This will quickly show that the problem occurs when the w3wmp.exe process tries to read the Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure. This is where the apppassword (set by the stsadm command) is stored.
Double click the failing entry in Process Monitor and you will see that the user who’s trying to read the Registry above is the app pool account of the SharePoint web app.
Check the permission of this Registry key and you will see that the following groups have read access:
- System
- Network Service
- WSS_Restricted_WPG_V4
- Local Administrators group
I added the app pool account to the local Administrators group, reset IIS and everything started to work. I checked the other environment where it was working and indeed the app pool account was added to the local Administrators group. (Probably better to add the app pool account to the WSS_Restricted_WPG_V4 group though).
Not sure why the app pool account was not setup properly by default or if I missed a required config step – but anyway it’s working now and I’m happy :).
Bernado Nguyen-Hoan's Blog - Coding Stories from an IT Mercenary 
Pingback: The user does not exist or is not unique « onefootinthecloud
I just ran into this same scenario on a single-server farm that I’ve built for a developer (I’m a systems guy). Anyway, I wanted to ask… Are you doing something funny with local machine service accounts? Or, when you configured “peoplepicker-searchadforests”, did you set a username and password for the local domain in addition to other ones?
-PlateSpinner
Hi PlateSpinner,
No, I did not have to do anything ‘funny’ with the local service accounts (except for what described in this post). I only had to specify the username/password of the account to access the other domain, not of the local service account.
Pingback: Process Monitor « SharePoint Dragons
Hi Bernado,
nice work, did help me a lot !
Best practice for the solution would be to give read permissions for this key to the local group “WSS_WPG” – this group usually contains all the app pool accounts.
Hi Bernado,
Just wanted to say thanks for posting this – that Process Monitor tool is great.
btw, I added the app pool account to the “WSS_Restricted_WPG_V4” group, and it worked/works
This error happened to me, even though my system had been working before. I was getting the registry access denied error, but the event log didn’t tell me which registry was causing the error. This blog on how to use the process monitor tool to tell you which registry entry was getting access denied was the key to resolving my issue. In fact, it was the same registry key you mentioned in your blog. I even found a bunch of other non-critical registry keys that SharePoint was trying to access, as well. Thanks, again for this posting!
Thank you. Very helpful. It applies also to Sharepoint 2013 (15 folder of course)
I really appreciate the run down on how to use Processor Monitor and not just saying “Add the account here”
Also a valid solution for SharePoint 2016. For me, the Web App account only needs to be added to ‘WSS_Restricted_WPG_V4’ If your Web App ‘SearchActiveDirectoryDomains’ settings specify an Account/Password. This makes sense, because then the service account running the Web App needs to be able to access that stored password.