Managed Service Accounts

by Mitchell Grande

Managed Service Accounts are a Windows feature introduced in Windows Server 2008 R2 for increasing the security of non-user service accounts. Managed Service Accounts, shortened as MSAs, have an automatically-managed, complex password that removes the requirement of manually dealing with password rotation and security. In Server 2012, this feature was enhanced to group Managed Service Accounts, or gMSAs, which allows the use of these accounts on multiple servers at once.

MSA Advantages

The advantage to Managed Service Accounts is being able to use an Active Directory user account for service-related tasks while easily keeping that account's password secure. Previously, the passwords for service accounts were handled in one of two ways: either configuring the account to have a password that never expires or manually rotating the password prior to its expiration. The first option is a security issue. If that password were ever leaked accidentally, it would be valid indefinitely. The second option has a significant administrative overhead. Keeping a task list of expiring passwords and going through the process of changing them and updating the related applications can be burdensome.

With MSAs and gMSAs, the password is managed by either the server using the account or by the AD DCs themselves. When configuring a service to use these accounts, no password is required. Instead, the password field is left blank, the system detects that it's an MSA or gMSA, and handles it appropriately. MSAs and gMSAs are supported for the following uses:

Windows Services

Scheduled Tasks

IIS Application Pools

Other, non-native applications that have support built-in

Using Group Managed Service Accounts

Since most scenarios require a service account to be used on multiple servers, we are going to focus on group Managed Service Accounts. You can still use these on just one server, but you have the option of using them on additional servers later if required. Since this is a well-documented process, we won't go into the specific steps here. Instead, here is an overview:

Initial setup steps - done only once for each domain

Introduce Windows Server 2012 or later DCs into the domain

Using PowerShell, create a KDS root key on a 2012 or later DC. The KDS root key is required for the DCs to retrieve the gMSA password when a server requests it

gMSA steps - to be done each time a gMSA is created

Identify the servers that the account will be used on

On a 2012 or later DC, create the gMSA using PowerShell, specifying the list of servers that will be allowed to use the account

Install the AD PowerShell feature on each server that will use the account

Using PowerShell, install the gMSA onto the servers that will be using it to allow them to retrieve the password automatically

Configure the service, scheduled task, or IIS App Pool with the service account

If required, grant the service account additional permissions, such as the "Log on as a batch job" right if it's a scheduled task

Once configured, group Managed Service Accounts can be granted system permissions or access to network resources just like a regular user account.

Example Uses

Here are some screenshots showing how and where gMSAs can be used:

Windows Services:

Configuring a service to use a gMSA:

Viewing a service configured to use a gMSA:

Scheduled Tasks:

Creating the task (must be done via PowerShell to use the gMSA):

Viewing the task in the task scheduler MMC:

Granting NTFS permissions (if the account needs access to a share for example):

Get Started!

Overall, Managed Service Accounts provide numerous benefits and are fairly easy to set up. The next time you have to configure a service, scheduled task, or IIS Application to run with a user account, considering using an MSA instead. Note that even if you can run a service with an MSA or gMSA not all applications will be fully supported. For example, SQL Server only supports gMSA in 2014 or later.