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.
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
MSA & gMSA: Domain controller with Microsoft Key Distribution Service (KdsSvc) enabled
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
To begin, we create a KDS root key. This is a one-time operation.
To do so, on the domain controller, we run:
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:
Then we use the below command to check the KDS key:
Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId
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:
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.
To use MSA/gMSA service accounts on target servers or workstations, we need to install the Active Directory PowerShell module:
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:
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.
Currently, SQL Server, IIS, AD LDS, and Exchange Server support 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 ""
This article covers how to use gMSA in Active Directory. When a gMSA is used as service principals, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password. Group Managed Service Accounts (gMSAs) provide a higher security option for non-interactive applications/services/processes/tasks that run automatically but need a security credential.
The Install-ADServiceAccount cmdlet installs an existing Active Directory managed service account on the computer on which the cmdlet is run. The cmdlet also makes the required changes locally so that the managed service account password can be managed without requiring any user action.