strange claims account for cache users

Question

We are facing in our sharepoint farm "sporadic" access denied issue due to our cache accounts in a claims (with ADFS) setup.

cache reader & cache full access are configured as expected at webapp policy level & property bag one. moreover, we had them in the local administrator group.

end users get an access denied ("sorry, you don't have access to this page") due to underlying issue to resolve the cache account.

We are getting the "normal" cache message

SPRequest.GetMetadataForUrl: UserPrincipalName=i:0).w|s-1-5-21-2438373579-171170487-1684575306-43097, AppPrincipalName= ,bstrUrl=/sites/searchcenter/Cache Profiles ,METADATAFLAGS=59

and here I'm a little bit surprised about the form of the UPN, the SID is the one of the cache account, UPN attribute is filled in AD. (I would have expected to see the name resolved) and I'm especially surprised regard the ")" in the claims prefix which doesn't mean anything (at least for me). Does anybody know what it's refering to ?

Reference : How Claims encoding works in SharePoint

many thanks

sharepoint version : 15.0.4675.1000 / ADFS 3.0

Answer 1

Common Mistake when we configure the Object Cache for Claims based web App is that when we set the super user and super reader account then never put the claims in it. if you run this powershell $wa = Get-SPWebApplication -Identity "<WebApplication>" $wa.Properties["portalsuperuseraccount"] and compare it to the account in the Policy for web app.

Here is the best way to configure it without any issue. Instead of having to go manually set the Full Read and Full Control permissions using the web UI, I do everything in one shot.

foreach ($wa in Get-SPWebApplication)
{

    if($wa.UseClaimsAuthentication)
    {
        $superUser = "i:0#.w|sharepoint\sp_superuser"
        $superReader = "i:0#.w|sharepoint\sp_superreader"
        $fullPolicy = $wa.Policies.Add($superUser, $superUser) 
        $fullPolicy.PolicyRoleBindings.Add($wa.PolicyRoles.GetSpecialRole
([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl)) 
        $readPolicy = $wa.Policies.Add($superReader, $superReader) 
        $readPolicy.PolicyRoleBindings.Add($wa.PolicyRoles.GetSpecialRole
([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullRead)) 
        $wa.Properties["portalsuperuseraccount"] = $superUser; 
        $wa.Properties["portalsuperreaderaccount"] = $superReader;

        $wa.Update() 
    }
}

Setting Object Cache Accounts in SharePoint 2010

Answer 2

unfortunately it seemed to be a cache account issue, but after a deep look in the ULS, I finally understood the rootcause.

just before the HTTP 302 redirection to AccessDenied page, I've spotted this following stacktrace which show that the redirection to access denied page is due to an exception while trying to reach an SPList.

at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(HttpContext context)
at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex)
at Microsoft.SharePoint.Library.SPRequest.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)
at Microsoft.SharePoint.SPWeb.GetList(String strUrl)
at Microsoft.SharePoint.Publishing.CacheManager..ctor(SPSite site)
at Microsoft.SharePoint.Publishing.CacheManager.GetManager(SPSite site, Boolean useContextSite, Boolean allowContextSiteOptimization, Boolean refreshIfNoContext)
at Microsoft.SharePoint.Publishing.Navigation.NavigationHelpers.TryParseUrlUntilWeb(HttpUrlBuilder sourceUrl, SPSite site, CachedArea& cachedArea, Int32& segmentIndexAfterWeb)
at Microsoft.SharePoint.Publishing.Navigation.TaxonomyNavigation.TryParseFriendlyUrlInternal(SPSite site, HttpUrlBuilder inputUrl, NavigationTerm& friendlyUrlTerm, String[]& catalogUrlSegments, CachedArea& cachedAreaForUrl)
at Microsoft.SharePoint.Publishing.PublishingHttpModule.PostAuthorizeRequestHandler(Object sender, EventArgs e)

finally, I had a look during the searchcenter provisionning, and i saw that one list was failing to be provisionned due to problem with a custom template

Failed to find ListTemplate tag corresponding to ID "100", tried both onet.xml for site definition ID "50" language "1033" and global site definition. Operation failed. f36cfa9c-bedd-6070-72cb-9500e649d6d5

I will check the template tomorrow and check if it was exactly the rootcause, but it seems to be on the correct direction.