SQL Server 2000's two key programs -- the actual SQL Server and the SQL Server Agent -- typically run as services...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
in the Local System user context. When SQL Server users access operating system features, usually through SQL Server's SA login, access is performed in the context of the accounts where the server process runs.
This may sound trivial, but if a security breach occurs, someone could execute arbitrary SQL Server code in an administrative context and terrible things could happen. For instance, the xp_cmdshell stored procedure can be used to run command-line codes in SQL Server's user context, which could allow an attacker to do anything from siphon out data to delete files.
To lock down that security hole, Microsoft recommends changing the user context that SQL Server runs in; typically you should create a domain user account with regular user privileges and run the SQL Server engine (MSSQLSERVER) in that context. To do this, create the user account, open SQL Server Enterprise Manager, right click on the SQL Server instance in question, select Properties | Security, and under "Startup service account," select "This account" and then supply the new user account name and password. You have to restart SQL Server for this change to take effect.
Note: When you make this change for SQL Server, you are also changing the context for the SQL Server Agent account. You may not want to do this if the Agent needs to do any of the following:
- Connect to SQL Server via standard authentication (not recommended in the first place)
- Run ActiveX/CmdExec jobs owned by users who are not members of the sysadmin fixed server role (unlikely, but possible)
- Use a multi-server administration master server account that again connects using standard authentication (also unlikely and not a recommended configuration)
For the most part, you should be able to run the Agent in a regular user context without problems. Test your SQL Server setup with limited privileges during off hours if possible and be wary of any unexpected consequences that might come from running in a regular-user context.
About the author: Serdar Yegulalp is the editor of the Windows 2000 Power Users Newsletter. Check out his Windows 2000 blog for his latest advice and musings on the world of Windows network administrators – please share your thoughts as well!
More information from SearchSQLServer.com
- Tip: Hacker's-eye view of SQL Server
- Book Excerpt: Optional features turned off by default in SQL Server 2005
- Step-by-Step Guide: How to patch SQL Server