Using gMSA with ATP results in many 2947 events

[StuartSquibb]

We have an ATP deployment with several domains and different Trusts. We have 3 different credentials in use, 2 x 'ordinary' service accounts and 1 x gMSA. On the DCs in the domain where the gMSA is hosted the "Directory Service" event logs are full of 2947 events ("An attempt to fetch the password of a group managed service account failed.") for the gMSA. The source computers for these events are computers in other domains with the ATP sensor installed. Is there any way of filtering which credentials are used by the sensors in a given domain? The deluge of 2947 events is making it difficult to find useful information in the logs of the affected DCs.

[#2]

No, all sensors need to be able to pull passwords for the gmsa of all other domains where there are entities that might contact the current domain where the sensor is running.
Read this:
https://docs.microsoft.com/en-us/defender-for-identity/directory-service-accounts
For better understanding how to configure it correctly.

[#3]

@Eli Ofek  We have the same issue. All is set up correctly. We only have gMSA but we have multiple forests. For every doamin we have a gMSA. This has logon-as-a-service on the DC and the gMSA is installed on the respective DC. Also, the PrincipalsAllowedToRetrieveManagedPassword for the gMSA contains a universal group of which the DC is a member.

Yet, we see a lot of 2947 events. The log shows 

2022-05-18 10:30:01.8472 Info RemoteImpersonationManager GetGroupManagedServiceAccountTokenAsync finished [UserName=gMSAxxxx$ Domain=forest1.local IsSuccess=False]
2022-05-18 10:30:01.8472 Info RemoteImpersonationManager CreateImpersonatorInternalAsync finished [UserName=gMSAxxxx$ Domain=forest1.local]
2022-05-18 10:30:01.8472 Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=unix.local Domain=forest1.local UserName=gMSAxxxx$ ]
2022-05-18 10:30:01.8472 Info RemoteImpersonationManager CreateImpersonatorInternalAsync started [UserName=gMSAxxxx$ Domain=forest2chld.local IsGroupManagedServiceAccount=True]
2022-05-18 10:30:02.5503 Info RemoteImpersonationManager GetGroupManagedServiceAccountTokenAsync finished [UserName=gMSAxxxx$ Domain=forest2chld.local IsSuccess=False]
2022-05-18 10:30:02.5503 Info RemoteImpersonationManager CreateImpersonatorInternalAsync finished [UserName=GMSY000001$ Domain=forest2chld.local]
2022-05-18 10:30:02.5503 Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=unix.local Domain=forest2chld.local UserName=gMSAxxxx$ ]
2022-05-18 10:30:02.5503 Info RemoteImpersonationManager CreateImpersonatorInternalAsync started [UserName=gMSAxxxx$ Domain=forest2.root IsGroupManagedServiceAccount=True]
2022-05-18 10:30:03.3316 Info RemoteImpersonationManager GetGroupManagedServiceAccountTokenAsync finished [UserName=gMSAxxxx$ Domain=forest2.root IsSuccess=False]
2022-05-18 10:30:03.3316 Info RemoteImpersonationManager CreateImpersonatorInternalAsync finished [UserName=gMSAxxxx$ Domain=forest2.root]
2022-05-18 10:30:03.3316 Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=unix.local Domain=forest2.root UserName=gMSAxxxx$ ]
2022-05-18 10:30:03.3316 Info DirectoryServicesClient TryCreateLdapConnectionAsync failed [exception=Microsoft.Tri.Infrastructure.ExtendedException: CreateLdapConnectionAsync failed [DomainControllerDnsName=unix.local]

 This is on a DC in a forest forest3.local (not present in the log above). It seems that it tries to find an account for the unix.local 'domain' (it is a Unix based LDAP, there is a trust between forest2chld.local and unix.local as wel as a two-way trust between forest2.root and forest3.local). It will never succeed.

IMHO it may try this one time, log a message and give up. But is it very agressive and floods the log...

Please Microsoft - there is more in the world than Windows/Active Directory.

[#4]

Interesting feedback on this scenario. can you share this feedback via email?
AatpFeedback at microsoft com.

[#5]

@Eli Ofek  e-mail sent. I am happy to provide more information if required.

[#6]

@Eli Ofek Any news on this matter? We have an open support case and it was suggested to provide feedback here too. 

[#7]

@AndrePKI Did you get a reply from the feedback alias ?

[#8]

@StuartSquibb 

I'm in a similar situation and really confused regarding gMSA implementation in a multi-forest environment, particularly in the case of one way trusts. To me it appears a single GMSA can only be used in a case of multiple domains/forests using two way trusts, and one can only use multiple GMSA's in the case of multiple domains/forests with NO trusts.

My current setup, each is a different forest:

Domain                       gMSA                              TRUST (all one way forest trusts)

DomainA.com            MDI-SVC-A               apps.domainb.com-->DomainA.com
DomainB.com            MDI-SVC-B               apps.domainb.com --> Domainb.com

                                                                   domainb.com --> DomainA.com

apps.DomainB.com    MDIAPPS-SVC       domainA.com-->apps.domainb.com<--Domainb.com

-There's a local security group in apps.domainb.com that contains the domain controller groups for all three domains/forests, and this is assigned to the MDIAPPS-SVC Gmsa, and every gmsa has been granted log on as a service in their respected domain 

-All sensors start on all DC's in all domains without error and portal shows no health issues

-apps.domainb.com is filled with 2947 errors stating it can't access the password of the MDI-SVC-A and MDI-SVC-B Gmsas

-domainA.com and domainB.com don't have 2947 errors, but the security log is filled with 4625 errors with logon type 5 (service) for failed logons of of the MDIAPPS-SVC account with error code 0xC000018B.  

Honestly, I don't see how this can work as long as the trusting gmsa requires log on as a service in the trusted domain, as there's simply no way to add it.

[#9]

@jroth710 @StuartSquibb @AndrePKI @Eli Ofek 

We are working on several improvements around credentials usage by the sensor in multi-forest environments and in general. But it'll take a few weeks to be released.

You can follow the what's new page for updates, but I'll make sure to update this thread as well.

[#10]

@Martin_Schvartzman 

looking forward to it as I opened a ticket with Azure and received a totally nonsensical answer along with advice to contact the on-premise active directory team on how to configure gMSA’s for a one way forest trust.. 

[#11]

@Eli Ofek: I never got a response - only via support case ([31255650] Many EventID 2947 events - TrackingID#2205250040002388)

"I wanted to share a bit of update related to the Product related to current logic of GMSA, improvements are currently being worked on and we expect to release them in the near future versions.

We will keep in touch and I expect as soon it is featured in a new version you can perceive a better scenario." (Amanda Nunes, Technical Advisor )

[#12]

@StuartSquibb  @Eli Ofek This is still an actual problem in our environment. What can we do? Open another support case?

[#13]

@AndrePKI Yes. Please open a support case.