I don’t particularly enjoy installing SharePoint, I’ve done it a million times and really it’s quite a boring process. When I do end up having to install it, I generally use a simple 4 account method:
- Admin (SPAdmin) - Used for installation and administration of SharePoint
- App Pool (SPAppPool) - all web apps except central admin run with this account as their identity
- Services (SPService) - App pool account for central admin and the SSP service account
- Search (SPSearch) - Used for all search services
Generally I’m installing SharePoint for my own dev/test purposes, so this suits just fine. I think it is also fine for small scale installations or instances when the admin in charge of account creation isn’t interested in creating 8+ accounts. To be honest I think a lot of the time using the 8+ accounts is a tad overkill, and people are just blindly following ‘best practices’ without applying them to their specific environment. But being more of a dev type than an infrastructure type I don’t feel qualified to formally make that recommendation.
Even for a development server it is really important to have some separation of accounts. It is in your best interest to simulate a production scenario as best you can. Take for example if you were to use the SharePoint admin account as an application pool identity. You may have permissions to do things on your dev server (in code) that will probably have issues in a production scenario.