The basic idea of Managed Service Account (MSA) is that Active Directory manages the password for these accounts.

MSA in Windows Server 2008 R2 could only use on one server. Therefore, Windows Server 2012 introduced Group Managed Service Accounts/gMSA.

We can use gMSA accounts simultaneously on multiple hosts.

Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to perform related Active Directory queries.

In this context, we shall look into using MSA and gMSA to launch services and tasks.

How to use gMSA in Active Directory ?

In order to use MSA/gMSA service accounts, we suggest having:

1. AD domain and forest functional level

MSA: Windows Server 2008 R2 or newer

gMSA: Windows Server 2012 or newer

2. KDC

MSA & gMSA: Domain controller with Microsoft Key Distribution Service (KdsSvc) enabled

3. PowerShell

MSA & gMSA: To create and manage service AD accounts, we need the Active Directory module for Windows PowerShell.

4. .Net Framework

MSA: .NET Framework 3.5 or newer on the server.

5. Supported Windows versions

MSA: Windows 7/Windows Server 2008 R2 or newer

gMSA: Windows Server 2012/Windows 8 or newer

How to Create the Key Distribution Service (KDS) Key ?

To begin, we create a KDS root key. This is a one-time operation.

To do so, on the domain controller, we run:

Add-KdsRootKey –EffectiveImmediately

Here, the key is available 10 hours after the AD replication is over.

To use the key immediately in the test environment, we run:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Ensure the successful creation of the KDS root key:

Get-KdsRootKey

Then we use the below command to check the KDS key:

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

How to Create a Managed MSA Account in Active Directory ?

To create a new MSA managed account in AD, we use:

New-ADServiceAccount -Name msaMunSrv1 –RestrictToSingleComputer

By default, MSA and gMSA are in the container CN=Managed Service Accounts. 

However, we can change the OU using the Path parameter.

Initially, we link our MSA service account to the target computer:

$Identity = Get-ADComputer -identity mun-srv01

Add-ADComputerServiceAccount -Identity $identity -ServiceAccount msaMunSrv1

We can only use the MSA account on one AD host.

Then we open the ADUC (Active Directory Users and Computers) console and make sure that a new account of type msDS-ManagedServiceAccount is in Managed Service Accounts container (OU).

By default, this AD container will be hidden. To see it, we enable Advanced Features in the View menu of the snap-in.

Then to get the MSA account info, we use:

Get-ADServiceAccount msaMunSrv1

How to Create a gMSA in Active Directory ?

Prior to the gMSA account, we create a domain security group. Then we add servers to it that will be allowed to use the password for this group service account.

To populate a group, the easiest way is using PowerShell:

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

Then to create a Group Managed Service Account (gMSA), we use:

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

The Managed Service Accounts OU, by default, will create the gMSA account.

How to Install gMSA on Windows ?

To use MSA/gMSA service accounts on target servers or workstations, we need to install the Active Directory PowerShell module:

Add-WindowsFeature RSAT-AD-PowerShell

Then we install the MSA (gMSA) service account on the server:

Install-ADServiceAccount -Identity gmsaMunSQL1

To check if the service account installation is correct, we use:

Test-ADServiceAccount gmsaMunSQL1

If the command returns True, everything is configured correctly.

If the command returns False, most likely we will receive the below warning:

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.

We cannot use standard RunAs to verify that our services and scripts can run under the MSA service account. However,

1. Open the command prompt as administrator.

2. Then we run the command:

PsExec64.exe -i -u ibmimedia\gmsaMunSQL1$ -p ~ cmd.exe

Replace the password with ~. This means that the password must be obtained from AD.

3. In the cmd window, we run the whoami command to make sure that the console is running under the gMSA account.

We verify if the scripts, programs, or services are running correctly under a Managed Service Account.

How to Run a Windows Service under a Managed Service Account ?

• Initially, we open the service management console (services.msc).
• Then we open the properties of the required service and go to the "Log On" tab.
• Select the "This account" option and enter the name of the MSA account.
• We make sure to add the $ symbol at the end of the account name.
• The MSA service account will automatically have "Log On As a Service" permissions.
• Once done, we restart the service.

Currently, SQL Server, IIS, AD LDS, and Exchange Server support gMSA.

How to Run Scheduled Task with Managed Service Account/gMSA ?

To run jobs under the gMSA service account, we configure the Windows Task Scheduler. This is convenient because the passwords are not scripts.

To grant permissions to the MSA/gMSA account, we have to add it to the required security group.

For example, to the local Administrators group, Domain Admins, DNS Admins, etc.

We can configure the task to run as the gMSA account using PowerShell.

For example, here, we will create a new scheduled task that runs a PowerShell script every day at 11:00 pm to backup the database:

$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 bobcares\gmsaMunSQL1$ -LogonType Password
Register-ScheduledTask DBBackup –Action $action –Trigger $trigger –Principal $principal

However, to run a scheduled task, we need to grant the gMSA account "Log on as a batch job" permission.

The '-LogonType Password' argument specifies that the password for this gMSA account will retrieve from the domain controller.

In addition, we can create a scheduled job of desired settings using the taskschd.msc GUI. Then we can reconfigure it using the schtasks.exe tool to run under a managed service account:

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

[Need help with fixing Active Directory configuration errors? We are available 24*7. ]