MDI: Notes from the Field
- Will Francillette
- Mar 25
- 3 min read
I've recently completed a Microsoft Defender for Identity (MDI) deployment for a customer and came across some issues during the deployment that I didn't see documented anywhere. The main issue and remediation I will document here is the MDI service being stuck on a Starting state after the sensor was installed.
For context, the Domain Controller environment is on a functional level of Windows Server 2008 R2 and we are using Group Managed Service Account (gMSA) for the Directory Service account.
Let's get started!
Table of Contents
Issue 1: Sensor service couldn't run and remains in Starting state
After configuring the gMSA credential in the security portal, the AATP service wouldn't start anymore.
We started investigating the sensor logs and found this issue
We could see that the impersonation was successful:
But the sensor could not connect to the DC
Next step, we looked at the doc and the known issues and found that the problem was because the gMSA was not able to log in as a service so we took the step to add the sensor and NT Service\All Services in the list of allowed resources as documented in MS Learn: Sensor service couldn't run and remains in Starting state| Microsoft Learn
Our issue was in the DSA Credentials
If we used the Domain F365C.local , log on as a service will fail and the service will not work
We had to use the Pre Win2000 domain name and a single label domain to get the service running
After the next service restart we could see the successful query flooding the logs
During the troubleshooting, I saw someone adding the gMSA into the "Domain Users" group in AD, despite this resolving the issue, I don't recommend anyone doing so because I would be worried of unexpected security issues and that it may have some unexpected sensor issue with the service impersonation. This solution is neater in my opinion.
We may also have noticed that the credentials for my gMSA ends with a $ sign - make sure not to forget it as the screenshots in the docs may be confusing but it's mentioned that it must be used for a gMSA
Issue 2: Can't install gMSA on hardened server
When configuring the gMSA on some hardened server, the server could not retrieve the gMSA credentials and Test-ADService Account was failing
The gMSA was created with the default settings however those servers were configured to only allow AES128 and AES256 encryption types.
To resolve the issue we had to remove RC4 from the default supported encryption type by running:
I found this solution here: Install-ADServiceAccount fail with unspecified error creating gMSA - Microsoft Q&A
Conclusion
Quick blog for a long troubleshooting session 🧱🥷
I hope this solution will be added to the Known issue remediation options as I wouldn't think this will be unique to my customer.
On another note when we tried adding the NT Service\All Services entry we couldn't find the entity and struggle adding it in the policy - We found the solution here
We also tried to add that entry locally on the server using secpol.msc but could find a way to achieve it....
As always all references are in the below section.
Thanks for reading and keep posted for the next blog!
References
About William Francillette:
I am DevSecOps Lead and Solution Architect at Threatscape specialised in M365 and Azure security offering.
I love learning, blogging and coding. My interests are very diverse and span across architecture, security, cloud engineering, automation, DevOps and PowerShell.
I own as of today 17x (and counting) Microsoft certifications and have worked in IT across multiple and diverse industries for over 15 years.
Comentarios