Minimum Permissions Required for MOSS 2007 Necessary Service Accounts

For security reasons, it is best to ensure that the service accounts used with Microsoft Office SharePoint Server (MOSS) 2007 run with only the minimum permissions necessary. This is referred to as the principle of least privilege.

Microsoft recommends two general rules that you should apply to all your MOSS 2007 service accounts:
– Use separate domain user accounts for services with different security requirements.
– Do not use domain user accounts with the local administrator or domain administrator privileges to run any services.

Microsoft suggests in one of its white paper that you can use a single service account with administrative privileges to install MOSS 2007 and when everything is working perfectly then you can go back and assign the services with different accounts with minimum permissions. Here’s the exact quote from Microsoft:

To reduce troubleshooting time, you can install an Office SharePoint Server 2007 server farm by using a single service account with administrative privileges. When you are sure that everything works correctly, you can then assign the services to different accounts with minimum permissions.

However, I am totally against this recommendation. On paper this may sound like a good idea but in the real world this can potentially become a nightmare. It’s bad enough that you need so many different accounts to run SharePoint, once you start messing with the service accounts you may end up running around in circles and troubleshooting can become very difficult.

If you must change service accounts and passwords, then check out my blog from December 2008: How to Change Service Accounts and Service Passwords in MOSS 2007 & WSS 3.0.

Here’s a table of Minimum Permissions Required for MOSS 2007 Service Accounts. The information is based on a Microsoft TechNet document. If you are interested in only the necessary SharePoint service accounts then check out Sharee’s blog Necessary SharePoint Service Accounts. She uses her vast SharePoint knowledge to explain things in more detail. There are so many lists out there that document MOSS accounts necessary to install SharePoint properly and some of them are really convoluted. Because Sharee has done tons of successful  installations at our clients based on the table that she has put together, I’ve created a table of accounts based on her table and then I also put together a script that creates all the accounts in an OU called Service Accounts. I have tested the script and it works great. Make sure you check out her blog because she has additional valuable information that I have not included in this post.

Table of Necessary MOSS Accounts (based on Sharee’s recommendation)

Here’s a table of necessary MOSS 2007 accounts. This is a fancy version of Sharee’s table. The table includes the purpose of each account, and its group, domain and SQL rights. You can use your own naming convention. I started my accounts with SP (for SharePoint….or SeattlePro) so I can recognize them as the accounts that were created by me, rather than the system.

WARNING! Although standard Active Directory accounts can have spaces and can be longer than 20 characters, I suggest you limit your account names to 20 characters because the Pre-Windows 2000 login names are limited to 20 characters in WS08 and can’t have spaces. You may not run into any issues in the near future if you don’t follow my advice but I think it is better to be safe than sorry.

Script to Create Necessary MOSS Accounts

To create all the above necessary accounts and the OU, you can download the script here. The results will look like this. This script adds all the necessary permissions required for the accounts in the description so you can easily verify that you have the permissions set properly.

WARNING! Make sure you change the password in the script to match with the password that you want to use for your service accounts.

Troubleshooting Tip

You may encounter a problem when you try to give the service accounts permission to impersonate a client after authentication. On your WS08 Domain Controller you can start Group Policy Management Console, go to Group Policy Objects, right-click Default Domain Controllers Policy and select Edit. In the Group Policy Management Editor, go to Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, User Rights Assignment and double-click Impersonate a client after authentication. Check the box Define these policy settings. If you simply add the service accounts you created and then click Apply or OK you won’t get anywhere. Notice that the warning at the bottom is telling you that you need to add the Administrators and the SERVICE account.

It may not be obvious but what that means is that you need to literally add the Administrators and SERVICE account as shown below in the screenshot and then when you click Apply the warning message will disappear and you will be able to click OK to proceed.

Copyright ©2009 Zubair Alexander. All rights reserved.