Recently someone sent me a question about service accounts. They weren’t sure how they should go about setting accounts up for various instances and services in their environments. Specifically they asked me about having domain accounts, or accounts separate for services.

Note that I’ve managed SQL Server for years this way in environments up to hundreds of instances. I haven’t managed thousands, so there might be issues with this philosophy at scale.

Here’s how I view service accounts. In a short list, I try to manage things like this:

• Domain accounts for the SQL database engine and SQL Agent
• Separate accounts for all instances and all Agent services
• Long, complex, one-time passwords that aren’t stored.

This has worked well for me, providing separation of services so that password changes or security issues on one instance don’t affect other instances.

It’s also been scalable in that I rarely setup SQL Server instances. In most organizations I’ve worked in, we are adding a few instances a week at the most. The overhead to create two new accounts per instance (db engine and Agent) is minimal.

Note that I would also have a separate domain account for SSAS or other items I install.

With today’s rapid provisioning of machines through virtualized environments, I realize this isn’t necessarily a good hard and fast rule. If I expect an instance to be a production level instance and live for some period of time in the organization, I’d follow this philosophy.

However if I am bringing online development and test instances that may not be kept around permanently, I think the local service accounts are fine. These will probably handle your needs and are worth scripting into your VM/instance creation process.

I’ll add a few more thoughts on this across other posts, but there’s my idea in a nutshell.

Filed under: Blog Tagged: administration, sql server, syndicated