Forum Discussion
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:
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
8 Replies
This is a very nuanced behavior, and the key point is this:
IsNtlmV1 in IdentityLogonEvents is not derived from Event ID 4624.
It is determined by Defender for Identity based on the authentication exchange the sensor observes.Event 4624 reflects how Windows classifies the authentication within the LSA/SSPI context. However, that log entry does not necessarily represent the exact NTLM response structure used on the wire.
The distinction between NTLMv1 and NTLMv2 is not determined by the authentication package label alone. It is determined by the structure of the NTLM AUTHENTICATE message in the NTLMSSP handshake.
Specifically:
NTLMv1 typically uses:
- 24-byte NT response
- 24-byte LM response
- DES-based challenge-response
- No NTLMv2 blob
NTLMv2 typically uses:
- HMAC-based NT response
- Variable-length NTLMv2 blob
- Target information (AV pairs)
- Extended session security
If Defender for Identity cannot confirm that the response structure matches NTLMv1 characteristics, it will not set IsNtlmV1 to true — even if Event 4624 shows “Package Name (NTLM only): NTLM V1”.
There are several reasons this mismatch can occur:
- The client advertises NTLMv2 capability but falls back in a way that still produces a response structure Defender does not classify as pure NTLMv1.
- Windows logs classify the package generically as NTLM V1 based on SSP context rather than strict response format.
- The sensor did not observe the full handshake (for example, due to visibility or capture timing).
- Extended session security was negotiated, which may affect how the authentication is interpreted.
The most authoritative way to validate what actually occurred is packet inspection.
If you capture the NTLM handshake and inspect the AUTHENTICATE message:
- If the NT response is exactly 24 bytes with no NTLMv2 blob, that is true NTLMv1.
- If there is a structured NTLMv2 blob and HMAC response, it is NTLMv2 — regardless of how 4624 labels it.
In summary:
Event 4624 is not the source of truth for NTLM version classification in Defender for Identity.
IsNtlmV1 reflects what the sensor can confirm from the authentication exchange it observes.
A mismatch between the Security Log and IdentityLogonEvents is possible and does not necessarily indicate an issue with MDI.If you can share the NTLM AUTHENTICATE response structure (for example, response length details), it would be possible to determine precisely why IsNtlmV1 remained false in your scenario.
- kuglidaniCopper Contributor
Hi!
Thank you for this very detailed explanation. I tried to reproduce the issue and capture network packets.
What I see so far:
NTLM v2 - this one is clear, posting just to compare:
- LM response length: 24
- NTLM response: 332 inlcudes NTLMv2 response field
- negotiate flags: 0xe2888215NTLM v1:
- LM response length: 24
- NTLM response length: 24
- Negotiate flags: 0xe2888215[some info redacted]
The nego flags include "Negotiate Extended Security" = 1 (Set)
Based on what you wrote, Extended security is typically used in NTLMv2, but all the other characteristics seem to be NTLMv1. What am I missing?
(Initiating NTLMv1 client is a Windows Server 2016, lmCompatibilityLevel is set to 0)- RyanSteele-CoVSteel Contributor
I believe the individual who replied to your question generated their response using an AI tool. Given the technical nature of your inquiry, it would not surprise me if the answer provided was a hallucination. (I'm not saying it definitely is, but you may want to treat its accuracy with some skepticism.)