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.

Today I installed the Windows SharePoint Services 3.0 SP2 on a Windows Server 2008 R2 x64 machine in order to install the Service Level Dashboard for Operations Manager 2007 R2 later on. I had to use the SPS because the SLD installer is incompatible with non-English MOSS farms… and Microsoft didn’t quite care about the users “whining” on TechNet.

After the SPS configuration wizard was done, I tried accessing the SharePoint Central Administration page… and got this:

 

 

I stopped looking at the event log at this point, what proved to be a time-costly mistake, more to that later. I started searching the Internet and found a lot of similar cases but none came close to mine. Most “answers” told you to disable IPv6. Seriously guys, this is NEVER a “solution”! It is at best a workaround… and won’t help in my case anyway. A little later I reviewed our MOSS documentation and stumbled across the solution: the application pool identity user did not have enough rights on the server. I forgot that using a “domain admin”-service account does NOT grant it the right to log on as a service! I really don’t like this behaviour as I like to start with a domain admin account and then, in case everything runs as expected, strip it to a least privileges account. So I added the service account to our server GPO and the application pool started and could reach the Central Administration site.

This is just another case of READ THE EVENTLOG CAREFULLY! There was a third entry I overlooked which even suggests the missing log on rights:

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