Group Managed Service Accounts

Last updated: April 10, 2024
Audience: IT Staff / Technical

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. This document describes how to get started with them.

What is a gMSA?

A group managed service account is a user account that provides a number of capabilities not currently available from any NETID user account today:

  • automatic password management
    • strong password of 120 characters
    • password is unknown to any person
    • password changes automatically on a regular schedule
    • password change is automatically picked up by your application
    • credential can be used across multiple computers
  • automatic SPN registration

We believe that where they can be used, gMSAs are superior to any other option for unattended purposes, including application UW NetIDs.

Pre-Requisites

  • Need a Delegated OU. OU admins can create these in their OU
  • Need PowerShell to create and the AD PowerShell module needs to be installed
  • Windows Server 2012 (or equivalent1) computer in the NETID domain runs the application
  • Application/service must support group managed service account
  • Have a group with the computer(s) which run the application as members

How do I create a gMSA?

The general process for deploying a gMSA is as follows:

  1. Create group of NETID computers to associate with gMSA
  2. Create gMSA & associate with group from step #1
  3. Install the gMSA on the computer(s)
  4. Configure the service, IIS app pool, or scheduled task to use the gMSA

Let’s look more closely at those steps.

  1. In the Groups Service, you’ll create a new group that has a membership of exactly the computers which are allowed to retrieve the password of the gMSA. Do create a group even if there is a single computer as the member. We suggest you make your _oucontacts group the administrator of this group, but that isn’t required. The group members will be the computers where your application/service/task runs. NETID computers as group members have been supported by the Groups service for years, but not many folks know about it or how to use it. To add a UWWI computer as a member, enter something like “w:vader$”. The “w:” tells the Groups service that what follows is a NETID computer. However, you can skip that prefix and the Groups service will figure it out as long as you append the $ character on the end. The $ character is key–you must specify that. And you must use the netbios name of the computer–not the fully qualified DNS name of the computer. If the computer was recently added to the domain, you might be told the NETID computer isn’t a valid member3.
  2. Pick a name for your gMSA. It must have a prefix of your delegated OU name plus a hyphen. For example, “pottery-mygmsa”. Then from a computer with PowerShell2 run the following using a delegated OU admin account:

    New-ADServiceAccount -name <gMSAName> -DNSHostName <fqdn> -PrincipalsAllowedToRetrieveManagedPassword < group> -ServicePrincipalNames <SPN1,SPN2,…> -Path <your OU’s DN>

    DNSHostName parameter: You’ll want to supply the fully qualified DNS name for the service you are using the gMSA with. This will ensure that SPNs will automatically be registered and updated. If you aren’t using a service that needs Kerberos, then you can supply any value there you want, but it should still follow the NETID computer namespace guidelines.

    PrincipalsAllowedToRetrieveManagedPassword parameter: You’ll want to supply the name of the group you created in step #1.

    ServicePrincipalNames parameter: This is optional. Include if you need to specify special SPNs different than the DNSHostName parameter.

    Path parameter: You’ll need4 to supply the distinguished name of your delegated OU. That’ll look like: OU=pottery,OU=Delegated,DC=netid,DC=washington,DC=edu. Replace pottery with your OU. Or if you want to put all your gMSAs in an OU by themselves, then create an OU and use the path to that instead.

    There are other optional parameters which you can employ, if needed. These will add some complexity, so be careful.

  3. On the Windows Server 2012 (or equivalent) computers you plan to use the gMSA on, run the following powershell (you may need to reboot the server first):

    Install-AdServiceAccount <gMSAName>
    Test-AdServiceAccount <gMSAName>

    The last command should return “True”

  4. What is required to configure your application to use the gMSA depends on the use case. In general, you’ll grant the required user rights and permissions needed, then setup the application to run as that gMSA. Here are the common use cases:
    1. Services:
      First, grant the gMSA the ‘log on as a service’ user right and add it to any local groups or grant it permissions as needed.
      Second, in the Services UI, enter:
      username: “NETID\<gMSA>$”
      password: <blank>
      confirm password: <blank>The computer will then retrieve the password from AD.
    2. Scheduled Task:
      First, grant the gMSA the ‘log on as a batch job’ user right and add it to any local groups or grant it permissions as needed.
      Second, use PowerShell to create the scheduled task. You can NOT use the Task Scheduler UI to create or edit the task!!

      $action = New-ScheduledTaskAction “c:\scripts\backup.cmd”
      $trigger = New-ScheduledTaskTrigger -At 23:00 -Daily
      $principal = New-ScheduledTaskPrincipal -UserID child\myAdminAccount$ -LogonType Password

      NOTE: Password in line above means that you literally type “Password”

      Register-ScheduledTask myAdminTask –Action $action –Trigger $trigger –Principal $principal

      The computer will then retrieve the password from AD.
      Third, optionally you can use the Task Scheduler GUI to manually launch the task to test it out.

      If your task action is a powershell script, you will need something like:

      $action = New-ScheduledTaskAction “powershell” -Argument “-file `”c:\bin\action-noun.ps1`“”

      The UI is more forgiving and auto-corrects parameters. Without the UI, if you don’t separate out the parameter, you’ll end up with an error 2147942487 when you run the task.

