/ Insights / Managed Service Accounts Insights Managed Service Accounts March 21, 2019 Concurrency, Inc.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 AdvantagesThe 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 ServicesScheduled TasksIIS Application PoolsOther, non-native applications that have support built-inUsing Group Managed Service AccountsSince 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 domainIntroduce Windows Server 2012 or later DCs into the domainUsing 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 itgMSA steps – to be done each time a gMSA is createdIdentify the servers that the account will be used onOn a 2012 or later DC, create the gMSA using PowerShell, specifying the list of servers that will be allowed to use the accountInstall the AD PowerShell feature on each server that will use the accountUsing PowerShell, install the gMSA onto the servers that will be using it to allow them to retrieve the password automaticallyConfigure the service, scheduled task, or IIS App Pool with the service accountIf required, grant the service account additional permissions, such as the “Log on as a batch job” right if it’s a scheduled taskA detailed step-by-step guide is available on TechNet BlogsOnce configured, group Managed Service Accounts can be granted system permissions or access to network resources just like a regular user account.Example UsesHere 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.