Azure ATP Group Managed Service Account (gMSA)

Brass Contributor

We are switching our service account for ATP to a gMSA.   

We are following the  gMSA guidance in this article:


Do you have any guidance for the following gMSA properties, or any other gMSA properties:

-ServicePrincipalNames <string[]>

-KerberosEncryptionType AES128,AES256

-ManagedPasswordIntervalInDays xx



I assume the PrincipalsAllowedToRetrieveManagedPassword will be set to the built-in Group “Domain Controllers”, correct?



Thank you

7 Replies

@Bryan Bishop The main requirement for the creation of the gMSA is indeed the PrincipalsAllowedToRetrieveManagedPassword attribute which points to a group that contains the computer accounts with the sensor installed (you can use the Domain Controller group or a dedicated group for that).

@Or Tsemah 
Thanks for the response.   Something else we found during testing.   

We have read-only domain controllers so that is a different group that needs to be added to gmsa properties.

We had to grant the gMSA logon rights as  service to each domain controller.   A standard account  did not require this OS right on the ADDS servers.


Yes, that's why you should consider using dedicated groups

Regarding the log in as a Service permission, you can view possible workaround in here:

@Or Tsemah Thanks, that is probably the same issue we have with the logon rights.


Dedicated groups work also.  The disadvantage for us is remembering to add the computers to that group as part of a ADDS server deployment.  

We are also evaluating putting sensors on additional components, which is another (future) reason for dedicated groups

@Bryan Bishop What is the recommended approach with a gMSA account when you have multiple domains in the forest. Can we use single gMSA created in forest root domain to use on all the child domains, or would you need a gMSA for each domain in the forest?

@JohanHeyneke OMG - that stinks no one answered your question.


You can absolutely use a single GMSA for your entire forest.