How do I deprovision a gMSA?

OU Admins SHOULD delete unused gMSAs. When a gMSA is no longer used on a computer, OU Admins SHOULD remove that computer from the group allowed to retrieve that gMSA password and also remove the cached gMSA password from that computer.

To delete a gMSA, locate it within your delegated OU and delete it. An OU administrator is required to perform this task.

When a gMSA is no longer used on a computer

  1. Go to the groups service, locate the group, and remove the NETID computer as a member.
  2. Go to the computer and run the following PowerShell commands:

    Uninstall-ADServiceAccount <gMSA>
    Test-AdServiceAccount <gMSA>

    The last line should return False.

For a given gMSA, I forgot which group I allowed to retrieve the password. How do I figure that out?

To avoid this, you may want to setup a scheme by which your group name corresponds to your gMSA name. But there will inevitably be cases where that doesn’t work out, so from PowerShell:

Get-ADServiceAccount -identity <gMSA name> -properties principalsallowedtoretrievemanagedpassword

Management Tips

You may want to stick all of your gMSAs in a separate sub OU so they are easy to find later. Or have a good way to easily search your OU and find them all.

Review your gMSAs on some periodic basis–say once a year revisit them all to make sure they are all still needed and delete the ones that are no longer in use.

You may want to employ a consistent group naming pattern for the groups associated with your gMSAs. If you need a group naming pattern idea, here’s one:

<group service stem>_gmsa_<gmsa name>

As an example of these suggestions, for the MI service, we have:

OU=gMSAs,OU=UWWI,OU=uwit,OU=Delegated,DC=netid,DC=washington,DC=edu

with two gMSAs in it:

uwit-fim-runs
mi-testgmsa

and the following associated groups:

u_windowsinfrastructure_gmsa_uwit-fim-runs
u_windowsinfrastructure_gmsa_mi-testgmsa

Can I put a gMSA in a Groups Service group?

Yes. gMSAs are technically a sub-class of computer objects. So the Groups Service understands them to be NETID computer objects. You’ll need to specify “w:<gMSA name>$”, e.g. “w:uwit-fim-runs$” for the gMSA named uwit-fim-runs.

Example Applications that Support or Don’t Support gMSAs

SQL 2012 supports gMSAs.

You can use a gMSA on each of the nodes in a cluster, but you can’t yet use it for the account running the Windows Cluster service–that’d be one of those apps/services that doesn’t yet support gMSAs.

How to Get the AD PowerShell Module Installed

Open Add Roles and Features. Under Features, find RSAT, and select the sub-component named Active Directory module for Windows PowerShell. It doesn’t require a reboot.

Useful References

1. Equivalent to Windows Server 2012: Windows 8, Windows 8.1, Windows Server 2012 R2, or newer releases of Windows.↩
2. Running the above PowerShell cmdlets from an elevated PowerShell session will require the AD PowerShell module to be installed.↩
3. If you recently added a computer account to the NETID domain, then it likely will not be available as a group member yet. Wait until the top or bottom of the hour after you added the computer account and try again. If it still fails, report it as an issue.↩
4. If you don’t include the path parameter, your gMSA will be created in a location where your fellow OU admins can’t manage it. That’s not good. You, as the creator/owner, will still be able to make some changes, which include moving it to your OU. If you make a mistake, look for the gMSA at: CN=Managed Service Accounts,DC=netid,DC=washington,DC=edu. Then move it to your OU.↩