Setting the super user account on SharePoint 2010 and getting Access Denied errors afterwards
By default after installing SharePoint 2010 you will probably soon encounter the following two error messages in the Application log:
Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources.
To configure the account use the following command ‘stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl’. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account.
Additional Data:
Current default super user account: SHAREPOINT\system
Object Cache: The super reader account utilized by the cache does not have sufficient permissions to SharePoint databases.
To configure the account use the following command 'stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue account -url webappurl'. It should be configured to be an account that has Read access to the SharePoint databases.
Additional Data:
Current default super reader account: NT AUTHORITY\LOCAL SERVICE
Source of the error is as the Technet documentation says:
By default, the Portal Super User account is the site’s System Account, and the Portal Super Reader account is NT Authority\Local Service. There are two main issues with using the out-of-box accounts.
- The first issue is that some items get checked out to System Account, so when a query that includes these items is made, the checked out version of the item is returned instead of the latest published version. This is a problem because it is not what a user would expect to have returned, so the cache has to make a second query to fetch the correct version of the file. This negatively affects server performance for every request that includes these items. The same problem would occur for any user who has items checked out, if that user’s account was set to be the Portal Super User account. This is why the accounts configured to be the Portal Super User and the Portal Super Reader should not be user accounts that are used to log into the site. This ensures that the user does not inadvertently check items out and cause problems with performance.
- The default Portal Super Reader account is NT Authority\Local Service, which is not correctly resolved in a claims authentication application. As a result, if the Portal Super Reader account is not explicitly configured for a claims authentication application, browsing to site collections under this application will result in an “Access Denied” error, even for the site administrator. This error will occur on any site that uses any feature that explicitly uses the object cache, such as the SharePoint Server Publishing Infrastructure, metadata navigation, the Content Query Web Part, or navigation.
So keeping these values on their default value on an intranet/extranet portal is not such a good idea. Let’s go ahead and set these two, according to the suggestions in the error message!
stsadm -o setproperty -pn portalsuperuseraccount -pv DOMAIN\user -url https://webappurl
stsadm -o setproperty -pn portalsuperreaderaccount -pv DOMAIN\user -url https://webappurl
iisreset
After doing so, you’re either done, or – in case you are in claims mode – will see Access Denied on all pages on the webapplication you set the accounts.
Moral of the story: if you are in claims mode, you will need to use the claims user name (i:0#.w|domain\user).
Relevant sections of the Technet article:
14. Make note of how the names for the Object Cache Super Reader and Object Cache Super User accounts are displayed in the User Name column. The displayed strings will be different depending on whether you are using claims authentication for the Web application.
1.
Copy the following code and paste it into a text editor, such as Notepad:
``` brush: ps;
$wa = Get-SPWebApplication -Identity "<WebApplication>"
$wa.Properties["portalsuperuseraccount"] = "<SuperUser>"
$wa.Properties["portalsuperreaderaccount"] = "<SuperReader>"
$wa.Update()
```
Replace the following placeholders with values:
- *\<WebApplication\>* is the name of the Web application to which the accounts will be added. - *\<SuperUser\>* is the account to use for the Portal Super User account as you saw it displayed in the **User Column** field mentioned in Step 14 of the previous procedure. - *\<SuperReader\>* is account to use for the Portal Super Reader account as you saw it displayed in the **User Column** field mentioned in Step 14 of the previous procedure.
Comments
- Anonymous
October 04, 2010
Thanks a Lot. I was having this problem during many weeks. I was supecting this to be a sharepoint bug. It worked fine!!. - Anonymous
November 08, 2010
Thank you so much! you saved my job! - Anonymous
February 10, 2011
Thanks for the writeup. However, I would like to clarify something for future readers that I got confused about. The recommended change is a two step process. After creating new accounts for super reader and super user in Active Directory, two things will have to be done (and not just the running the powershell command ).1) Add these users in user policy section under web application management in Central Admin. (This is what I got confused about as I think the article doesn't state that clearly and step 14. is a little confusing)2) After adding the accounts thru the Central Admin UI in step 1, run the powershell script as described by the authornonetheless, thanks a lot for this information. - Anonymous
February 14, 2011
Thanks Punit for the clarification. My post was primarily about the results of not entering the correct string for the superuser/reader accounts, that's why I omitted the web application user policy part. - Anonymous
February 23, 2011
I am NOT in claims mode, yet, whenever i set the superusers/reader, i am getting access denied on all sites.pls help thanks - Anonymous
March 09, 2011
You should add priviliges to this accounts throught central administration p[age for all web application - Anonymous
May 04, 2011
hi i am in similar boat, my web app is claims based, and turned on publishing infrastructure in all sub sites.some people are getting access denied on some sub sites, other are fine. how do i fix this issues, i did not configure nay super user account at all. can u direct me in the correct path. - Anonymous
May 04, 2011
Object Cache: The super reader account utilized by the cache does not have sufficient permissions to SharePoint databases.To configure the account use the following command 'stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue account -url webappurl'. It should be configured to be an account that has Read access to the SharePoint databases.Additional Data:event 7363 web content managementCurrent default super reader account: NT AUTHORITYLOCAL SERVICEis this the reason some useers ar4e getting access denied on some sub sites.through ur pointer.and comment - Anonymous
July 06, 2011
The comment has been removed - Anonymous
August 11, 2011
I have four web applications. How do I find our which application is missing the permissions? - Anonymous
August 12, 2011
Carsten, I would verify the settings on all four webapps and make sure1) the webapp has its portalsuperuseraccount and portalsuperreader accout set to a string that's valid for the webapp2) the specified accounts have full control and read rights respectively on the webapp policy - Anonymous
September 05, 2011
Thanks a lot. I have faced Sharepoint 2010 authetication issues. it worked. - Anonymous
October 05, 2011
Thanks for this article.to the point "The first issue is that some items get checked out to System Account", how can we know which all items get checked out by the system account? - Anonymous
March 29, 2012
Thanks! This saved a lot of work, had exactly the same issue. - Anonymous
August 27, 2012
How do you verify it worked after doing both steps? - Anonymous
November 26, 2012
Thank you very much! I had lost a mission-critical site collection, and had strange calendar form issues in another site collection before I tried this solution. The deletion and re-adding of the account in Central Admin, coupled with the PoweShell code above worked! Of course, at first it didn't because I forgot to reset IIS! After that, I am back in business. Thanks again, and also for the clarification by Punit. - Anonymous
June 07, 2013
Check Central admin quotas and locks it should be not locked - Anonymous
December 22, 2013
The comment has been removed - Anonymous
February 03, 2014
Thanks for the article. really helps a lot.I had Claims Based Authentication and i have not used (i:0#.w|domainuser), - Anonymous
February 20, 2014
@matthew - To verify the Super User Account - stsadm -o getproperty -propertyname portalsuperuseraccount -url "myURL"Nice blog! Thanks