Default Web Application Policies and Determining Number of Service Accounts
Back in the day we use to run everything as an account that is local administrator. This really isn't a best practice anymore. Worst case is to run everything with domain admin priviledges. It unnecessarily exposes your environment. Let me compare and contrast different strategies.
All one account in local admin group - (lazy) this unnecessarily gives the account running everything access to everything and when that account gets hacked they have read access to everything. It will have full read to the content and can then get into central admin and give itself a full control policy. If you use this with the SQL rights as well you're exposing that box info as well. You just need dbcreator and securityadmin.
One account for crawl account, and one service account for everything else - (a bit better) In a lot of environments this should meet most of the requirements. At least the crawl account isn't unnecessarily exposing info.
One account for Crawl, One for Central Admin service/SSP service account for SSP Admin and Farm Service/Management account, one for content web app app pool - (much better) now we're looking like a smarter farm. Read access to crawl in our central. As long as the people who own the content web apps have common interest this scenario trades off management and security. For those looking for simplifying there life without compromising security this is my recommendation. I really really don't think WSSSearch and MOSS Search (the crawl or content access) accounts really don't need to be different. If you have 2 different crawlers, then yes, you should use different crawl accounts since obviously you're looking to divide your content between SSPs to separate the indexes or BDC access. When it's about search, I would recommend specifically pay attention to the crawl account(s). As a best practice *Never* make the crawl account a local admin.
One for SharePoint Setup (install SP_Admin), WSS Search Help crawl (SP_WSSSearch), one for MOSS Crawl (SP_MOSSSearch), one for Central Admin (SP_Farm), one for SSP service account (SP_SSPService), SSP App Pool account for the SSP Admin web app (SP_SSPAppPool), one for My sites content web app for the app pool (SP_MyAppPool), one for Portal App Pool (SP_PortalAppPool) - this is the most secure and obviously in this configuration this is just speaking to the Front end. You're going to have separate SQL Service Account (SQL_Service) and for the cluster service account in a cluster (Cluster_Service). Most of these accounts really don't need any special rights. SharePoint will take care of setting up the rights. The Setup account (SP_Admin) and the Central admin (SP_Farm) does need local admin during the install and needs dbcreator and securityadmin. This way during install it works to create the databases, and then after the central admin exists new dbs can be created from the web UI. This farm setup account (SP_Admin) the only local admin with the relevant SQL access would be used to install hotfixes and service packs, deploy packages, and run stsadm commands. It could be disabled when you're not doing these things since it is not ran as a service account.
With so many accounts, you're secure, but what about managing these with a 60 or 90 day password expiration policy? Here's a handy reference for STSADM password management.
In Shane's Advanced Admin class we created a new farm with 8+ unique accounts (much of the detail above). In doing so, I'm seeing some interesting default web application policies.
(All zones) NT AUTHORITY\LOCAL SERVICE NT AUTHORITY\LOCAL SERVICE Full Read
(All zones) Search Crawling Account TPG\SP_MOSSSearch Full Read
(All zones) Search Crawling Account TPG\SP_WSSCrawl Full Read
(All zones) TPG\sp_sspservice TPG\SP_SSPService Full Read
First you can see the builtin group local service is given a full read. Both the Office SharePoint Search (content access account) crawl account and the Windows SharePoint Services Help Search crawl account are individually given a policy of full read. This enables the crawl accounts access to the content in the web applications.
Note, you don't want the crawl account to have more rights, so when you are creating accounts it does pay off to create this is a second account. You don't want your crawl account to have more than read. If you remove this policy you'll likely get errors. This policy that gets setup is important.
The SSP service account is also given full read. Interesting. If you think about it, it does need to share information with the web applications. If you have BDC this is one example of the SSP needing to share information across web applications.
Curious about local service? I was. So I looked around and found Microsoft's Service Account Planning Guide. Sounds like a handy reference. Great recommendations on making sure you're being consistent about your service accounts for planning with some recommendations for limiting access.
Here's some info on Network Service and Local Service from the Planning guide:
Local Service account
The Local Service account is a special built-in account that has reduced privileges similar to an authenticated local user account. This limited access helps safeguard the computer if an attacker compromises individual services or processes. A service that runs as the Local Service account accesses network resources as a null session; that is, it uses anonymous credentials. The actual name of the account is NT AUTHORITY\LocalService, and it does not have a password that an administrator needs to manage.
Network Service account
The Network Service account is a special built-in account that has reduced privileges similar to an authenticated user account. This limited access helps safeguard the computer if an attacker compromises individual services or processes. A service that runs as the Network Service account accesses network resources using the credentials of the computer account in the same manner as a Local System service does. The actual name of the account is NT AUTHORITY\NetworkService, and it does not have a password that an administrator needs to manage.
Important: If you change the default service settings, you might prevent key services from running correctly. It is especially important to use caution when you change the Startup type and Log on as settings for services that are set to start automatically by default.
Couple of handy TechNet references:
Plan for and design security (Office SharePoint Server)
Plan for administrative and service accounts
