In SQL Server 2012, service accounts are created as virtual accounts (VAs), as described here, as opposed to managed service accounts (MSAs).

The important differences I can see for these, based on the descriptions:

  • MSAs are domain accounts, VAs are local accounts
  • MSAs use automagic password management handled by AD, VAs have no passwords
  • in a Kerberos context, MSAs register SPNs automatically, VAs do not

Are there any other differences? If Kerberos is not in use, why would a DBA ever prefer an MSA?

UPDATE: Another user has noted a possible contradiction in the MS docs concerning VAs:

The virtual account is auto-managed, and the virtual account can access the network in a domain environment.


Virtual accounts cannot be authenticated to a remote location. All virtual accounts use the permission of machine account. Provision the machine account in the format <domain_name>\<computer_name>$.

What is the "machine account"? How/when/why does it get "provisioned"? What is the difference between "accessing the network in a domain environment" and "authenticating to a remote location [in a domain environment]"?

  • 1
    Your last paragraph added 4 more questions. S/O rules recommend one question per request. I can answer one of these questions: A "Machine account" is a local (NT) service account. Each machine has one. When you run a NT service as "System", it runs under this special local account. Since it is not managed by a domain, it can't really (inherently) be trusted by other machines in a domain. The account is automatically created when the OS is installed. It is a throw-back to the days of peer-to-peer networks.
    – TimG
    Commented Mar 25, 2014 at 20:03
  • So if "all virtual accounts use the permission of the machine account" then by this definition, it couldn't possibly "access the network in a domain environment".
    – jordanpg
    Commented Mar 25, 2014 at 21:05
  • 1
    (in my previous message, I left-out something). When a server joins a domain, the local "System" account gets mapped to a domain account <domain_name>\<computer_name>$. That account is an actual domain account.
    – TimG
    Commented Mar 26, 2014 at 13:50
  • I would say, it is not typical to use a machine account to "access the network in a domain environment". As you can imagine, it is pretty generic and therefore presents a generous back-door. You could grant permissions for that account, just like any other account, but it is discouraged.
    – TimG
    Commented Mar 26, 2014 at 13:52
  • It can't be all that atypical. VAs, which "use the permission of the machine account", are the default account type for almost all the MSSQL12 service accounts. Either MS left out a sentence like "however, it is not recommended to use VAs to access the network in a domain" or this is precisely what is intended. That is why I asked the question.
    – jordanpg
    Commented Mar 26, 2014 at 14:47

1 Answer 1


Here's the way I see it.

When you use a VA, you impersonate the machine account.

The problem is, that it is easy to make a VA or use an existing one (ex. NT Authority\NETWORKSERVICE). If you grant the machine account access to an instance, an application that is running as a VA will be able to connect to that instance and perform actions.

With a managed account, you will have to provide the credentials for that account to whatever application wants to use them, allowing you more granularity with permissions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.