Forum Widgets
Latest Discussions
Defender for Identity health issues - Not Closing
We have old issues and they're not being "Closed" as reported. Are we missing something or is this "Microsoft Defender for Identity" Health Issues process broken? Thanks! Closed: A health issue is automatically marked as Closed when Microsoft Defender for Identity detects that the underlying issue is resolved. If you have the Azure ATP (workspace name) Administrator role, you can also manually close a health issue.
IdentityLogonEvents - IsNtlmV1
Hi, I cannot find documentation on how the IdentityLogonEvents table's AdditionalFields.IsNtlmV1 populated. In a demo environment, I intentionally "enforced" NTLMv1 and made an NTLMv1 connection to a domain controller. On the DC's Security log, event ID 4624 shows correct info: Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): NTLM V1 Key Length: 128 On MDI side however it looks like this: (using the following KQL to display relevant info here: IdentityLogonEvents | where ReportId == @"f70dbd37-af8e-4e4e-a77d-b4250f9e0d0b" | extend todynamic(AdditionalFields) | project TimeGenerated, ActionType, Application, LogonType, Protocol,IsNtlmV1 = AdditionalFields.IsNtlmV1 ) TimeGenerated ActionType Application LogonType Protocol IsNtlmV1 Nov 28, 2025 10:43:05 PM LogonSuccess Active Directory Credentials validation Ntlm false Can someone please explain, under which circumstances will the IsNtlmV1 property become "true"? Thank you in advance
Change password for krbtgt account
What is the criteria that MDI uses to determine whether the https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/accounts#change-password-for-krbtgt-account recommendation has been completed? I'm working with an org where the passwordLastSet attribute on the krbtgt account says "never", yet this recommendation is showing "Completed".
Sensor install failing, error log indicates proxy issue
Hi Everyone, I was re-installing a sensor that was stuck on updates and I get an error in the logs - failed connecting to service. The issue can be caused by a transparent proxy configuration From what I can find that's related to either missing certificates or SSL inspection. The proxy works fine for other sensors and I know it's not inspecting this traffic anyway. I found a troubleshooting page that calls out the specific Root CA - "DigiCert Global Root G2" which exists on this machine. https://learn.microsoft.com/en-us/defender-for-identity/troubleshooting-known-issues#proxy-authentication-problem-presents-as-a-connection-error I believe this sChannel error is related The remote server has requested SSL client authentication, but no suitable client certificate could be found. I am stumped at this point, any help is appreciated.Clarification over "dormant" account status
I was looking today at our list of "Remove dormant accounts from sensitive groups" within Microsoft Defender for Identity, and one service account has caused a bit of discussion. The account would only be used on-premise and would never be carrying out authentications out of our estate. In this case would Defender for Identity still see the account as being "dormant", or is the reason because it's not carried out any of those off-estate authentications? Apologies if this is a simple question, but it would be very helpful to know the answer.
DSA requirements
Hello, DSA is configured with rights "log on as a service" on the domain controllers. Do you need to configure the sensor service it self to also start the service with the DSA account with "Logon as"? Our sensors are starting up fine. But I have some strange logs in the sensor error log file. So I just want to verify that our setup is correct. Thanks!MDI set up on AD FS but no logs are coming
Hi everyone, We are currently deploying Defender for Identity all around our infrastructure. We already covered all the DCs, however we are facing some configuration issue with the sensors installed on our AD FS farm. In a nutshell, even if it seems that the sensors have been configured correctly (no health issues in the XDR console, service running), when running the KQL query to ensure authentication logs from AD FS are coming in, we get nothing: IdentityLogonEvents | where Protocol contains 'Adfs' No results found in the specified time frame. Here's a summary of the tasks we performed: We installed the sensor on the two servers in our AD FS farm and verified that they check in with the cloud console We enabled verbose logs and granted access to the AD FS database to the gMSA user we use with MDI We were unable to enable audit logs on the AD FS container because for some reason we can't find it (even enabling View > Advanced features in ADUC) - maybe this is the problem? We specified the FQDNs of the domain controllers on the two sensors, in the cloud console After looking at the logs (Microsoft.Tri.Sensor.log), it seems that there is some issue indeed, since for every authentication we get the following two Warning messages: Warn EventActivityEntityResolver ResolveLogonEventAsync logonEvent detected [...] Warn EventActivityEntityResolver ResolveLogonEventAsync logonEvent failed to resolve source computer [...] We cannot see more descriptive errors in the logs. Did anyone have this issue? How is it possible that we don't have the ADFS container in AD?
