Run SQL Server services with the lowest possible privileges.

I see the phrase "Run SQL Server services with the lowest possible privilege
s." but the exact lowest possible privileges are not exactly discussed anywh
ere. I am betting that the answer depends on exactly what you are doing wit
h SQL Server. Some guideli
nes and discussion of this would be helpful.Ken wrote:
> I see the phrase "Run SQL Server services with the lowest possible privileges." bu
t the exact lowest possible privileges are not exactly discussed anywhere. I am bet
ting that the answer depends on exactly what you are doing with SQL Server. Some gu
ide
lines and discussion of this would be helpful.
>
I wrote up a small article on this that can help point you in the right
direction.
http://blogs.sqladvice.com/aweiker/.../03/07/712.aspx
Aaron Weiker
http://blogs.sqladvice.com/aweiker
http://aaronweiker.com/|||from:
http://www.microsoft.com/technet/pr...n/sp3sec02.mspx
Services
SQL Server 2000 and SQL Server Agent run as Windows services. Each service
must be associated with a Windows account, from which it derives its
security context. SQL Server allows members of the sysadmin fixed server
role to access operating system features. These operating system calls are
made with the security context of the Windows account that owns the server
process. If the server is cracked, these operating system calls may be used
to extend the attack to any other resource to which the owning Windows
process (the SQL Server service account) has access. For this reason, it is
important to grant only necessary privileges to SQL Server services. The
following settings are recommended.
SQL Server Engine/MSSQLServer
This is the SQL Server database engine and is the only mandatory service.
Run as a Windows domain user account with regular user privileges. Do not
run as local system, local administrator, or domain administrator accounts.
If there are named instances, they will be named MSSQL$InstanceName.
SQL Server Agent Service/SQLServerAgent
This is a support service that allows you to schedule commands and notify
operators when errors occur. Disable if not required in your environment;
otherwise run as a Windows domain user account with regular user
privileges. Do not run as local system, local administrator, or domain
administrator accounts. If there are named instances, they will be named
SQLAgent$InstanceName.
Important: SQL Server Agent will need local Windows administrator
privileges if one of the following is true:
SQL Server Agent connects to SQL Server using SQL Server Authentication
(not recommended).
SQL Server Agent uses a multiserver administration master server (MSX)
account that connects using SQL Server Authentication.
SQL Server Agent runs Microsoft ActiveX script or CmdExec jobs owned by
users who are not members of the sysadmin fixed server role.
SQL Server Active Directory Helper/MSSQLServerADHelper
This service supports Active Directory integration, including database
instance registration. Disable if not required in your environment;
otherwise run as a Windows local system account.
Microsoft Search
This service provides full-text search capabilities. Disable if not
required in your environment; otherwise run under the local system account.
Microsoft DTC
This service coordinates the processing of transactions distributed across
two or more servers. Disable if not required in your environment.
If you need to change the account associated with a SQL Server service, use
SQL Server Enterprise Manager. Enterprise Manager will set appropriate
permissions on the files and registry keys used by SQL Server. Never use
the Services applet of Microsoft Management Console (in Control Panel) to
change these accounts, because this requires manual adjustment of dozens of
registry permissions, NTFS file system permissions, and Windows user rights
a process that is prone to error.
For more information, see 283811 "HOW TO: Change the SQL Server Service
Account Without Using SQL Enterprise Manager in SQL Server 2000,". Changes
to account information will take effect the next time the service is
started. If you need to change the account associated with SQL Server and
SQL Server Agent, you must apply the change to both services separately
using Enterprise Manager
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Aaron,
I have followed your directions to the letter, and had also previously
attempted this with MS's article Q283811, but am coming up with a problem
when I attempt to make the change in Ent. Manager:
Error 22042: xp_SetSQLSecurity() returned error -2147024890, 'The Handle is
invalid.'
Should I be setting this up elsewhere? Has anybody else encountered this
before?
Derek
"Aaron Weiker" <msnews.SPAM@.aaronweiker.com> wrote in message
news:efQXgRcDEHA.3016@.TK2MSFTNGP11.phx.gbl...
> Ken wrote:
privileges." but the exact lowest possible privileges are not exactly
discussed anywhere. I am betting that the answer depends on exactly what
you are doing with SQL Server. Some guidelines and discussion of this would
be helpful.
> I wrote up a small article on this that can help point you in the right
> direction.
> http://blogs.sqladvice.com/aweiker/.../03/07/712.aspx
>
> --
> Aaron Weiker
> http://blogs.sqladvice.com/aweiker
> http://aaronweiker.com/
>|||Did you change the MSSQLServer service account from Control Panel Services,
or thru Enterprise Manager?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||We have recently implemented this change on our SQL servers. One thing that
helped us with troubleshooting errors was to enable failed object access aud
iting in the local auditing policy and then to enabloe all auditng on failed
access attempts on HKLM\So
ftware and sub keys and on the root of every partition and subdirectories an
d files.
If a DBA or programmer creates a SQL job that tries to access something that
it shouldn't or something that is stored somewhere that it shouldn't be it
will show up in the security event log.
Our biggest issue was batch files and scripts that were called from SQL jobs
that used the admin shares or tried to write to the root of a partition rat
her than the directories that we had set aside for SQL use.