Re: SQL Server Service account rights
From: Christopher Calvin (chris_at_no-chriscalvin-spam.notorgbutcom)
Date: 04/02/04
- Next message: Sue Hoegemeier: "Re: Controlling Access"
- Previous message: DBA72: "SQL Server Service account rights"
- In reply to: DBA72: "SQL Server Service account rights"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 2 Apr 2004 07:11:54 -0600
Everyone's needs are a bit different. I've waged this battle time and time
again due to the fact my hand has been forced by external corporate
auditing. Regardless, the very responsibility of your organization may help
determine the steps you should undertake.
In my environment, we're billed as a platform group asked to supply the
Windows OS as an underlying requirement for a business solution. In
reality, we're an application hosting group required to not only manage the
OS, but also the layered applications and services. SQL is one of a few
special cases where the component on top of our supplied OS is managed by a
group outside of our own: the MSSQL dbas. Other groups falling under this
classification are email (exchange, fax, and other messaging), Oracle DBAs,
etc.
Obviously, these layered services and applications require elevated user
rights; however, we have this catch-all in our corporate security policy
that covers the principle of least access. By rule, we have to restrict
rights to or by any user, device, or object to the absolute minimum required
in order to maintain functionality. See why I say my hand is forced?!
Ultimately, because of the size of our organization and political posturing
that we face, clear and specific administrative boundaries have been drawn
that must be enforced. We can't get into the databases, and the dbas can
only maintain what we allow them with regards to the underlying operating
system.
The risks involved in this is mostly education. Learning what can and can't
be accomplished without one hand asking for help from the other. If you
have an open dialog between administrative groups, easy! Documenting proper
procedures for, what used to be, simple tasks becomes a must in this
secured-to-the-point-of-altering-standard-operations environment.
But hey! I've had oracle dbas dork up their administrative scripts and try
deleting the entire contents of system32. If it wasn't for this strict
environment we've created, I'd probably still be working out disaster
recovery!
As for actually making the switch. It can be a pain. Script it so you
don't have to do it manually again. NTFS, registry, and system auditing
catches anything missing. Use enterprise manager to make the actual service
account change, it will delegate a lot of the rights to you. Grant list
access to the sql account down to the root of the data drive to alleviate
erroneous errors in the event log. (you can mitigate this by denying access
to this account on other folders). Most of all, have fun. You might learn
more about sql than you wanted to know!
Chris
"DBA72" <anonymous@discussions.microsoft.com> wrote in message
news:F5A2B7F6-4D03-4818-987C-FF515BA7F93F@microsoft.com...
> I know that microsoft recommends that the account that the SQL Service and
SQL Agent runs under should not be in the local administrators group of the
SQL Server. However, I have also seen various posts and websites where
people say this is actually ok to do and some people actually recommend it.
For example on the following site:
>
> http://vyaskn.tripod.com/sql_server_security_best_practices.htm
>
> The following is a quote from the site:
> "DBAs generally tend to run SQL Server service using a domain
administrator account. That is asking for trouble. A malicious SQL Server
user could take advantage of these domain admin privileges. Most of the
times, a local administrator account would be more than enough for SQL
Server service."
>
> It seems that if you do not put the account into the local administrators
group, there are a great deal of hoops that you need to jump through in
order to get all the sql functionality to work properly (for example,
replication). Does anyone have any opinion, caveat, or story to share about
setting the account up as a local admin?
- Next message: Sue Hoegemeier: "Re: Controlling Access"
- Previous message: DBA72: "SQL Server Service account rights"
- In reply to: DBA72: "SQL Server Service account rights"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
