In the last couple of days a person next to me was trying to install SharePoint and failing every time with the shared services. After setting up the shared services, he couldnt open the shared services site - it would "access denied" him, no matter what account he tried to log on as (and we even tried the application pool account).
We immediatly suspected that kerberos wasnt configured correctly, that we didn't give enough local permissions for a system account or that some metaphysical entity just hates us sooo much.
Today I sat with the guy and watched him configure everything correctly. Still - access denied. damn!.
I turned to my trusty friend google, typed "sharepoint ssp access denied" in the search box and the second result had not only a workaround - but also an explanation why it happened and how to avoid it in the future.
So first of all - thank you Faraz for finding a work around, but more importantly - thanks to Scott who wrote the following in the comments:
"DO NOT call you SSP the same name as the AppPool you use for the SSP Admin Site.
The SSP actually uses its name to create an AppPool for use under the Office Search site.
If your SSP Admin AppPool is the same name then MOSS sets it to use the timer svc account.
If your hosting then call the SSP Admin AppPool 'Company - SSPAdmin' and the actual SSP 'Company - SSP'. This will stop MOSS clobbering the accounts."
This was exactly what we did wrong! We created a new SSP and this time made sure the SSP name is different from the application pool name, and here we go! ready to start.
So, if you are the Scott who wrote that comment - I thank you.