sql services

do the below look OK/appropriate.. are any of the service accounts not best?

i see in
http://social.msdn.microsoft.com/Forums/en-US/sqlsecurity/thread/2986a020-b1bd-46a9-8f97-dbd439664f6a/
that locaservice is not a good idea..
sa.jpg
LVL 5
25112Asked:
Who is Participating?
 
dqmqConnect With a Mentor Commented:
It says LocalService MUST not be used for SQL Server Agent. That's not the same account as LocalSystem, which is shown in your graphic.  
0
 
25112Author Commented:
OK I see what you are saying.. other than that, are all the other services ok/appropriate?
0
 
JHolycloudConnect With a Mentor Commented:
They seem ok, as long as you don't use the SQL Server in a domain. If your SQL Server is a part of a domain, you should consider to change the service using domain user account.
Because by using local system account, you'll have problem when you need SQL Server to access other computer in your network/domain.
0
Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

 
dqmqConnect With a Mentor Commented:
That's a workable approach, but not considered extremely secure.  The reason being that those accounts are shared by other packages and whoever administers those packages gains a free ride to SQL Server resources.

For stronger security, it's preferable to use special service accounts with strong passwords.  Dedicate a different local windows account for each running service. If you are running Windows Server 2008 R2, then you can use the Managed Service Account feature to administer the service accounts from active directory.
0
 
25112Author Commented:
OK-
JHolycloud - you are recommending a domain account and dqmq would recommend a local account, is that right? (just trying to make sure I understand correctly)

dqmq : the following says Managed Service Account not applicable for SS?
http://technet.microsoft.com/en-us/library/ff641729%28WS.10%29.aspx
0
 
mastooConnect With a Mentor Commented:
Using a domain account for sql can be more convenient but is less secure.
0
 
25112Author Commented:
>>For stronger security, it's preferable to use special service accounts with strong passwords
what are these special service accounts?
0
 
25112Author Commented:
>>Using a domain account for sql can be more convenient but is less secure.
what is the alternative you would suggest ? local accounts or OS default accounts (local service etc)
0
 
mastooConnect With a Mentor Commented:
My book I use for all things sql server says "it depends".  At the most secure end, you're using separate accounts for each sevice and each is tailored to have the minimum requirements.  I don't carry it that far, so I'm just suggesting don't grant your sql engine network permissions unless it is really a requirement.  In our case, sql has no business talking to the network although sql agent needs to on a few servers.  If network isn't required, you could use a local account or a fairly restricted domain account.
0
 
dqmqConnect With a Mentor Commented:
>what are these special service accounts?

Local Accounts that you create and dedicate to the service.  Each has the minimal set of permissions it needs to do it's job and is independent from other service accounts.  If you use configuration manager to assign the account to the service, then configuration manager will take care of the permissions.
0
 
25112Author Commented:
mastoo, if the app server needs to access sql server, then it is needing network, right? your app and db are on the same server? and hence not needing network?
0
 
25112Author Commented:
   >>Local Accounts that you create and dedicate to the service.
you are referring to one of the below?
LocalService
    NetworkService
    LocalSystem

can they still be able to work domain wide communication to other servers for data transfers?
0
 
mastooConnect With a Mentor Commented:
Even if your app server is a different server, your sql engine doesn't need network credentials.  It would just be "outbound" things from sql that would necessitate network credentials.

And for your other question, NEtworkService and LocalSystem refer to built-in accounts.  The term "Local Accounts that you create and dedicate" means you create a "user" on the server and that user is specifically used by one of the sql services.  This gives you a high level of isolation for each service, which makes security people feel good.
0
 
dqmqConnect With a Mentor Commented:
>you are referring to one of the below?
    LocalService
    NetworkService
    LocalSystem
No, those are built-in, shared accounts.

I am referring to special accounts that YOU create and dedicate to a service.  Usually, they are named according a convention that includes the dbms server and service that they are supporting.
0
 
25112Author Commented:
mastoo, do you use built-in or dedicated accounts in your case - when you mentioned that you do not need network access for sql service account.

>> It would just be "outbound" things from sql that would necessitate network credentials.
app server initiates the request, right? so it will be 2-way always?

thanks for confirming, dqmq
0
 
mastooConnect With a Mentor Commented:
We're sort of inbetween.  We use one domain account for our sql agents that need network access, and the other sql services run under an account local to the server that we create during install (one local account per server).

Yes, app server sends questions to sql and sql responds with results and sql wouldn't require network credentials.  Our sql agent only requires a domain account for network access because some of the jobs are copying backup files over the network and things like that.
0
 
25112Author Commented:
thanks for the pro & con.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.