Change privilege levels for SQL Server 2000 services

SQL Server 2000 users are able to access operating system features in the context of the accounts where the server process runs -- making the database vulnerable to attackers looking to play administrator and steal or tamper with your data. This tip tells you have to change privilege levels.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

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.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy