Skip to main content

MSSQL Permissions

Installation of Microsoft SQL Server requires that it have certain permissions in order to run on the local system. Some people choose to have it run under a Domain Account that has Administrative Access. And at one point (especially SQL Server v6.5 and SQL Server v7.0) it was much easier to install if you used an Acount that had Administrative access (i.e., Local Administrator Group role). I even believed at one point that using a Domain account made it easier for SQL Agent jobs to export data to remote file shares. Changes in SQL Server and in SQL Server Integration Services (SSIS) and SQL Agent have fixed (or made easier) some of these issues. So I can now say to a former co-worker (Bill) that you were right, and we could have converted SQL Server to use a local account instead of a Domain Account (although this may still introduce some security concerns for some enterprises).

In any case, the account that Microsoft SQL Server uses needs the following rights include (instead of running under an account with Administrator rights): 'Access this computer from the network', 'Allow log on locally', 'Allow log on through Terminal Services', 'Bypass traverse checking', 'Force shutdown from a remote system', 'Perform volume maintenance tasks', 'Profile single process', 'Profile system performance', 'Shut down the system'. I do need to research this more as new versions of SQL Server (this is all based on SQL Server 2005 and Windows 2003) may require less or more permissions, especially as further changes are made to the Windows Security Model.

If you do use a Domain Account (or even a local account on the server), double check to ensure what other permissions the account has and what directories the account can access. Too much access could lead to additional exploits where users can access data without accountability. There could even be potential for a denial of service attack which would disrupt the system for all the other users and/or applications.

A separate concern, that still occurs today, is software or roles that need more permissions than really necessary? Applications may be grated something like db_datareader in all databases, which could cause information "leakage" so that one account/user/application with rights to a database can read data in other databases that it shouldn't. Other roles like 'db_ssisoperator,' 'SQLAgentOperatorRole,' 'ServerGroupReaderRole' in msdb, 'mdw_reader' in your Management Data Warehouse, and server permissions for 'Alter trace' 'View any database' 'View any definition', 'View server state' (For SQL 2005 substitute 'db_dtsoperator' for 'db_ssisoperator' and leave out 'ServerGroupReaderRole') could lead to more data leakage or even data tampering. And the role 'SQLAgentOperatorRole' can have even more serious repercussions by crafting a job that restarts SQL Server or the whole server if it's created correctly. In other words, think about the permissions you're granting to accounts and what access they might have.

Some of my reading on the web inspired this, and one article specifically caught my eye. Read this article ( for further information about other security concerns.