Using Managed Service Accounts (MSA and gMSA) in Active Directory | Windows OS Hub (2024)

You can use Managed Service Accounts (MSA) to securely run services, applications, and scheduler tasks on servers and workstations in an Active Directory domain. The MSA is a special type of account for which the AD generates a complex password (240 characters) and automatically changes the password every 30 days. MSA cannot be used for interactive login, the password is not known to anyone and is not stored on the local system (you cannot extract the password from the LSASS system process using mimikatz or similar tools). So to run services or automated jobs, you don’t have to create separate service users in AD and manage their passwords.

This article shows how to create MSA and gMSA accounts and use them to securely run services and scheduled tasks on Windows computers in an AD domain.

There are two types of service accounts in AD:

• Managed Service Accounts (MSA) – introduced in Windows Server 2008 R2 (msDS-ManagedServiceAccount object type). The main limitation is that such an account can only be used on a single server (it cannot be used to run cluster services);
• Group Managed Service Accounts (gMSA) – introduced in Windows Server 2012 (msDS-GroupManagedServiceAccount object type). You can use GMSA accounts on multiple Windows servers.

How to Create a Managed Account (MSA) in Active Directory

Before you start creating AD-managed service accounts,you must perform a one-time operation of creating a KDS root key on a domain controller with the KdsSvc service enabled. This key is used to generate the GMSA password.

Add-KdsRootKey –EffectiveImmediately

In this case, the key is created and becomes available 10 hours after the AD replication has finished.

Check that the KDS root key has been successfully created:
Get-KdsRootKey

Use the command to check the KDS key:

Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId

To create a new managed service account (MSA) in AD, use the command:

New-ADServiceAccount -Name msaMunSrv1 –RestrictToSingleComputer

Link your MSA service account to the target computer (to bind, the msDS-HostServiceAccount attribute is used in the computer account properties):

$Identity = Get-ADComputer -identity mun-srv01
Add-ADComputerServiceAccount -Identity $identity -ServiceAccount msaMunSrv1

Remember that you can only use one MSA account on one domain server.

Open the ADUC (Active Directory Users and Computers) console and make sure that a new account of type msDS-ManagedServiceAccount has appeared in CN=Managed Service Accounts container.

This AD container is hidden by default. To display it, enable the Advanced Features option in the View menu of the ADUC snap-in.

Create a Group Managed Service Account (gMSA) in Active Directory

Before creating the gMSA account, create a domain security group and add servers to it that will be allowed to use this service account. You can create and populate a group using PowerShell:

New-ADGroup grMunSQL1 -path 'OU=Groups,OU=Munich,OU=DE,dc=woshub,DC=com' -GroupScope Global -PassThru –Verbose
Add-AdGroupMember -Identity grMunSQL1 -Members mun-sql01$, mun-sql02$, mun-sql03$

Create a Group Managed Service Account (gMSA) and bind it to the grMunSQL1 security group:

New-ADServiceAccount -name gmsaMunSQL1 -DNSHostName gmsaMunSQL1.woshub.com -PrincipalsAllowedToRetrieveManagedPassword grMunSQL1 –verbose

The gMSA account is also created by default in the Managed Service Accounts OU. The msDS-GroupMSAMembership attribute in the gMSA account properties links an account to a Windows host or AD group.

Some services require a Service Principal Name (SPN) registration for Kerberos authentication to work correctly. Managed service accounts can be used for SPN registration:

setspn -s MSSQLSvc/munsql01 woshub\gmsaMunSQL1$
setspn -s MSSQLSvc/munsql01.woshub.loc woshub\gmsaMunSQL1$

Install Managed Service Account on Windows

To use MSA/gMSA service accounts on domain servers or workstations, you must first install the PowerShell module for Active Directory and the .NET Framework 3.5+:

Add-WindowsFeature RSAT-AD-PowerShell

Install the MSA service account on the server:

