Search This Blog

SQL Server Service Account Privileges

SQL Server 2005 Books Online indicates that the SQL Server service account requires permission to start the following related services (among many other requirements): SQL Server Active Directory Helper and SQL Server VSS Writer services. How can I verify service-related permissions for the SQL Server service account?

Obviously, the service really would NOT NEED permissions to start these services if you were not going to make use of them.  Let's assume for the moment that we are going to do so, and that you want to determine first of all if the SQL Server service account has these permissions and/or what permissions the account has to services on the machine in question.
A tool called "AccessChk" will allow you to see this type of information, along with lots of other access-related information for given accounts. You can find information on the tool at the following link - http://www.microsoft.com/technet/sysinternals/utilities/AccessChk.mspx.

Always use SQL Server Configuration Manager to change the account used by the SQL Server or SQL Server Agent services, or to change the password for the account. In addition to changing the account name, SQL Server Configuration Manager performs additional configuration such as setting permissions in the Windows Registry so that the new account can read the SQL Server settings. Other tools such as the Windows Services Control Manager can change the account name but do not change associated settings. If the service cannot access the SQL Server portion of the registry, the service may not start properly.

 

To start and run, each service in SQL Server must have an account configured during installation. Startup accounts used to start and run SQL Server can be built-in system accounts, local user accounts, or domain user accounts.

Domain User Account

If the service must interact with network services, access domain resources like file shares or if it uses linked server connections to other computers running SQL Server, you might use a minimally-privileged domain account. Many server-to-server activities can be performed only with a domain user account. This account should be pre-created by domain administration in your environment.

Local User Account

If the computer is not part of a domain, a local user account without Windows administrator permissions is recommended.

Local Service Account

The Local Service account is a built-in account that has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard the system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null session without credentials. Be aware that the Local Service account is not supported for the SQL Server or SQL Server Agent services. The actual name of the account is "NT AUTHORITY\LOCAL SERVICE".

Network Service Account

The Network Service account is a built-in account that has more access to resources and objects than members of the Users group. Services that run as the Network Service account access network resources by using the credentials of the computer account. The actual name of the account is "NT AUTHORITY\NETWORK SERVICE".

Local System Account

Local System is a very high-privileged built-in account. It has extensive privileges on the local system and acts as the computer on the network. The actual name of the account is "NT AUTHORITY\SYSTEM".

In addition to having user accounts, every service has three possible startup states that users can control:

  • Disabled   The service is installed but not currently running.

  • Manual   The service is installed, but will start only when another service or application needs its functionality.

  • Automatic   The service is automatically started by the operating system.

Always run SQL Server services by using the lowest possible user rights. Use a specific low-privilege user account or domain account instead of a shared account for SQL Server services. Use separate accounts for different SQL Server services. Do not grant additional permissions to the SQL Server service account or the service groups. Permissions will be granted through group membership or granted directly to a service SID, where a service SID is supported..

 

No comments: