I have been involved with installing MOSS 2007 (with the right service accounts) with our Sharepoint administrator in our test environment. One problem we uncovered when creating the SSP application is that the SSP timer service account would take over the app pool credentials and not allow us to login. This is explained below.
When we created the Web application where the SSP will be hosted, we created a new app pool and added the service account we created (svcMOSSSSPAP) as the app pool identity account in the 'Create web application' page in central admin. Things were great thus far. However, when we went in to create a SSP under that Web application, we would run into a problem where the SSP timer service account that we entered in the SSP creation form (svcMOSSSSP) would end up taking over the app pool identity for the Web application. This would block all access to the SSP. Also, it would not allow us to change the identity in the app pool in IIS (it would reset to the same account everytime we tried to change it). We finally figured out what it was doing and had to create a new app pool in IIS that would use svcMOSSSSPAP as its identity and configured the SSP web application to use that new app pool. We were then able to access the SSP.