Introduction
Recently I have been involved with multiple scenarios where Microsoft defender for identity is being provisioned successfully and a question arise around usage of gMSA accounts.
As explained in MDI documentation here Microsoft Defender for Identity prerequisites Microsoft recommends to use gMSA account and actually there is a soft cap of up to 30 accounts to be used with intention to map to 30 AD forests within single MDI instance and even this soft cap limit can be raised by opening a support ticket.
However, something to note here is that as explained in this document gMSA account scope, gMSA accounts are designed with scope limited to current domain only.
Why scope of gMSA account was referred to as domain scope ?
If we take a quick look at the gMSA account created object and in specific if we check the object class attribute and compare it to normal computer object class attribute, we find following:
|
gMSA objectClass attribute |
objectClass for normal computer object |
|
|
So it becomes apparent that gMSA account is actually a special type of computer object created from a class that has an additional attribute called msDS-GroupManagedServiceAccount
This explains why the scope boundary of gMSA account objects is limited to one active directory domain.
The above is aligned with the fact that when running powershell command Install-ADServiceaccount on a given child domain controller in a forest where gMSA account was created in root domain controller it will simply throw an error saying it couldn’t be found.
This is due to the way the PowerShell cmdlets work in this general context with fact that practically in order to use Install-ADServiceaccount from child domain then the gMSA account has to be present in same domain or the PowerShell won’t work.
Note: The Powershell cmdlet Install-ADServiceaccount is mentioned here in the general context of gMSA creation and usage. Defender for identity does not require using Install-ADServiceaccount cmdlet at all.
So could gMSA accounts be used cross-domains ?
This brings us to the Defender for Identity part
gMSA accounts are special type of computer object class in active directory and this means it can be discovered by domain controllers in child domain or other domains with trust relationship.
So in context of Defender for identity we could actually allow domain controllers from trusted domains in the forest to retrieve the password of the gMSA account by simply doing following:
1- Creating a new active directory group
2- Add the domain controllers group from all domains in the forest to be a member of the newly created group in step1.
3- The newly created group will be passed to attribute PrincipalsAllowedToRetrieveManagedPassword while creating the g
MSA account as explained in this document here Creating gMSA account
Example
Following example will create new gMSA account with minimum required options.
MDI-gMSA-Allowed: This is the name of the security group that have all members allowed to retrieve gMSA account password
New-ADServiceAccount gMSA02 -PrincipalsAllowedToRetrieveManagedPassword MDI-gMSA-Allowed -DNSHostName gMSA02.xxx.local
This will have advantage that any newly created domain controller will by default become a member and hence will be allowed to be onboarded to defender for identity without extra work related to gMSA account perspective.
Once that is done, then defender for identity would be seamlessly working with one gMSA account for whole forest including all domains and trusted domains in this forest.
with thanks to Claus Jespersen @claus_jespersen, Martin Schvartzman and Ahmed Awad for their input to this post.