15

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.

versus

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]"?

Tom V
  • 15,670
  • 7
  • 63
  • 86
jordanpg
  • 355
  • 5
  • 14
  • 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 Mar 25 '14 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 Mar 25 '14 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 Mar 26 '14 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 Mar 26 '14 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 Mar 26 '14 at 14:47
  • Good point! Since this is the default (simplest) way of doing things, it probably looks like the correct way of doing it, to most people. – TimG Mar 26 '14 at 15:13

1 Answers1

4

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.

Nabil Becker
  • 441
  • 2
  • 6