A: Managed service accounts (MSAs) and virtual accounts, which Microsoft introduced in Windows 7 and Windows Server 2008 R2, overcome the password management problems you'll encounter if you use a custom domain or local account for authenticating a service. By using a custom account, you can better isolate the privileges of an application -- which isn't the case when you use one of the built-in high-privilege local accounts (i.e., Local System, Local Service, Network Service) as the service account.

But unlike these built-in local accounts, custom accounts don't have automatic password management. Therefore, when you use custom service accounts, you need to manually manage their passwords or create a custom solution for managing them. MSAs and virtual accounts resolve this problem by providing automatic password management.

MSAs are domain accounts and virtual accounts are local accounts. Besides automated password management, MSAs also provide simplified Service Principal Name (SPN) management. Services that run with virtual accounts can access network resources by using the identity and credentials of the local computer account.

The combination of MSAs or virtual accounts and service- specific SIDs provides the best least-privilege configuration option for a Windows service. MSAs and virtual accounts are the best least-privilege option for authenticating a service, and service-specific SIDs are the best least-privilege option for authorizing a service.

To use MSAs or virtual accounts, the client computer on which the application or service is installed must be running Server 2008 R2 or Windows 7. To ensure automatic MSA password management on a Windows domain controller (DC), your Active Directory (AD) schema must have been updated to Server 2008 R2.

There's no UI support for creating and managing MSAs. To configure and manage MSA for a service, you must use Windows PowerShell cmdlets. To have PowerShell support for creating MSAs in AD, you must install the .NET Framework and the AD module for PowerShell. To import the AD module for PowerShell, you use the Import-Module cmdlet as follows:

Import-Module ActiveDirectory

Setting up an MSA for a service requires four configuration steps. The first two steps affect AD for your domain; the last two steps are done against the domain machine where the service using the MSA will actually run.

To create a new MSA in AD, use the New-ADServiceAccount cmdlet, as follows:

New-ADServiceAccount -name newMSA -enabled $true

where newMSA is the name of the new MSA you create. You can then link the newly created MSA to the AD machine account of the machine where the service is installed. Note that an MSA can be linked to only a single machine that is a domain member and that runs Server 2008 R2, Windows 7, or a later Windows OS. To do so, you must use the Add-ADComputerServiceAccount cmdlet, as follows:

Add-ADComputerServiceAccount -identity myservicemachine -serviceaccount newMSA

where myservicemachine is the machine account name of the service machine. The service administrator must then install the MSA on the service machine. To do this, you must be a member of the local administrators group on the service machine and use the Install-ADServiceAccount cmdlet, as follows:

Install-ADServiceAccount -identity newMSA

Finally, you must configure the service or application to actually use the MSA for authentication. This step can be done in the service's properties that you can access from the Microsoft Management Console (MMC) Services snap-in. On the Log On tab, click This account and enter the MSA in the format domainname\accountname$. For the above example, you would use mydomain\newMSA$ (make sure you append a dollar sign at the end!). Leave the password fields blank.

Setting up a service to use a virtual account for authentication is much simpler. In this case, you can go straight to the MMC Services snap-in and configure the local virtual account by using the This account option on the Log On tab of the Service properties. Enter the virtual account in the format NT SERVICE\<servicename> -- where <servicename> is the actual name of the service. Again, leave the password fields blank.

You can find more details about MSAs and virtual accounts and how to manage and configure them in the Microsoft TechNet article "Service Accounts Step-by-Step Guide."