Introduction to group Managed Service Accounts

Blog Post created by lmlcoch on Apr 11, 2018

Although introduced in Windows Server 2012, the Group Managed Service Account (gMSA) still has low adoption within our customer base. This blog post aims to highlight benefits of gMSAs, discuss how to deploy and use them, and offer some tips & tricks.


Built-in accounts such as NetworkService or LocalSystem have decent password management, are simple to use, and can easily run a service or an Application Pool. However, outside the machine boundary, they take on the identity of their host machine (COMPUTERNAME$). This limits their usefulness outside the machine itself, as granting access to a computer object inevitably gives access to all other built-in identities on the computer (and all the services they're running!).

Many companies use standard domain accounts instead, but these accounts suffer from very poor password management (entropy, expiration/resetting, maintenance). Moreover, standard domain accounts' passwords are inevitably exposed to both users (who need to regularly interact with the passwords - typing or copy/pasting) and computers (passwords are stored locally).


gMSAs combine the best of both worlds: automatic password management with secure & centralized storage, while maintaining uniqueness outside the machine boundary. gMSA's password is calculated on-demand by Domain Controller (KDC) and automatic password changes are done periodically. In contrast to passwords used by standard domain user accounts, gMSA passwords are not stored locally on computers nor exposed to users.




gMSA vs. Standard Domain User - Practical Password Play


Sticky notes are awesome! Right?




gMSA password consists of 256 bytes of data, interpreted as 128 UF-16 characters. It is a constructed attribute calculated by the Domain Controller (KDC) on-demand.


Let's take a look using PowerShell:
# Download the DSInternals module

Save-Module DSInternals -Path C:\share


# Import the required modules

Import-Module ActiveDirectory

Import-Module C:\share\DSInternals\2.22\DSInternals.psd1


# Get the password blob – need to explicitly ask for the msDS-ManagedPassword attribute

$gmsa = Get-ADServiceAccount -Identity PVizgMSA -Properties msDS-ManagedPassword

$mp = $gmsa.'msDS-ManagedPassword'


# Convert the blob to Unicode string

$pw = ConvertFrom-ADManagedPasswordBlob $mp



This yields the actual Unicode string representation:



For more details, check out DSInternals’ post on retrieving cleartext gMSA passwords.



As an example, let's take a look at the two IIS Application Pools shown below - one is running under a standard domain user, while the other runs under a gMSA (an easy way to spot a gMSA is by the trailing $ character, much like a computer object).

Since the password of the standard domain user is stored locally on the server, a local administrator can obtain the password in plain text, which means there is no role separation between the service administrator and the local computer administrator! The gMSA password, on the other hand, is not stored locally on the server and therefore can't be retrieved.



In this case, we’ve read the standard domain user password from applicationHost.config file.


But it’s the same story with Windows services. The only difference is that the passwords are stored in the registry (within HKEY_LOCAL_MACHINE\SECURITY hive) rather than in a .config file:




While we’re on the topic of passwords, I would be remiss if I didn't mention mimikatz - the Swiss Army Knife of Windows Authentication. We’ll cover mimikatz and attacks on credentials (pass-the-hash, pass-the-ticket, plus mitigation and detection strategies) in a future blog post.


gMSA Passwords – main takeaways:

  • Incredibly high entropy making brute force attacks impossible
  • gMSA is denied interactive logon, so even with the raw data for the password, capabilities for using it are limited

  • Obscure characters in the gMSA password natively protect against mismanagement or accidental leakage


While gMSAs provide some hardening and additional security against credential theft, they do not address all threats. Deploy gMSAs to complement other security best practices such as least privilege.




gMSA – Provisioning and deployment



  • Windows Server 2012+ on at least one Domain Controller.
    • Functional Level of the domain must be at least 2003, but 2008 R2+ is recommended.
  • Windows Server 2012+ OS installed on the machines hosting services that will use the gMSA.
  • Key Distribution Service (KDS) Root Key must exist to enable gMSA creation.
    • Microsoft strongly recommends using a single KDS Root Key. See the documentation for more details.


To create the KDS Root Key, run PowerShell command:
If (-Not (Get-KdsRootKey)) {




By default, it takes 10 hours until the KDS Root Key is in effect (this is to provide sufficient time to replicate the key in large domains). However, in a test environment, we can force it to come into play immediately:

If (-Not (Get-KdsRootKey)) {

Add-KdsRootKey -effectivetime ((get-date).addhours(-10))



Next, use New-ADServiceAccount PowerShell cmdlet and specify (at least):
Name gMSA account name (must be fewer than 15 characters)
DNSHostName gMSA DNS account name (FQDN of the gMSA)
PrincipalsAllowedToRetrieveManagedPassword Principals allowed to obtain gMSA’s password. For manageability, it’s best practice to create a Domain Group (type: Security) and add the machines hosting services the that will run under the gMSA. However, it’s also possible to specify the computer(s) directly.


Optionally, specify other parameters such as ServicePrincipalNames and PrincipalsAllowedToDelegateToAccount, to configure Kerberos Authentication (SPNs) and Kerberos Delegation upon gMSA creation. To change the default password reset period (30 days), use ManagedPasswordIntervalInDays parameter.

Recommendation: Read the official New-ADServiceAccount cmdlet documentation before proceeding further.


Example 1:

The steps outlined below create a gMSA called PIVizgMSA, designed to run PI Vision Application Pools on two servers (piviz1 and piviz2). The appropriate Service Principal Names are created as well.


1. Create a domain group called PI Vision Servers and add piviz1 and piviz2 computers into the group.


2. Create the gMSA: (execute the command in an elevated PowerShell console on your Domain Controller)

New-ADServiceAccount -Name PIVizgMSA -DNSHostName PIVizgMSA.domain.local -PrincipalsAllowedToRetrieveManagedPassword "PI Vision Servers" -ServicePrincipalNames http/piviz1, http/piviz1.domain.local, http/piviz2, http/piviz2.domain.local


3. Remove all Kerberos Tickets from LocalSystem session on piviz1 and piviz2 computers by running klist -li 0x3e7 purge command in an elevated Command Prompt (alternatively, restart both computers). This is only required because a Domain Group was specified as the value for the PrincipalsAllowedToRetrieveManagedPassword parameter. If the machines were specified directly (i.e. -PrincipalsAllowedToRetrieveManagedPassword piviz01$, piviz02$), there’s no need to update Kerberos tickets (restart the machines).


4. Optional: Allow the account to write its own Service Principal Names – useful for services that support automatic SPN registrations such as PI Data Archive, PI AF Server or MS SQL Server.

(execute the command in an elevated PowerShell console on your Domain Controller)

$gMSA = Get-ADServiceAccount -Identity PIVizgMSA

dsacls $gMSA.DistinguishedName /G "SELF:RPWP;servicePrincipalName"


5. Use the gMSA to run PI Vision AppPools on the target machines (piviz1 and piviz2). Use it in the same way as a standard Domain User, just don’t specify the password (make sure the Password box is empty) and let the computer retrieve the password.



Example 2:

The steps outlined below create gMSA called AFgMSA, designed to run AF Server service on machine piaf01. Included are the appropriate SPNs and configuration of Kerberos Constrained Delegation (Resource Based Kerberos Delegation in this case) – where the PI Vision gMSA created in Example 1 (PIVisionGMSA) will be allowed to delegate to the AF Server piaf01 running under AFgMSA$.


1. Create the gMSA:

New-ADServiceAccount -Name AFgMSA -DNSHostName AFgMSA.domain.local -PrincipalsAllowedToRetrieveManagedPassword piaf01$ -ServicePrincipalNames afserver/piaf01, afserver/piaf01.domain.local -PrincipalsAllowedToDelegateToAccount PIVisionGMSA$



2. Allow the account to write its own Service Principal Names – AF Server supports automatic SPN registration:

$gMSA = Get-ADServiceAccount -Identity AFgMSA

dsacls $gMSA.DistinguishedName /G "SELF:RPWP;servicePrincipalName"


3. Use the gMSA on the target machine.



Example 3:

The steps outlined below create a gMSA designed for PI Web API service running on machine piweb01, including appropriate SPNs and configuration of Kerberos Constrained Delegation (traditional Kerberos Constrained Delegation in this case) – where the newly created PI Web API gMSA will be allowed to delegate to PI Server pi01.


1. Create the gMSA:

BackendSPNs = 'PIServer/pi01', 'PIServer/pi01.domain.local'

New-ADServiceAccount -Name PIWebAPIgMSA -DNSHostName PIWebAPIgMSA.domain.local -PrincipalsAllowedToRetrieveManagedPassword piweb01$ -ServicePrincipalNames http/piweb01, http/piweb01.domain.local -OtherAttributes @{'msDS-AllowedToDelegateTo'=$BackendSPNs}



2. Allow the account to write its own Service Principal Names – in case the AF machine name changes, for example.

$gMSA = Get-ADServiceAccount -Identity PIWebAPIgMSA

dsacls $gMSA.DistinguishedName /G "SELF:RPWP;servicePrincipalName"


3. Use the gMSA on the target machine.




If any modifications are required after the gMSA is created, use the Set-ADServiceAccount cmdlet. See the official documentation for details.




gMSA in PI Environment

When specifying gMSA identity in Services.msc snap in or in IIS Manager, simply type in the name of the account and leave the password box blank:



Tip: After the Log On account of a Service is set to a gMSA, the Log On tab will be permanently unavailable (grayed out). To fix this, open an elevated Command Prompt and execute sc managedaccount <serviceName> false.


PowerShell can be used to use gMSA for IIS Application Pools and Services.


IIS Application Pools:
# Define gMSA and AppPool name

# Change the two variables below as needed

$gMSA = "DEN\PISQgmsa$"

$AppPoolName = "PIVisionServiceAppPool"


# Import WebAdmin module

Import-Module WebAdministration


# Set AppPools to use gMSA

$AppPool = Get-Item IIS:\AppPools\$AppPoolName

$AppPool.processModel.identityType = 3

$AppPool.processModel.userName = $gMSA

$AppPool.processModel.password = ''

$AppPool | Set-Item



# Define gMSA and Service name

# Change the two variables below as needed

$serviceName = 'PIOLEDBENTAgent'

$gMSA = "DEN\PISQgmsa$"


$service = Get-WmiObject -Class Win32_Service -Filter "Name='$serviceName'"

$service.Change($null, $null, $null, $null, $null, $null, $gMSA, $null, $null, $null, $null)



PI Data Server 2017 R2+

  • Use Services.msc or PowerShell to switch PI Network Manager service (pinetmgr) to run under the gMSA.
  • Older PI Data Servers do not support custom accounts.


PI AF Server

  • Use Services.msc or PowerShell to switch the AF Server service (afservice) to run under the gMSA.

PI Vision

  • From Command Prompt, execute aspnet_regiis.exe -ga domain\gMSA$ to give the account access to Microsoft .NET Temporary folder and IIS meta database.
  • Use IIS Manager or PowerShell to switch PI Vision Application Pools to run under the gMSA.


PI Web API 2017+

  • Run through PI Web API Admin Tool and select the default NT Service accounts.
  • Use Services.msc or PowerShell to switch PI Web API and PI Crawler services to run under the gMSA.
  • Re-run PI Web API Admin Tool and make no changes. The tool will automatically grant all required permissions to the gMSA.


PI Connectors

  • Add the gMSA to PI Connector Administrators local group as this group is automatically granted all the required permissions.
  • Use Services.msc or PowerShell to switch PI Connector to run under the gMSA.



  • Install kit supports gMSA and sets permissions appropriately.




Resource-based Kerberos Constrained Delegation (RBCD)


Configuring RBCD is not limited to gMSAs, but the requirements are similar – if you can use gMSAs, you can also use RBCD. OSIsoft has good documentation on the requirements and configuring RBCD.


One of the big advantages of RBCD is that service administrators can configure it themselves (no need to contact Domain Administrators).





1. Open elevated Command Prompt on the machine with the gMSA-run back-end service (PI or AF Server).


2. Use Windows Sysinternals’ PsExec to open a PowerShell console under the gMSA identity:
PsExec.exe -u DOMAIN\gMSAname$ -p ~ powershell.exe


3. Domain users, including gMSAs, possess the required permission (write account restrictions) by default, so we can configure RBKCD as needed:

Set-ADServiceAccount -Identity gMSAname -PrincipalsAllowedToDelegateToAccount Account1, Account2 ..

For example, to allow Kerberos Delegation from PI Web API service running under PIWebAPIgSMA$ account to AF Server service running under AFgMSA$ account, execute:

Set-ADServiceAccount -Identity AFgMSA -PrincipalsAllowedToDelegateToAccount PIWebAPIgMSA$



4. Assuming the gMSA has been granted to write to its SPN attribute (as recommended and shown above), SPNs can now be set using SetSPN.exe:
setspn -s SPNClass/MachineHostName gMSAname$
setspn -s SPNClass/MachineFQDN gMSAname$


For example, to create HTTP SPNs for a PI Vision Service, execute:

setspn -s HTTP/piviz01 PIVizgMSA$

setspn -s HTTP/piviz01.domain.local PIVizgMSA$



References and recommended reading


Securing Privileged Access

Group Managed Service Accounts Overview

Getting Started with Group Managed Service Accounts

Windows Server 2012: Group Managed Service Accounts

CQURE: How To Use Group Managed Service Accounts (gMSA) vs. Service Accounts

DSInternals’ post on retrieving cleartext gMSA passwords

OSIsoft documentation: Resource Based Kerberos Constrained Delegation