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
1 Reply
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.
