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.
A group managed service account is a user account that provides a number of capabilities not currently available from any NETID user account today:
We believe that where they can be used, gMSAs are superior to any other option for unattended purposes, including application UW NetIDs.
The general process for deploying a gMSA is as follows:
Let's look more closely at those steps.
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.
Install-AdServiceAccount <gMSAName> Test-AdServiceAccount <gMSAName>The last command should return "True"
$action = New-ScheduledTaskAction "c:\scripts\backup.cmd" $trigger = New-ScheduledTaskTrigger -At 23:00 -Daily $principal = New-ScheduledTaskPrincipal -UserID child\myAdminAccount$ -LogonType PasswordNOTE: Password in line above means that you literally type "Password"
Register-ScheduledTask myAdminTask -Action $action -Trigger $trigger -Principal $principalThe 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.
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
Uninstall-ADServiceAccount <gMSA> Test-AdServiceAccount <gMSA>The last line should return False.
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
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
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.
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.
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.
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.↩