SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Avoid Domain Admin level accounts for SQL Server

Every so often I see a post in the forums where someone has stated they've used a Domain Admin level account to run the SQL Server service. The implications are that anyone who is a member of the sysadmin fixed server role is effectively a domain admin. That means if a developer is a member of this role within SQL Server, the developer can use SQL Server to execute with these rights. The same is the case of a SQL Server DBA in production. Typically DBAs don't have domain admin rights unless it's a small shop. But if SQL Server is configured to run under a service account that has such rights, the DBA effectively is as well. Not good.

 In all but the rarest cases this is absolutely unnecessary. Truth be told, SQL Server doesn't even need administrative privileges over the server it's running on. Therefore, it certainly doesn't need Domain Admin rights. In security there is the Principle of Least Privilege. It's a simple concept: give only the rights needed to do the job and no more. This just doesn't apply to people, it also applies to service accounts. When it comes to SQL Server, this principle should be applied to the SQL Server service account just like any other.

How can you determine if your SQL Server is running under a Domain Admin account? First, determine what service account SQL Server is using. This can be done through SQL Server 2005 Configuration Manager (Figure 1) or SQL Server 2000 Enterprise Manager. You can also use the Services applet under Administrative Tools (Figure 2).

Figure 1:

Configuration Manager

 Figure 2:

Services applet

Once you know what the account is, check with your system or directory services administrator. If it's named [Domain]\Administrator, chances are likely that it is. If you have access to Active Directory Users and Computers, you can check the groups the service account is a member of (read access is all that's necessary and that's typically granted to all authenticated users in Active Directory). If you find the service account is a member of the Domain Admins group, do the research as to why. If there's a legitimate, unavoidable reason (and this should be extremely rare), seek to change the account immediately. This also applies to the SQL Server Agent service account.

Note: My snapshots are from a development laptop which isn't on a domain, hence the use of LocalSystem. Generally, though, LocalSystem isn't recommended and actually strongly suggested against. If this laptop had been on a domain, these accounts would be running under a local user account.

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.


Posted by shifty1981 on 9 February 2010

I seem to remember that when you do a SQL install it creates certain groups in Active Directory (in a domain environment). However my account does not have permission to create such groups. I am a local admin on the machine (my domain account is) however. Is this a concern? Exactly what type of permissions are required or recommended for the SQL Server 2008/2005 installer to be run as?

Thank you

Posted by Ken Sturgeon on 26 August 2010

If the SQL Sys Admin has been set up also as a Domain Admin and we were to remove Domain Admin rights, how would that affect SQL Server rolls and permissions? If, say, the acct. is a schema owner in SQL Server and the acct has privileges removed at the Domain Admin level, will processes be affected in SQL Server that call for that schema ownership?

Posted by dave-605818 on 13 June 2012

it would be nice if someone out there knew WHAT the domain user needs to be a member of. Admins? Schema operators? WHAT?!?!!?

Leave a Comment

Please register or log in to leave a comment.