Azure ATP doesn't start in DC with gMSA account

Question

Cx is unable to start a sensor when he uses gMSA account instead of personal account.

The customer also had a Security Group in AD with their DC and standalone sensors included.

We added the gMDSA account in the policy Log on as a service but still faces the same error.

Unable to run AATP Ldap Binder tester tool to test MDI sensor AD access using a gMSA accout, shows "PC can't run this app error."
The DC is 2016

1. Health Alert when we use gMSA account.
   ![179865-s4.png][1]
2. Created and Updated Security Group to DC
   ![179809-s2.png][2]![179873-s3.png][3]
3. Added gSMA account in Logon as services, that too didn't resolve.
   ![179855-image-20220122040626-1.png][4]
4. Unable to start AATP sensor
   ![179893-s5.jpg][5]
5. Error while running aatpldapbindtester.exe file.
   ![179883-s5.jpg][5]

-

Answer 1

@EPSrookie
Thank you for your detailed post and I apologize for the delayed response!

Based off your error message, I found a troubleshooting doc that details root causes for your error and solutions, which I'll share below to hopefully help point you in the right direction to resolve this issue.

Sensor failed to retrieve group managed service account (gMSA) credentials

Error Message: Directory services user credentials are incorrect

---

Root Cause 1:

The domain controller hasn't been granted permission to retrieve the password of the gMSA account.

Troubleshooting:

Validate that the computer running the sensor has been granted permissions to retrieve the password of the gMSA account. For more information, see Granting the permissions to retrieve the gMSA account's password.

---

Root Cause 2: This was the solution for one of the Support Requests
The sensor service runs as LocalService and performs impersonation of the directory services account. If the user rights assignment policy Log on as a service is configured for this domain controller, impersonation will fail unless the gMSA account is granted the Log on as a service permission.

Troubleshooting:

Configure Log on as a service for the gMSA accounts, when the user rights assignment policy Log on as a service is configured on the affected domain controller. For more information, see Verify that the gMSA account has the required rights.

---

Root Cause 3:

If the domain controller Kerberos ticket was issued before the domain controller was added to the security group with the proper permissions. This group won't be part of the Kerberos ticket, so it won't be able to retrieve the password of the gMSA account.

Troubleshooting: Do one of the following to resolve this issue

1. Reboot the domain controller.
2. Purge the Kerberos ticket, forcing the domain controller to request a new Kerberos ticket.
   From an administrator command prompt on the domain controller, run the following command:
   klist -li 0x3e7 purge

3) Assign the permission to retrieve the gMSA's password to a group the domain controller is already a member of, such as the Domain Controllers group.

Additional Link:

Microsoft Defender for Identity - Azure ATP Deployment and Troubleshooting
Resources for Defender for Identity

If you have any other questions or are still having issues, please let me know.
Thank you for your time and patience throughout this issue.

---

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

Answer 2

Hi,

I have the Same issue.

Did you @EPSrookie find a solution?

Regards
Farhad