This is due to AllowLocalAccount
requiring Windows authentication (Classic auth). As the default for SharePoint 2013 and above uses Claims authentication by default, the code path to enable this setting is ignored. On the SPUtility.ResolvePrincipalInternal
method (there are other methods that resolve accounts as well, but they're very similar), we see:
bool flag2 = alwaysAddWindowsResolver || (webApplication == null);
if (!flag2 && (webApplication != null))
{
if ((web == null) && urlZone.HasValue)
{
flag2 = webApp.IisSettings[urlZone.Value].AuthenticationMode == AuthenticationMode.Windows;
}
else
{
foreach (SPIisSettings settings in webApplication.IisSettings.Values)
{
if (settings.AuthenticationMode == AuthenticationMode.Windows)
{
flag2 = true;
break;
}
}
}
}
if (flag2)
[...]
if (SPUserUtility.IsAllowedAccount(domainName, web, webApp))
{
bySidResolver = new SPActiveDirectoryPrincipalBySIDResolver(web, (web == null) ? webApp : web.Site.WebApplication, domainName, ntAccountName, binaryForm, sidTypeInvalid, false);
}
So we can see flag2
is only set to true
when the AuthenticationMode
is set to Windows
. In a Claims-based Web Application, the AuthenticationMode
is Forms
.
Additionally, installing SharePoint 2013 in a Workgroup is unsupported per KB2764086.