What user account would you recommend running the SQL Server Express 2008 services in a development environment?

Question

The SQL Server Express 2008 setup allow you to assign different user account for each service.

For a development environment, would you use a domain user, local user, NT Authority\NETWORK SERCVICE, NT Authority\Local System or some other account and why?

Answer 1

It depends.

• Local System - Never, it's too high a privilege.
• Network Service - Perhaps, if you need to connect to network resources, but that's doubtful.
• Local Service - Probably the best choice, limited privileges, do not unlock network connections
• Local interactive user? Does it truly need to have login rights, or act as a user?
• Domain user? Goodness no, not unless you're accessing network drives from within it; if SQL runs amok then an attacker is authenticated against the domain.

Answer 2

Whatever it wants to use as default. Changing that is just asking for trouble later.

Answer 3

Local System is not recommended, it is an administrator equivalent account and thus can lead to questionable coding that takes advantage of administrator privileges which would not be allowed in a production system since security conscious Admins/DBA's really don't like to run services as admin.

Depending on if the server instance will need to access other domain resources or not should determine which type of low privilege account it should run under.

If it does not need to access any (non-anonymous) domain resources than I normally create a unique local, low privilege account for it to run under in order to gain the additional security benefit of not having multiple services running in the same identity context. Otherwise Local Service is also acceptable as it is a low privilege account without network credentials.

If it does need to access non-anonymous domain resources then you have three options: 1. run as Network Service which is also a low privilege account but one that retains the computers network credentials, 2. run under the local developers credentials, this is only a viable solution if the developer is not a local admin (see the above point on Local System for why it would not be good if the developer is local admin) or 3. run under a custom domain account with low local privileges. One advantage to running under the developers account is that it is easier to attach debuggers to processes in your own identity without compromising security so debugging is easier (since non-Admin accounts do not have the privilege to attach a debugger to another identities process by default). A disadvantage to using another domain account is the overhead of managing those accounts, especially since each service for each developer should ideally have unique credentials so you do not have any leaks if a developer were to leave.

Most of what I tend to do does not require the service to access domain resources so I tend to use unique local low privilege accounts that I manage. I also run exclusively as a non-admin user (and have done so under XP SP2, Server 2003, Vista and Server 2008 with no major problems) so when I have cases where I need the service to access domain resources then I have no worries about using my own domain credentials (plus that way I don't have to worry the network admins about creating/maintaining a bunch of non-production domain identities).