Jan 31 2022 07:53 AM
Jan 31 2022 07:53 AM
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.
Jan 31 2022 07:57 AM
May 18 2022 04:47 AM
@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.
May 18 2022 04:54 AM
Jun 21 2022 04:46 AM
@Eli Ofek Any news on this matter? We have an open support case and it was suggested to provide feedback here too.
Jun 26 2022 10:26 AM - edited Jun 26 2022 10:41 AM
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.
Jul 02 2022 02:33 PM
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.
Jul 05 2022 11:56 AM
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..