Group managed service account -gMSA

Question

Group managed service account -gMSA

SAGA 45

Hi Team,

We would like to setup the gMSA to enhance the security for service accounts.

Root key is already setup , want to know if we have to configure the task scheduler, services or any other windows related requirement do we need to use powershell only , wont it possible to use gui to update the account. when we try to update n task scheduler gui with serviceaccountname$ and save it says task scheduler cannot apply your changes.

Also in the target server is it mandatory to enable the ad powershell module to install the gmsa and to configure? could you give some insight and command to configure schedule tasks and services etc

0 comments

3 answers

Your answer

Answer 1

VPHAN 33,910 Independent Advisor

Hi SAGA,

How is your issue going? Has it been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

VP

0 comments

Answer 2

Hi SAGA,

To use a Group Managed Service Account on a target server, you must first provision it locally so the operating system knows how to automatically retrieve the password from Active Directory. Doing this does require the Active Directory PowerShell module to be present on the target host. You can easily add this by running the Install-WindowsFeature RSAT-AD-PowerShell command in an elevated prompt. Once the module is available, executing Install-ADServiceAccount -Identity "Domain\YourgMSA$" registers the account with the local Netlogon service.

Configuring the account for standard Windows services is straightforward and fully supported in the graphical interface. You can open the services.msc console, locate your specific service, and enter your account in the DOMAIN\AccountName$ format on the Log On tab. The system will automatically pre-fill placeholder dots in the password fields, which you must completely highlight and delete so both boxes are entirely empty before applying the changes.

Task Scheduler handles Group Managed Service Accounts differently and frequently rejects them through the graphical interface with the exact application error you encountered. Microsoft highly recommends using PowerShell to assign a managed service account to a scheduled task to bypass these legacy credential checks. You will need to use the New-ScheduledTaskPrincipal cmdlet, defining the -UserId as your managed account and specifically setting the -LogonType to Password. While selecting a password logon type seems counterintuitive for an account where you do not know the password, it is the required operational parameter to instruct the task to fetch the credentials dynamically from Netlogon. You then pass this principal object into the Register-ScheduledTask cmdlet to finalize the configuration without being prompted for manual credentials.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP

Answer 3

gMSAs can be configured using both PowerShell and GUI, but PowerShell is required for creating and installing the gMSA itself. GUI can then be used to assign the gMSA to services, IIS app pools, and scheduled tasks.

Creating and managing the gMSA (PowerShell only)

Creation and core management of a gMSA are done with the Active Directory PowerShell module on a machine with RSAT or on a domain controller:

Create KDS root key (already done in this environment, but for completeness):
```
    Add-KdsRootKey -EffectiveImmediately
```

Create a gMSA (example):

    New-ADServiceAccount -Name "MyGmsa$" `
      -DNSHostName "MyGmsa.domain.com" `
      -PrincipalsAllowedToRetrieveManagedPassword "MyGmsaHostsGroup"

Verify and inspect the gMSA:

    Test-ADServiceAccount -Identity "MyGmsa$"
    Get-ADServiceAccount -Identity "MyGmsa$" | Select-Object *

The AD module is required somewhere in the environment (DC or management server) to run New-ADServiceAccount, Set-ADServiceAccount, etc.

Installing the gMSA on target servers

On each server that will run services or tasks under the gMSA, the gMSA must be installed locally using the AD module:
```
  Install-ADServiceAccount -Identity "MyGmsa$"
```
This step must be run on the target server itself. The AD PowerShell module is therefore required on that server (typically via RSAT if it is not a domain controller).
After installation, Windows can use the gMSA for services, IIS app pools, and scheduled tasks.

Using GUI vs PowerShell for services and scheduled tasks

Services (Service Control Manager)

After Install-ADServiceAccount has been run on the server, the service identity can be changed via GUI:
1. Open services.msc.
2. Open the properties of the target service.
3. Go to the Log On tab.
4. Enter the gMSA name in the form DOMAIN\MyGmsa$.
5. Leave the password fields blank (gMSAs do not require a manually entered password).
6. Apply and restart the service.
This is the same pattern used by the On-premises data gateway example, where the service logon is updated to a gMSA in the Services GUI and the password is left empty.

Scheduled tasks (Task Scheduler)

gMSAs are supported for scheduled tasks that use Task Scheduler.
After Install-ADServiceAccount on the server, a task can be configured via GUI:
1. Open Task Scheduler.
2. Create or edit a task.
3. On the General tab, set When running the task, use the following user account to DOMAIN\MyGmsa$.
4. Do not specify a password when prompted (for gMSAs, Windows manages the password).
Task Scheduler is explicitly listed as a supported consumer of gMSAs.

Using PowerShell to configure services and tasks (optional)

If desired, PowerShell can also be used to set the logon account for services or to create scheduled tasks, but it is not mandatory if GUI is preferred.
Example pattern (conceptual) for services: use sc.exe config or Set-Service with the gMSA account name DOMAIN\MyGmsa$ and no password.
Example pattern for scheduled tasks: use Register-ScheduledTask with a principal that specifies the gMSA account.

Windows / AD requirements and considerations

Prerequisites for gMSA usage include:
- Domain functional level and schema that support gMSAs (Windows Server 2012 or later for gMSAs).
- Hosts must support the Kerberos encryption types required by gMSA; AES should be configured for MSAs.
- All systems that log on as, or install using, a gMSA must support these Kerberos encryption types; otherwise logon or installation fails.
The AD module (via RSAT or on a DC) is required to:
- Create the KDS root key.
- Create and manage the gMSA (New-ADServiceAccount, Set-ADServiceAccount, etc.).
- Install and test the gMSA on each host (Install-ADServiceAccount, Test-ADServiceAccount).

Summary

PowerShell with the AD module is mandatory for:
- Creating the gMSA in Active Directory.
- Installing the gMSA on each target server.
GUI can be used on the target server to:
- Configure Windows services (Services MMC) to run under the gMSA.
- Configure scheduled tasks (Task Scheduler) to run under the gMSA.
When using the gMSA in GUI, always include the trailing $ in the account name and do not enter a password.

References:

Share via

Group managed service account -gMSA

3 answers

Your answer