Active Directory has what are known as group managed service accounts (a gMSA). The use case of a gMSA is to either run a Windows service or configure a Scheduled Task. Certain Windows services, like IIS webfarms, are gMSA aware, and can take advantage of these special service accounts.
The advantage of a gMSA is that you do not have to manage the password for it; it will periodically update it’s password automatically, and that password is unknown, providing extra security.
A gMSA can only be created by a Wolftech Domain Admin, so please request by submitting a ticket to ACTIVEDIRECTORY_TECHNICAL.
To create a gMSA, we’ll need a few details to complete the request.
- samAccountname : This is limited to 15 characters, and will need to include the departmental prefix and and an appropriate suffix (i.e. “.svc”)
- A departmental AD group that you will use to define the systems that will use the gMSA. While this group needs to exist, it does not have to be populated at gMSA creation time; you can add & remove systems as you need to. Systems in this group are allowed to retrieve the gMSA password from AD. Used in setting the “PrincipalsAllowedToRetrieveManagedPassword” attribute of the gMSA.
- DNSHostName : This is a required attribute of the gMSA, and we will, unless specified otherwise, use “<samAccountNamePrefix>.<dept>.ncsu.edu”. Should the <samAccountNamePrefix> (the part before .svc) contain periods, we’ll substitute dashes (“-“) for them, as periods have meaning in DNS hostname syntax.
- For the “KerberosEncryptionType” we are only using AES128, AES256
- We are using 90 days for ManagedPasswordIntervalInDays. This is compatible with most security guidelines. But, you don’t have to ever change it! Happens automatically.
- Optional : SPNs, or Service Principal Names. As mentioned, certain services are aware of gMSAs, and require SPNs to work correctly. If your particular use case needs SPNs, we can configure them as necessary.
After the gMSA is created, you’ll need to configure it on the target system. Configure the Local Policies / User Rights Assignments for the account with the “Log on as a service” or “Log on as a batch job” for either services use or for Task Scheduler use respectively.
First, ensure that you’ve added the computer account to the AD group specified with the gMSA. Depending on timing, the computer accounts Kerberos tickets need to reflect that they are indeed in the gMSA’s AD group.
Next, install the gMSA onto the system. Within an elevated/admin Powershell context, type:
- Install-AdServiceAccount <gMSA>
you can test success by:
- Test-AdServiceAccount <gMSA>
“True” is what hopefully returns. If not, then you may try a reboot of the system to ensure fresh Kerberos tickets for the system.
At this point, the gMSA is ready to be used on the system.
- Uninstall-ADServiceAccount <gMSA>
removes it from the system. You should also remove the system from the AD group as well.
To configure this gMSA for a Windows service, open the “Services” MMC, and specify this gMSA.
For Task Scheduler jobs, it’s a little more tricky. If you use the Task Scheduler GUI, it doesn’t see the gMSA when you try to specify it to run the task. We have to use Powershell.
Assuming you already have the Scheduled task configured as desired, but currently running under a different, undesired credentials, do the following:
- get-scheduledTask -TaskName “YourScheduledTask’sName”
This returns the TaskPath and TaskName parameters of your Scheduled Task. Now, lets define a variable with our gMSA’s credentials:
- $creds = New-ScheduledTaskPrincipal -UserId WOLFTECH\<gMSA>$ -LogonType Password
(yes, that parameter for “-LogonType” is literally “Password”. The process knows to retrieve the password from AD. You also do need that “$”)
Now, to set the credentials on the Scheduled Task:
- Set-ScheduledTask -TaskName “<from above>” -Taskpath “<from above>” -Principal $creds
And there you have it. Your Scheduled Task is configured to use the gMSA.
If you make any edits to the Scheduled Task, you’ll most likely have to configure the creds again.