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.
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
A detailed step-by-step guide is available on TechNet Blogs
Once configured, group Managed Service Accounts can be granted system permissions or access to network resources just like a regular user account.
Here are some screenshots showing how and where gMSAs can be used:
Configuring a service to use a gMSA:
Viewing a service configured to use a gMSA:
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):
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.