I've done lots and lots of searching and I cant seem to find a simple answer, I assume it is because everyone's circumstances differs however;

We need to setup a few SQL servers for production and I am not too sure which SQL service accounts to use. The servers will be running SQL 2012 and a few 2008 R2. They will be on a domain and the domain is in 2008 mode and not 2008 r2 (so no MSA accounts I assume).

Local System Account? Local User Account? Locally created user account? Network Account? Domain Account? Virtual Accounts (not too sure I understand these)?

The SQL server will be backing up to a non-domain NAS so I will need to pass certain credentials to it. I'd also like to know which account to use if it doesn't need to access a domain or an external none-domain NAS server.

Sorry if the question is 'too' newbie.


  • The answer would depend on the result of balancing convenience vs. security. Do you need to create security boundaries between multiple SQL server instances on a single host? Do you need to make sure a rooted SQL server instance is not gaining local administrative rights? Do you have the manpower and know-how to manage / maintain multiple service accounts? Do you have the time for testing your specific databases' stored procedures in a restricted environment? – the-wabbit Feb 3 '14 at 7:32
  • Security between multiple SQL instances is not necessary. I'm not too sure what you mean by a rooted SQL service not gaining administrative rights. Yes, we can manage multiple accounts should it be the best practice. Yes, we have time to test our databases - thanks! – dqnet Feb 3 '14 at 13:24
  • The "rooted" part is about an attacker's ability to take over the entire system in case of a security breach in your SQL server instance. It might not be that much of a concern if you have dedicated OS environments per SQL server instance, but an unprivileged account will save you some headache nonetheless when doing security considerations. OTOH, it might take more testing time and be unsupported by the application's vendor. Go with Katherine's answer, if you feel you can cope with the accompanying manageability issues. – the-wabbit Feb 3 '14 at 14:36

Most of the places I've worked have used a domain account that is otherwise unprivileged, although I've also worked places that used a local account that is otherwise unprivileged. My understanding is that this is pretty standard practice. If you google, you can find a lot of articles explaining why not to use local system, but they generally boil down to "it's too powerful, SQL doesn't need it, and if your SQL server is compromised They [TM] now have local system."

In short, I'd recommend one or more unprivileged domain accounts (depending on how many people are going to know them/how compartmentalized you need your installs to be). I recommend a domain account over a local account not only because of the ease of administration but also for credential lookups when you use integrated security.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.