"Access denied" for newly-created AD accounts, not showing up in People Picker

For the last week, we've been experiencing a problem where certain user accounts have not been able to access our SharePoint 2010 site.  They have been presented with an Access Denied message, wrapped in the usual SharePoint error template.  The affected accounts were no different to similar accounts that did work (such as my own).

I trawled the SharePoint error logs and found the following.


Name=Request (GET:http://SP2010)
Begin Query the AD to get the user email and display name.
End Query the AD to get the user email and display name.

Access denied.  You do not have permission to perform this action or access this resource.
Leaving Monitored Scope (GetFileAndMetaInfo). Execution Time=53.0181908594528
Leaving Monitored Scope (GetWebPartPageContent). Execution Time=53.1897210399646
Leaving Monitored Scope (PostResolveRequestCacheHandler). Execution Time=55.7009340572615
System.Runtime.InteropServices.COMException: Access denied.  You do not have permission to perform this action or access this resource.    at Microsoft.SharePoint.Library.SPRequestInternalClass.GetFileAndMetaInfo(String bstrUrl, Byte bPageView, Byte bPageMode, Byte bGetBuildDependencySet, String bstrCurrentFolderUrl, Int32 iRequestVersion, Boolean& pbCanCustomizePages, Boolean& pbCanPersonalizeWebParts, Boolean& pbCanAddDeleteWebParts, Boolean& pbGhostedDocument, Boolean& pbDefaultToPersonal, Boolean& pbIsWebWelcomePage, String& pbstrSiteRoot, Guid& pgSiteId, UInt32& pdwVersion, String& pbstrTimeLastModified, String& pbstrContent, Byte& pVerGhostedSetupPath, UInt32& pdwPartCount, Object& pvarMetaData, Object& pvarMultipleMeetingDoclibRootFolders, String& pbstrRedirectUrl, Boolean& pbObject...
...IsList, Guid& pgListId, UInt32& pdwItemId, Int64& pllListFlags, Boolean& pbAccessDenied, Guid& pgDocid, Byte& piLevel, UInt64& ppermMask, Object& pvarBuildDependencySet, UInt32& pdwNumBuildDependencies, Object& pvarBuildDependencies, String& pbstrFolderUrl, String& pbstrContentTypeOrder)     at Microsoft.SharePoint.Library.SPRequest.GetFileAndMetaInfo(String bstrUrl, Byte bPageView, Byte bPageMode, Byte bGetBuildDependencySet, String bstrCurrentFolderUrl, Int32 iRequestVersion, Boolean& pbCanCustomizePages, Boolean& pbCanPersonalizeWebParts, Boolean& pbCanAddDeleteWebParts, Boolean& pbGhostedDocument, Boolean& pbDefaultToPersonal, Boolean& pbIsWebWelcomePage, String& pbstrSiteRoot, Guid& pgSiteId, UInt32& pdwVersion, String& pbstrTimeLastModified, String& pbstrContent, Byte& pVerGhostedSet...
...upPath, UInt32& pdwPartCount, Object& pvarMetaData, Object& pvarMultipleMeetingDoclibRootFolders, String& pbstrRedirectUrl, Boolean& pbObjectIsList, Guid& pgListId, UInt32& pdwItemId, Int64& pllListFlags, Boolean& pbAccessDenied, Guid& pgDocid, Byte& piLevel, UInt64& ppermMask, Object& pvarBuildDependencySet, UInt32& pdwNumBuildDependencies, Object& pvarBuildDependencies, String& pbstrFolderUrl, String& pbstrContentTypeOrder)

I found only one link online which was relevant to this - http://sharepoint.stackexchange.com/questions/39243/you-do-not-have-permission-to-perform-this-action-or-access-this-resource-nativ.  It suggested that I perform an stsadm command to remove a setting that may have been applied.

Then I remembered.  We had been looking into the idea of restricting the people picker to only show AD accounts within a certain domain.  I had passed this on to another SharePoint engineer to look into, and he must have carried out a command with this in mind.  However, documentation on this command is limited, and it may have had a side effect.

So, to test this theory, I reset the field using stsadm:


stsadm -o setsiteuseraccountdirectorypath -url http://sp2010 -path ""

Sure enough, as soon as I completed this command, the affected accounts could now access our SharePoint site.