Using gMSA account in Microsoft Defender for Identity in multi-domain forests.

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

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 in the MDI.

 

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.

 

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

mahmoudmsft_0-1636463166891.png

 

mahmoudmsft_1-1636463166894.png

 

 

 

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

 

 

 

 

 

mahmoudmsft_0-1636466505795.png

 

 

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.

 

 

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.