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 Network Service or Local System are simple to use and can run a service or an Application Pool, but as they take on the identity of their host machine outside the machine boundary. Consequently, built-in accounts are not manageable at the domain level.  Many companies use standard Domain Accounts instead, but these accounts have a different weakness - password management (entropy, expiration/resetting, maintenance). Exposure of standard domain account passwords is inevitable for both users (who need to work with them – typing, copy/pasting) and computers (passwords are stored locally).


gMSAs combine the best features of both worlds: automatic password management and secure, centralized storage. The password is calculated on-demand by Domain Controller and automatic password changes are made periodically. In contrast to passwords used by standard Domain Users, gMSA passwords are not stored locally on server machines nor exposed to users.

Finally, provided the gMSA is created and deployed properly, configuration of common tasks such as setting Service Principal Names or configuring Kerberos Delegation can be done by services or service owners rather than domain administrators.



gMSA vs. Standard Domain User - Practical Password Play


Sticky notes are awesome!



On the other hand, gMSA password is 256 bytes of data, interpreted as 128 UF-16 characters. It is a constructed attribute calculated by Domain Controller 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.



Below, we can see two IIS Application Pools. 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).  As the password of the standard domain user is stored locally on the server, it can be obtained:



In this case, we’ve read the standard domain user password from applicationHost.config file. It’s the same story with standard 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:




As a side note, while we’re on the topic of passwords, mimikatz must be mentioned. It’s the tool of choice for any kind of fun with windows credentials. We’ll cover mimikatz and attacks on credentials (pass-the-hash, pass-the-ticket, and their mitigation and detection) 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, which can happen with the plain-text password so readily available for service accounts


While gMSAs provide some hardening and additional security against credential theft, they do not address all threats. Maintain gMSAs as a complement to 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 make it come into force 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 use fewer than 15 characters)
DNSHostName gMSA DNS account name (FQDN of the account)
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 use the gMSA. However, it’s also possible to specify the computer(s) directly.


Optionally, specify other parameters such as ServicePrincipalNames and PrincipalsAllowedToDelegateToAccount, to make Kerberos configuration for the selected service easier and faster.
If you’d like to change the default period for password reset (30 days), specify the ManagedPasswordIntervalInDays switch.

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


Example 1:

Follow the example below to create a gMSA called PIVizgMSA, designed to run PI Vision Application Pools on two servers (piviz1 and piviz2). The command creates the appropriate Service Principal Names 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 a 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. Restart piviz1 and piviz2 computers

This is only required because a Domain Group was specified as the value for the PrincipalsAllowedToRetrieveManagedPassword parameter. If you specified the machines directly (i.e. -PrincipalsAllowedToRetrieveManagedPassword piviz01$, piviz02$), there’s no need to restart the machines.


4. Optional: Allow the account to write its own Service Principal Names – especially useful for services that support automatic SPN registrations (PI, AF, SQL Servers …).

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

$gMSA = Get-ADServiceAccount -Identity PIVizgMSA

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


5. Use the gMSA on the target host machine. 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 for you.



Example 2:

In the second example, let’s create a gMSA called AFgMSA, designed to run AF Server service on machine piaf01, including proper SPNs and Kerberos Constrained Delegation settings (Resource Based Kerberos Delegation in this case) – where the above created PI Vision account (PIVisionGMSA) will be allowed to delegate to the AF Server piaf01 running under AFgMSA$ identity.


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 host machine



Example 3:

In the last example, let’s create a gMSA for PI Web API service running on machine piweb01, including proper SPNs and Kerberos Constrained Delegation Settings (Classic Based Kerberos 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 host 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 only the name of the account:



Tip: After the Log On account of a Service is set to a gMSA, the Log On tab will be greyed out. Open a Command Prompt and run sc managedaccount <serviceName> false command to revert back.


Of course, PowerShell can be used to specify 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). In the PI world, this would be used to enable RBCD to AF or PI Server.

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