Does i:0#.w| part matter in superuser or superreader username on web app properties?

Question

I'm trying to figure out continuous "Unable to write SPDistributedCache call usage entry." error in ULS and some instructions like this suggests that issue might be with super accounts having incorrect username.

The user accounts used for superreader and superuser accounts are currently set in domain\superuser and domain\superreader format to web app's portalsuperreaderaccount and portalsuperuseraccount properties.

But I'm wondering if they would need to be updated into i:0#.w|domain\username format instead to fix issues?

As far as I know these both formats should resolve fine but thinking if this still could be an issue.

Answer 1

No it doesn't. The i:0#.w| part is an internal signature for SharePoint that identifies the authentication type as claims rather than the soon to be deprecated classic authentication.

Update

Usually this isn’t a problem, but if you have the object cache accounts without the initial claims signature all users will get access denied to the object cache (which you see in the ULS logs). There may be a number of reasons why this happened, but there are ways to fix it.

According to Scott on MSFT in his post SharePoint – PowerShell to configure SuperUser and SuperReader accounts on all Web Apps, this cause error:

What you will see is that there is a check for Claims Authentication.

The reason for this is that you will notice that when User rights are granted in Central Admin via User Policy for each Web App you will see that the Claims identifier ("i:0#.w|") is shown (Yes, even in SharePoint 2013).

If you do not provide the claims identifier and you implement Object cache all users will receive "Access Denied" prompts and will be denied regardless of how many times they try to login.

The way to solve it is to update your webapps that uses claims, but is missing the initial claims signature. For this you use PowerShell:

Add-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue
####SET ACCOUNT NAMES (Replace Domain and UserName)
#SUPER USER ACCOUNT – Use your own Account (NB: NOT A SHAREPOINT ADMIN)
$sOrigUser= "blue\SP_SuperUser"
$sUserName = "SP_SuperUser"
#SUPER READER ACCOUNT – Use your own Account (NB: NOT A SHAREPOINT ADMIN)
$sOrigRead = "blue\SP_SuperRead"
$sReadName = "SP_SuperRead"

$apps = get-spwebapplication 
foreach ($app in $apps) {
   #DISPLAY THE URL IT IS BUSY WITH
   $app.Url
   if ($app.UseClaimsAuthentication -eq $true)
   {
    # IF CLAIMS THEN SET THE IDENTIFIER
    $sUser = "i:0#.w|" + $sOrigUser
    $sRead = "i:0#.w|" + $sOrigRead
   }
   else
   {
   # CLASSIC AUTH USED
     $sUser = $sOrigUser
     $sRead = $sOrigRead
   }
   
   # ADD THE SUPER USER ACC – FULL CONTROL (Required for writing the Cache)
   $policy = $app.Policies.Add($sUser, $sUserName)
   $policyRole = $app.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl) 
   $policy.PolicyRoleBindings.Add($policyRole)
   $app.Properties["portalsuperuseraccount"] = $sUser
   $app.Update()
   # ADD THE SUPER READER ACC – READ ONLY
   $policy = $app.Policies.Add($sRead, $sReadName)
   $policyRole = $app.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullRead) 
   $policy.PolicyRoleBindings.Add($policyRole)
   $app.Properties["portalsuperreaderaccount"] = $sRead
   $app.Update()
 }

Hopefully you and I have a better understanding of what tha claims signature does, and doesn’t do.

Answer 2

Yes, it does matter. Especially in the Object Cache Configuration( Super User & Super Reader).If your webapplication configured as claims based authentication then this is import piece.

• Make Sure your Account in Web Application Properties( Via PowerShell) have the same format i.e cliams|domain\username, as they are in the Web Application's Policy( from Central admin > policy for web application).

If it mismatch, you will get the access denied error.