
Using Startup Accounts for SQL Server Services
To start and run, each service in SQL Server must have a user account that is configured during installation. User accounts can be built-in system accounts, local user accounts, or domain user accounts.
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.
The following table shows optional accounts for each SQL Server service, and the startup states for each service.
|
SQL Server service name
|
Optional accounts
|
Startup type
|
Default state following Setup
|
|
SQL Server
|
SQL Server Express: Domain User, Local System, Network Service1 All other editions: Domain User, Local System, Network Service1 | Automatic2 | Started Stopped only if user chooses not to autostart |
|
SQL Server Agent | Domain User, Local System, Network Service1 | Manual3 Automatic only if user chooses to autostart | Stopped Started only if user chooses to autostart |
|
Analysis Services
| Domain User, Network Service, Local Service, Local System | Automatic | Started Stopped only if user chooses not to autostart |
|
Reporting Services
| Domain User, Local System, Network Service, Local Service | Automatic | Started Stopped only if user chooses not to autostart |
|
Integration Services | Domain User, Local System, Network Service, Local Service | Automatic | Started Stopped only if user chooses not to autostart. |
| Full-Text Search | Use an account different than the account for the SQL Server service. The account will default to Local Service on Windows Server 2008 and Windows Vista. | Automatic | Started Stopped only if an account is not specified on Windows Server 2003 or Windows XP. |
|
SQL Server Browser | Local Service | Disabled4 Automatic only if user chooses to autostart. | Stopped Started only if user chooses to autostart. |
|
SQL Server Active Directory Helper | Local System, Network Service | Disabled | Stopped |
| SQL Writer | Local System | Automatic | Started |
1 Important We recommend that you do not use the Network Service account for SQL Server services. Network Service is a shareable account, and is appropriate for use as a SQL Server service account only if you can ensure that no other services that use the account are installed on the computer. Domain User accounts that are not a Windows administrator are more appropriate for SQL Server services. Be aware that the Local Service account is not supported for SQL Server Agent.
2Set as manual in failover cluster configurations.
3The SQL Server Agent service is disabled on instances of SQL Server Express and SQL Server Express with Advanced Services.
4By default, for failover cluster installations and named instances, the SQL Server Browser is set to start automatically after Setup finishes.
Using a 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 server account. Many server-to-server activities can be performed only with a domain user account.
Using the 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.
Using a Local User Account
If the computer is not part of a domain, a local user account without Windows administrator permissions is recommended.
Using the 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.
Important: |
|---|
|
We recommend that you do not use the Network Service account for SQL Server services. Network Service is a shareable account, and is appropriate for use as a SQL Server service account only if you can ensure that no other services that use the account are installed on the computer. |
Using the Local System Account
Use caution when you assign Local System permissions to SQL Server service accounts. Local System is a very high-privileged account.
Using Service SIDs for SQL Server Service Configurations
Service security IDs (SIDs) are available in SQL Server 2008 on Windows Server 2008 and Windows Vista operating systems to enable service isolation. Service isolation provides services a way to access specific objects without having to either run in a high-privilege account or weaken the security protection of the object. A SQL Server service can use this identity to restrict access to its resources by other services or applications.
A service isolates an object for its exclusive use by securing the resource by using an access control entry that contains a service SID. This per-service SID is derived from the service name and is unique to that service, for example, a service SID name for a SQL Server service might be NT Service\MSSQL$<InstanceName>. After a SID has been enabled for a service, the SID is added to the local security group in Windows. The service owner can modify the access control list for an object to give access to the SID. For example, a registry key in HKEY_LOCAL_MACHINE\SOFTWARE would usually be available only to services that have administrative credentials. By adding the per-service SID to the access control list of the key, the service can run in a lower-privilege account, but still have access to the key.
During installation,SQL Server Setup creates a service group for each component of SQL Server. On Windows Server 2003 and Windows XP, service accounts for SQL Server services are added to the local service groups and function on these operating systems as they have in previous SQL Server releases; SQL Server services connect to an instance of SQL Server as members of the local group. On Windows Server 2008 and Windows Vista, the service SID is added to the local security group instead of the SQL Server service account.
Supported Service Configurations
Installing SQL Server 2008 on a Windows Server 2008 or Windows Vista domain controller requires SQL Server services to be provisioned with a service SID. SQL Server 2008 is not supported where failover cluster nodes are domain controllers The following table shows the service configurations for new and upgraded installations on Windows Server 2008 or Windows Vista.
|
New installation
|
Upgrade
|
-
Stand-alone instance - Service group with service SID
-
Failover cluster instance - Service SID
| -
Stand-alone instance - Service group with service SID
-
Failover cluster instance - Service group with service account
|
Installing SQL Server 2008 on a Windows Server 2003 or Windows XP domain controller requires the domain for SQL Server services to be provisioned with a domain account. SQL Server 2008 is not supported where failover cluster nodes are domain controllers. The following table shows the service configurations for new and upgraded installations on Windows Server 2003 or Windows XP.
|
New installation
|
Upgrade
|
-
Stand-alone instance- Service group with service account
-
Failover cluster instance - Domain service group with service account
| -
Stand-alone instance - Service group with service account
-
Failover cluster instance - Service group with service account
|
Changing User Accounts
To change the service accounts, password, service startup type, or other properties of any SQL Server–related service, use SQL Server Configuration Manager. Note that renaming the instance of SQL Server does not rename SQL Server security groups. The security groups will continue to function with the old names after the renaming operation.