Problem solve Get help with specific problems with your technologies, process and projects.

Run SQL Server as a domain account for network access

Security-conscious administrators tend to run SQL Server with reduced privileges -- but don't make those privileges too restrictive or you may find SQL Server unusable.

Like many services, SQL Server and the SQL Server Agent can run in a variety of account contexts. By default, both...

SQL Server and the Agent are installed in the Local System Account context. However, Microsoft notes in one of its own discussions that the Local System Account is provided for backward compatibility only, and it has privileges that SQL Server Agent (and perhaps SQL Server itself) does not require.

For that reason, many security-conscious administrators elect to run SQL Server and SQL Server Agent in a reduced-privilege context. Unfortunately, they sometimes choose a context that's too restricted, especially if SQL Server or the Agent needs to make network connections to or from another host (such as a database server). An account that's too restrictive will prevent SQL Server from accessing the network at all and may make it almost unusable. This applies to both TCP/IP and Named Pipes protocols, since Named Pipes uses the protected IPC$ network share resources.

If you recently changed credentials for SQL Server and have trouble getting the service to authenticate network connections, start checking account permissions. Microsoft recommends creating a domain user account that has no administrative rights but can access the network. If you switched SQL Server to a domain user account, but didn't grant that account type access to the network as an inherited privilege, make sure you explicitly grant that permission and see what happens. (The only other caveat with using a domain account is that the account has to be authenticated on a domain controller.)

About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!

More information from

  • Tip: Setting up SQL Server clusters on a SAN
  • Undocumented DBCC: Report on settings with DBCC RESOURCE>
  • Stored procedure: Examining SQL Agent job run history

  • This was last published in April 2006

    Dig Deeper on SQL Server Security

    Start the conversation

    Send me notifications when other members comment.

    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

    Please create a username to comment.