A New Twist on SSP Site Access Denied

Posted: September 28, 2010 in MOSS 2007

So you have a farm that has been working for a long time.  Then you do something to it, like say execute a script to update passwords on all your service accounts, including a stsadm edit ssp command. Then you find even your farm install account gets an “Access Denied” when you try to access the SSP administration site.  Despite your farm install account being in the site collection administrators for the SSP administration site, you still are denied access to the site. You find nothing in the event logs, and the ULS simply has an access denied error on Default.aspx in the SSP Admin site.

You can access the “_Layouts/Settings.aspx”, if you try typing in the direct URL, you can even access the search administration, User profile admin, and all other SSP Administration pages, it is JUST the default.aspx page that seems to be blocking you. What’s even more frustrating when you change the SSP service account to your farm account or Content Access account, suddenly everything works.

I have seen many posts on possible causes for this issue. The fixes include from resetting the passwords again, rebuilding your SSP, and a large number of other advanced in depth fixes.

The key to this issue lies in the URL for the access denied page you are given when the user tries to access the default.aspx page along with some default settings quietly put into your site when you configure your SSP. The quiet settings…go to “Policy for Web application” in your central administration. If you select the web application for your SSP administration site, and examine the entries you will see one of the keys. You will see your search crawling account, SSP service account, and Farm install account all have access rights given here. This is the key to your access denied issue.

Turns out when you trace the Access denied page link you will find a listID (GUID) in the url, this will point to 1 of several lists included in the SSP Administration site. The lists will inherit security from the main site. We begin to build the picture, here is the last piece. When you open the Default.aspx , the page uses the SSP Service account to access these custom lists to build its list of links. On the farm I encountered this issue on, during its inception more than a year ago, there were some serious security issues as a result of DoD compliance GPOs, particularly with search. The resulting support call ended up in a series of stsadm calls being made which reset a lot of security items. During this change the SSP Service account was modified to an incorrect setting, and during the password reset a week ago, we fixed that issue and created the access denied issue. The editSSP command will change the SSP Service account fine but it will not add the Policy for Web Application setting to the farm.

One of those little things that can cause a severe headache for you out there. Hopefully, I save someone some trouble with this one.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s