Security and the User Context

To install SQL Server on a machine, you need not be an administrator of the domain, but you must have administrator privileges on the machine. Users can install most of the SQL Server client utilities without administrator privileges.

Before you set up your system, give some thought to the user context in which SQL Server and SQL Server Agent will run. A new SQL Server environment can set up the SQL Server engine to run in the context of the special system (LocalSystem) account if it is not being installed on a Windows 2000 domain controller. This account is typically used to run services, but it has no privileges on other machines, nor can it be granted such privileges. However, the default is to have the SQL Server service and the SQL Server Agent service run in the context of a domain administrator account. This allows SQL Server to more easily perform tasks that require an external security context, such as backing up to another machine or using replication. If you don't have access to a domain administrator account, you might want to set up SQL Server to run in the context of a local administrator. This will still give SQL Server sufficient privileges to run on the local machine.

If you're not going to use the LocalSystem account, it's a good idea to change the account under which SQL Server runs to a user account that you've created just for this purpose rather than use an actual local or domain administrator account. The account must be in the local Administrators group if you're installing SQL Server on Windows NT or Windows 2000. You can create this account before you begin installing SQL Server, or you can change the account under which SQL Server runs at a later time. Changing the account is easy: you use the Services applet in the Windows NT Control Panel. In Windows 2000, you can use the Microsoft Management Console, which is accessible from Start/Programs/Administrative Tools/Computer Management. When you choose or create a user account for running SQL Server, make sure you configure the account so that the password never expires; if the password expires, SQL Server won't start until the information for the service is updated. (This is why I don't recommend using the real Administrator account for SQL Server; that account will probably have its password changed regularly.)

If you plan to use the mail integration features (SQL Mail), you should be aware of one additional issue: if you're using Microsoft Exchange on the same machine as SQL Server, you should run SQL Server in the context of the user account for which your Exchange client is configured. SQL Server can then pick up the Exchange configuration for that user automatically.

By default, the installation program chooses to use the same account for both the SQL Server and the SQL Server Agent services. SQL Server Agent needs a domain-level security context to connect to other computers in more situations than does SQL Server. For example, if you plan to publish data for replication, SQL Server Agent needs a security context to connect to the subscribing machines. If you won't be publishing data for replication or scheduling tasks on SQL Server that require access to other computers, you can have SQL Server Agent run in the LocalSystem account. If you specify a domain account but the domain controller cannot validate the account (because the domain controller is temporarily unavailable, for example), go ahead and install using the LocalSystem account and change it later using the Services applet (in Windows NT) or the Microsoft Management Console (in Windows 2000).

The accounts under which the SQL Server service and the SQL Server Agent service run can also be changed from SQL Enterprise Manager. For the SQL Server service, right-click on the name of your SQL Server, choose Properties, and then go to the Security tab. For the SQL Server Agent service, open the Management folder, right-click on SQL Server Agent, choose Properties, and stay on the General tab.