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.
