SharePoint is an incredibly powerful collaboration platform that has revolutionized the way businesses function. With its ability to streamline business process management solutions, enhance productivity, and provide a competitive edge, SharePoint has become an integral part of many organizations.

However, even with its numerous benefits, SharePoint can sometimes face issues that can hinder its effectiveness. From technical glitches to user errors, these problems can have a significant impact on the productivity of an organization.

In this article, we will explore some of the most common issues related to SharePoint and how our team was able to solve them. By understanding these issues and their solutions, organizations can ensure that they are getting the most out of their SharePoint investment.

Common errors

After installing and using SharePoint 2010, you will most probably encounter the following 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 unnecessary 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 "

Our SharePoint Admin and development team recently came across some errors while working on the platform, and after conducting some research, we found that the root of the problem lay in the default configuration of the Portal Super User and Portal Super Reader accounts. As per Microsoft’s TechNet Library documentation, these accounts are automatically assigned by default when creating a new SharePoint site, with the Portal Super User account being the site’s System Account, and the Portal Super Reader account being NT Authority\Local Service.

While these default accounts may seem convenient, we noticed two main issues with using the out-of-box accounts. The first problem is that using the System Account as the Portal Super User can lead to security concerns, as this account has elevated privileges that can be exploited if compromised. The second issue with using out-of-the-box accounts is that the Local Service account used for the Portal Super Reader has limited permissions, which can prevent users from accessing certain resources or data on the site.

Issue we encountered

After our team analyzed the application logs and configured the accounts accordingly, we believed that the issues we had encountered had been resolved. However, we soon found ourselves facing a new and unexpected problem. Users in the site owner group began reporting that they were receiving an "Access Denied" error when trying to access certain resources on the site. This was a puzzling development, as users in this group should have had full control permissions and should not have been encountering any access issues.

The "Access Denied" error clearly indicated that the users in the group did not have the necessary permissions to access something on the site. However, we were unable to determine what this could be, as we had thoroughly checked and configured all the relevant permissions. This issue was particularly concerning as it had the potential to seriously impact productivity and hinder collaboration.

The Solution through Root Cause Analysis

Our Administrators, Development team, and R&D team were back in action to find out the root cause for the issue and tried several ways to resolve the issue:

# Checked master page gallery for any custom permissions

One of the first steps we took was to check the Master Page Gallery for the site collection to see if there were any custom permissions that could be causing the issue. However, we did not find any issues there, and the permissions seemed to be set up correctly.

# Attempted to revert the object cache settings

Next, we attempted to revert the Object Cache Settings that had been changed to configure the Super User and Super Reader accounts. However, even after doing this, the "Access Denied" error persisted.

# Checked custom web parts

Since our site had many custom web parts, we considered the possibility that one of these web parts could be causing the issue. We carefully examined each web part and checked if it was accessing groups through the SharePoint Object Model using a user's credentials instead of privileges. However, we did not find any issues with the web parts, and we concluded that they were not causing the "Access Denied" error.

# Enabled anonymous access and removed NTLM authentication

After conducting further research, our team came across similar reported issues and solutions. We decided to enable anonymous access and remove NTLM authentication through central administration, and this finally worked. Users were able to access the site without encountering the "Access Denied" error.

# Disabled anonymous access and enabled NTLM authentication

Since our team knew that enabling anonymous access was not the right approach to solving the issue, we disabled anonymous access and re-enabled NTLM authentication. To our surprise, users were still able to access the site without encountering the "Access Denied" error.

In the end, it was unclear what caused the "Access Denied" error on the SharePoint site, but our team was able to resolve it by enabling anonymous access and removing NTLM authentication. This was not the ideal solution, and we continue to investigate the issue to find a more permanent fix. Our experience highlights the complexity of SharePoint and the importance of thorough testing and investigation when encountering issues.

Finally, to implement a secure solution, they revoked permissions for each user and again individually configured permissions for each user. Now, users had access to the site just as before. The moral of this story is that superuser accounts need full control of the web applications, and the super reader account needs full read of the web applications. These accounts should be separate domain accounts and should not be used to login into the site. In addition, you should avoid poorly written web parts and must properly configure you SharePoint with appropriate privileges.

Conclusion

Encountering "Access Denied" errors in SharePoint can be a frustrating experience for both users and administrators. Through our experience, we learned the importance of thorough testing and investigation when encountering issues in SharePoint. Superuser and super reader accounts should be separate domain accounts and not used to log in to the site. Poorly written web parts and SharePoint solutions must be properly configured with appropriate privileges to avoid any security concerns.

In the end, we resolved the issue by revoking permissions for each user and individually configuring permissions for each user to ensure secure and efficient access to the site. By following best practices and conducting thorough testing and analysis, organizations can ensure that they are getting the most out of their SharePoint integration and avoid common errors and "Access Denied" issues.

Call us at 484-892-5713 or Contact Us today to know more details about the How to resolve SharePoint error: Super user accounts & “access denied”