Install-ADServiceAccount -Identity gmsaMunSQL1

Check that the service account is properly installed:

Test-ADServiceAccount gmsaMunSQL1

If the command returns True, this service account can be used on this Windows host.

WARNING: Test failed for Managed Service Account gmsaMunSQL1. If standalone Managed Service Account, the account is linked to another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA.

You cannot use standard RunAs to check that your services and scripts can run under the MSA service account. Use the PsExec tool instead (previously we showed you how to use psexec to run the command prompt on behalf of NT Authority\System).

1. Open the command prompt as administrator;
2. Run the command: PsExec64.exe -i -u woshub\gmsaMunSQL1$ -p ~ cmd.exe

   The ~ symbol replaces the password. This means that the computer needs to get the account password from AD.

3. In the new cmd prompt, run the whoami command to ensure that the console is running under the gMSA account;
4. Make sure that any scripts, services, or applications that you require can run correctly under a managed service account.

The next step is to configure the necessary Windows services, scheduler jobs, IIS pools, etc. to run as an MSA or gMSA user.

How to Run a Windows Service as a Managed Service Account

Let’s look at configuring a specific Windows service to run under the AD-managed service account.

1. Open the service management console (services.msc);
2. Open the properties of the service you need and go to the “Log On” tab;
3. Select the This account option and enter the name of the MSA account. Add the $ symbol to the end of the account name (no password is required);
4. The MSA service account will be automatically granted Log On As a Service permissions;
5. Save the changes and restart the service.

To run an IIS application pool on behalf of the Managed Service Account, open the apppool Advanced Settings and change the Identity field from ApplicationPoolIdentity to Custom Account -> woshub\gmsaMunSQL1$ (leave the password field blank):

Or you can use PowerShell to specify the MSA account for the IIS application pool:

Import-Module WebAdministration
$pool = Get-Item IIS:\AppPools\wpad
$pool.processModel.identityType = 3
$pool.processModel.userName = "woshub\gmsaMunSQL1$"
$pool.processModel.password = ''
$pool | Set-Item

To run complex Windows services with gMSA, check the documentation to see if they are supported. Currently, gMSA is supported in SQL Server, IIS, AD LDS, and Exchange Server.

Run Windows Scheduled Task with Managed Service Account (gMSA)

You can configure the Windows Task Scheduler to run jobs under the MSA service account. This is convenient because the passwords for the MSA accounts are not explicitly stored in the scripts, and you do not need to encrypt or protect them. If the domain controller changes the service account password, there is no need to reconfigure the Task.

The only way to configure a scheduled task to run as a gMSA is by using PowerShell. For example, the following script creates a new scheduled task that runs a PowerShell script to backup the database every day at 11:00 pm:

$action = New-ScheduledTaskAction -Execute powershell.exe -Argument "-file C:\PS\Scripts\DBBackup.ps1 -executionpolicy bypass -NoProfile"
$trigger = New-ScheduledTaskTrigger -At 23:00 -Daily
$principal = New-ScheduledTaskPrincipal -UserID woshub\gmsaMunSQL1$ LogonType Password -RunLevel Highest
Register-ScheduledTask DBBackup –Action $action –Trigger $trigger –Principal $principal

You can also create a scheduled task with the necessary settings using the taskschd.msc GUI. Then reconfigure it to run under a Managed Service Account using the schtasks.exe console command:

schtasks /Change /TN BackupDB /RU "woshub\gmsaMunSQL1$" /RP ""

Grant the necessary service permissions and NTFS permissions on the file system to the MSA/gMSA account. For example, I added gMSA to the server’s local Backup Operators group:

Add-LocalGroupMember -Group "Backup Operators" -Member woshub\gmsaMunSQL1$

To run scheduler tasks, you must grant the gMSA account the Log on as a batch job permission. This can be done using the local GPO editor on a standalone computer: gpedit.msc -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment. Add an account to the policy: woshub\gmsaMunSQL1$