SSP Access Denied

It's quite easy to be faced with an Access Denied screen after creating a Shared Service Provider (SSP) but it's not always so easy to fix the problem.

In most cases, treat your SSP admin sites like any other SharePoint site and ensure the correct users have been granted the necessary access permissions (yoursite/ssp/admin/_layouts/settings.aspx and then People and Groups). You'll generally want to access the SSP site to configure these permissions using the account used to create the SSP in the first place; if that fails, try the account used to run the IIS app pool of the SSP admin site. If that fails, read on...

Before diving in I want to mention this issue has been covered before in various places with the most notable items being Faraz Khan's post; the post includes a plausible explanation of the problem provided by "Scott" in the post's comments. A social.technet thread also points to the same post and some some additional solutions are reported. When I encountered this problem I found both sources cumbersome to wade through and difficult to decipher so I'm summarising the steps I took to fix the problem.

Also, a disclaimer of sorts. SharePoint and MOSS are finicky beasts so while the solution described below may seem to work, I expect a better solution would be to delete the problem SSP after creating a replacement and making it the default SSP (see below to find out what’s causing the problem before you recreate). I’m not certain the solution described won’t introduce new problems (but so far so good in the proof-of-concept environment I’ve built).

To setup, let's assume the following:

• You've created a new SSP named Default SSP
• As part of the SSP provisioning process, you've created a new SSP admin site with an app pool named Default SSP
• The app pool of the SSP admin site account is configured to use the SSP_APP account
• The SSP itself is configured to run as the SSP_SVC account
• When you try to access the site using the account used to create the SSP, the SSP_APP app pool account, or the SSP_SVC service account, you receive an Access Denied error; you can however access /ssp/admin/_layouts/settings.aspx as the SSP creator
• Inspecting the Default SSP app pool, you find the identity is set to run as SSP_SVC instead of SSP_APP as specified above. Changing the identity back to SSP_APP sticks for a few seconds but quickly reverts to SSP_SVC.
• Nothing is reported in the event logs

According to legendary "Scott", the problem occurs because the application pool configured for use by the SSP's admin web application has the same name as the SSP itself (Default SSP). Apparently MOSS independently creates another app pool named after the SSP and running with the SSP credentials (SSP_SVC) for use by the “Office Search site”. The Office Server Web Services web site does have a child web application named Default SSP that is also configured to use the Default SSP app pool. It makes sense that since an app pool with the same name already exists, MOSS either recreates it or magically updates it on a scheduled basis.

To resolve the problem:

• From IIS Manager, right-click the app pool intended for use by the SSP admin site (eg. Default SSP)
• All Tasks -> Save Configuration to a File… and specify a location where you can easily find the output file
• Open the saved .xml file in notepad and change the two references to “Default SSP” (or whatever you’ve named your SSP/SSP admin site account):
  1. The Location attribute of the IISApplicationPool element - change Default SSP to Default SSP App
  2. The Location attribute of the IISInheritedProperties element - change Default SSP to Default SSP App
• Save the file
• Right-click on the Application Pools folder in IIS Manager
• New -> Application Pool (from file)...
• Locate and select the file, click the Read File button, select the configuration, Ok
• Configure the Default SSP web site to use the new app pool (Properties -> Home Directory tab, Application pool drop down)
• Repeat for the /images and /inc applications below the _layouts child site (Default SSP/_layouts/Images, inc)
• Reset IIS for good measure

You’ll now have two application pools, Default SSP and Default SSP App. Don’t delete the original as it’s still in use by Office Server Web Services web site and may get recreated anyway.