Kernel Confusion

Every last business day of the month, freelancers working for our company access our SharePoint Portal to enter their project work times. This time, they got an “Access Denied” error instead of the usual homepage. Trying to access “www.someportal.com” would result in the error shown below. On the other hand, directly accessing the time sheet manager via “www.someportal.com/time/” was successful.

SharePoint: Access Denied

The first suspect was of course the main user and group setting of the portal. But nothing had changed and the “freelancer” group still had it’s permission to view the homepage. As the access rights were inherited down to the time sheet manager, which was accessible, that couldn’t be the problem.

Then I noticed that one particular thing was different with the URL displayed in the IE address bar. Instead of the usual
” https://www.someportal.com/_layouts/AccessDenied.aspx?Source=%2fsomepage ”
I got this:
” http://www.someportal.com/_layouts/AccessDenied.aspx?Source=somepage&Type=list&name=%7B12151589%2D7C0B%2D40DE%2DBD92%2DADB851B3D78E%7D ”

The additional GUID leads to some list, as you can see a little earlier in the URL. Now you can of course search you content database or, if you want to save time, use a little tool. For this case I stumbled upon this one: The Sharepoint Explorer by Ontolica. Run it on your portal server with an user that has full access to the site. This way, you can find the list in question quite quickly.

SharePoint Explorer

In most cases, identifying the list is the solution, as you then know where you have to review the permissions. In my case, this was a dead end, as the permissions were correct.

Going on, I copied the Windows user account of a freelancer and gave it full permissions. Looking through “their eyes” I found a new report viewer web part on the homepage which was targeted at the freelancer group, so I couldn’t see it with my account. This web part was added a few days earlier and obviously not tested properly. The “read” permission was not enough to display it, so the homepage was denied. I granted the freelancer group participation-level access to the report-item, which finally solved the problem.

A Microsoft Sharepoint Server can be very complicated, to say the least. Last week I had the task to establish Kerberos authentication throughout a very small Sharepoint environment, consisting just of a MS SQL 2008 Server and the Office Sharepoint Server itself. The installation was based on Microsoft’s best-practice recommendations, so every application pool and Windows service  had it’s own domain user.

Looking up all interesting data can take some time, especially if you did not setup these servers yourself. I stumbled upon a small tool that gathers useful data about Office Sharepoint and Sharepoint Services environments. It is called SPSFarmReport and is an open-source project at Codeplex.

The following “questions” will be answered by the tool: 

• How many servers exist in the farm?
• What services are run by each server in your farm? Which server is the Query/Indexer?
• Which server(s) host(s) the Central Administration web site in the farm?
• How many SSPs exist in the farm?
• Which is the default SSP in the farm?
• What is the URL of the administration site of an SSP?
• What is the URL of the My Site provider of an SSP?
• What Web applications are associated with each SSP?
• Which application pool is associated with each web application in the farm?
• Which account is used to run a specific application pool?
• How many content databases are associated with each web application and how many site collections does each have?
• What AAMs are configured for each web application?

You run it on one of the Sharepoint servers and it will gather all the data from there and create an HTML result file.

It really helped me to get an overview and locate all the accounts I had configure for Kerberos.

Get it here: http://www.codeplex.com/SPSFarmReport