Eric Swanson on Technology Services

You either love or hate “Local Service”, “Network Service”, and “Local System”. Have you ever avoided setting up individual Service Accounts for SQL Server, IIS, SharePoint, or other enterprise applications and simply defaulted these built-in accounts? Perhaps you didn’t know that it’s “best practice” to use domain accounts for these services. Or, perhaps you knew and wanted to avoid the maintenance overhead of updating passwords constantly per company policy.

In my experience, what you use will vary based on the hat you like to wear most:

• IT Pro – Knows they should setup separate service accounts, but wants to avoid maintenance. So, they use the built-in accounts unless someone complains enough. Some may have even gotten smart about it and written scripts to automate account password updates every month.
• Developer – Ignore the opportunity to setup separate accounts, find the install process complicated or burdensome so they skip this step, or they don’t know better, so they setup the service to use one of the built-in accounts
• Security – Wants to use separate service accounts as a policy, but can’t seem to keep the IT Pro or Developer compliant!

In addition to this basic problem, separate environments for development, testing, staging, and production sometimes require different account credentials! All of this has been exacerbated in recent years by investments in clustering and virtualization. More servers with more services and more accounts to maintain…

In response to this problem, Microsoft released new features in Windows Server 2008 R2 and Windows 7 called Managed Service Accounts and Virtual Accounts.

Finally! Improve service isolation, increase account security, eliminate administration and support growth of your infrastructure! Read “What’s New in Service Accounts in Windows Server 2008 and Windows 7”.