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:

 Figure 2:

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.