Notes from the Field: Default Web Application Policies and Determining Number of Service Accounts

In the past, we used to run everything as a local administrator account. This really isn’t a best practice anymore. The worst-case scenario is to run everything with domain administrator privileges, which unnecessarily exposes your environment. Let me compare and contrast some different strategies.

Strategy one: All one account in the local administrator group (worst strategy). This unnecessarily gives the account that is running everything access to everything. If that account gets hacked, the intruders will have read access to everything. Because this single account has so much access, someone hacking into this account will have full read privileges to the content and can get into Central Administration to assume a full control policy. If you use this strategy with SQL rights as well, you’re exposing that box info, too. A hacker needs only dbcreator and securityadmin and the entire system can be compromised.

Strategy two: One account for the crawl account and one service account for everything else (a bit better). In many environments, this strategy meets most needs, and at least the crawl account isn’t unnecessarily exposing information.

Strategy three: One account for crawl, one for Central Administration service/SSP, one for SSP administration and Farm Service/Management, and one for content Web application pool (much better). This is a much smarter farm than the previous two. As long as the people who own the content Web applications have common interests, this scenario trades off management and security. For those looking to simplify their lives without compromising security, this is my recommendation. I really don’t think WSSSearch and MOSS Search (the crawl or content access) accounts need to be different unless you have two different crawlers. Obviously, you’re looking to divide your content between SSPs to separate the indexes or BDC access. When it’s about search, I recommend paying specific attention to the crawl account(s). As a best practice, never make the crawl account a local administrator.

Strategy four: One for SharePoint Setup (install SP_Admin), one for WSS Search Help crawl (SP_WSSSearch), one for MOSS crawl (SP_MOSSSearch), one for Central Administration (SP_Farm), one for SSP service account (SP_SSPService), an SSP App Pool account for the SSP Admin Web app (SP_SSPAppPool), one for My Site content Web app for the app pool (SP_MyAppPool), and one for Portal App Pool (SP_PortalAppPool). This configuration is the most secure because it is speaking only to the front end. You’re going to have a separate SQL Service Account (SQL_Service) and a 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 Central Administration (SP_Farm) do need local admin during the install, as well as dbcreator and securityadmin. This way, it works to create the databases during installation. After the Central Administration exists, new databases can be created from the Web user interface. The Setup account (SP_Admin), which is the only account with both local admin and 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 because it is not run as a service account. It should never be deleted because it is required for performing these special farm configuration activities. Remember, this account has complete access to all farm content and cannot be denied, so it should never be used as a logon account or for other administration.

With so many accounts, you’re secure, right? But what about managing these with a 60- or 90-day password expiration policy? A handy reference for STSADM password management can be found at http://blogs.msdn.com/joelo/archive/2006/08/22/712945.aspx.

In testing, we created a new farm with more than eight unique accounts (many details of which is covered above). In doing so, we saw some interesting default Web application policies. You’ll notice that these accounts spanned all zones with full read rights.

First, you can see that the built-in group local service is given full read rights. 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 gives the crawl accounts access to the content in the Web applications.

Note that you don’t want the crawl account to have more than read rights. So, when you are creating accounts, it pays off to create this as a second account. If you remove this policy, you’ll likely get errors.

The SSP service account is also given full read rights. 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.

Are you curious about local service? I was. So I looked around and found Microsoft’s Service Account Planning Guide at http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/sspgch02.mspx. The planning guide has great recommendations on how to make sure you’re being consistent when planning your service accounts, with some recommendations for limiting access.

The following is information on Network Service and Local Service accounts 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 AUTHORITYLocalService, 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 AUTHORITYNetworkService, and it does not have a password that an administrator needs to manage.

You need to be aware that 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.

Joel Oleson, Senior Technical Product Manager, Microsoft