You are currently offline, waiting for your internet to reconnect

Audit event shows authentication package as NTLMv1 instead of NTLMv2


You are using lmcompatibilitylevel on 3 or higher on all machines in the domain to force clients to use only NTLMv2.  In testing connections to network shares by IP address to force NTLM you discover the “Authentication Package” was still listed as NTLMv1 on the security audit event (Event ID 4624) logged on the server.

For example you test with a Windows 7 client connecting to a file share on Windows Server 2008 R2. The network trace showed the authentication was actually using NTLMv2 but reporting NTLMv1 in the event log: 

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Event ID:      4624
Task Category: Logon
Level:         Information
Keywords:      Audit Success
An account was successfully logged on.
                Account Name:                               user
                Account Domain:                            contoso
Detailed Authentication Information:
                Logon Process:                 NtLmSsp
                Authentication Package:             NTLM
                Transited Services:         -
                Package Name (NTLM only):     NTLM V1
                Key Length:                       128
More Information

There are two known scenarios that can lead to this result.

A. Windows Server 2003 Domain Controllers

We discovered that we can reproduce this behavior when the domain controller validating the users credentials is a 2003 based server. Windows Server 2003 did not have the “authentication package” field in its event logging, this was a new feature added in Windows Vista.

If the domain controller is Windows Server 2008 or newer the server will show the authentication package listed correctly as NTLMv2. If the reporting of the authentication protocol version is important, we suggest using Windows Server 2008 or newer Domain Controllers.

Windows Server 2003 is in the extended support phase, the support is retired in July 2015. See

B. Negotiation of security levels uses "legacy" methods that mean best effort:

This scenario involves 3rd party clients:

1. The customer has a 3rd party SMB client which is configured for NTLMv1.

2. The file server is configured for LmCompatiblityLevel=5 and minimum sesion security NTLMv2, the DC is configured for LmCompatiblityLevel=4.

3. A user on the 3rd party client connects. In the SMB, you see the security blob in the SMB session negotiation with the expected name fields and NegotiateFlags, the server rejects the negotiation with STATUS_NOT_SUPPORTED since the client does not negotiate NTLMv2:

NegotiateFlags: 0x60000215 (NTLM v1128-bit encryption, , Sign)
NegotiateNTLM:                    (......................1.........) Requests usage of the NTLM v1 session security protocol.
NegotiateNTLM2:                   (............0...................) Does NOT request usage of the NTLM v1 using the extended session security.

4. The 3rd party client then retries without using the security blob (which indicates extended session security). In this format, you don't see the same known list of name fields and maybe also no NegotiateFlags. Some fields like "ClientChallenge" might indicate that the client tries to perform NTLMv2 hash processing. But due to the lack of NegotiateFlags this does not arrive as a NTLMv2 authentication request at the DC.

5. The server forwards the package to the DC which authenticates the request, and since the DC is OK to use NTLMv1, it authenticates the request.

6. The server receives the successful logn and audits that as NTLMv1 as specified by the DC.

For logons without extended session security, the server has no option to block the logon request based on the client flags. It has to forward the request with the best flags it got to the DC. on return, it also has to accept any decision the DC makes on the logon. In this case, it accepts the logon and logs it as NTLMv1 logon, even though the resource server is configured to only allow NTLMv2.

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.

Article ID: 2701704 - Last Review: 09/12/2013 03:12:00 - Revision: 10.0

  • Windows Server 2008 R2 Standard
  • Windows Server 2008 R2 Enterprise
  • Windows Server 2008 Standard
  • Windows Server 2008 Enterprise
  • Windows Server 2012 Standard
  • Windows Server 2012 Datacenter
  • KB2701704