"Access Denied" After Setting the Super User Account in SharePoint 2010

by dcurtis 8/24/2011 6:23:00 AM

I have a love/hate relationship with SharePoint, and for the last 24 hours I've been leaning on the hate part of the relationship.  

The Situation

I noticed the following messages in my logs on SharePoint:

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

So, I ran the commands and thought everything would be good to go--boy was I wrong. Suddenly I started getting "Access Denied" errors on every page that I went to. The logs weren't helpful in indicating what the issue was either. Finally I found a post here that definately applied to my situration--I was using claims-based authentication, but I had used [domain]\[username] when setting the super reader and super user accounts. I ran the script again with the correct accounts and...I still had the same problem. The only parts of the site I could get into was the site settings--I couldn't get into any other account. As a side note, I found that I also could not connect via SharePoint Designer--it would just result in a looping login.

The Solution

After hours of trying anything to get this to work, I decided to go to Central Administration and enable anonymous access and remove NTLM authentication. After changing these settings, I was finally able to get into the site! I then crossed my fingers, disabled anonymous access and added NTLM authentication again and voila--I could once again access the site.

Final Note

Just in case you don't see it in the blog post I referenced in this article, the super user and super reader accounts should be two separate domain accounts that are not used to log into the site. The super user account needs Full Control on the web application and the super reader account needs Full Read on the web application.

Currently rated 3.7 by 15 people

  • Currently 3.666667/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Related posts

Comments

Comments are closed

Powered by BlogEngine.NET 1.3.0.0
Theme by Mads Kristensen

About the author

Derek Curtis Derek Curtis
President, Plaid Pony Technology Solutions LLC

E-mail me Send mail

Calendar

<<  September 2017  >>
MoTuWeThFrSaSu
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678

View posts in large calendar

Pages

    Recent comments

    Authors

    Disclaimer

    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    © Copyright 2017

    Sign in