LM Hash Storage Disabled Active Directory: Verify NoLMHash and Password Renewal

Verifying that LM hash storage is disabled in Active Directory raises two separate questions: is Windows configured to stop creating LM password hashes, and have the relevant passwords changed since that configuration became effective? A stronger password policy or an NTLMv2 network setting alone cannot answer both.

This guide explains the Microsoft storage control, three documented configuration checks, and a staged remediation plan. It also states a product limitation explicitly: the EtcSec check named ANSSI_R23_LM_HASH_NOT_DISABLED evaluates LmCompatibilityLevel, not NoLMHash. Its result is not an inventory of stored LM secrets.

LM Hash Storage in Active Directory: What Disabled Means

Microsoft distinguishes two password representations: the older LM hash and the NT hash. They can reside in the local Security Accounts Manager (SAM) database or Active Directory. The LM representation is weaker and more vulnerable to offline password recovery. Microsoft's KB 299656 on preventing LM hash storage describes the historical generation of LM material for passwords shorter than 15 characters.

That historical description does not establish that every current Windows installation creates LM hashes for short passwords. The Microsoft storage-policy reference lists enabled effective defaults for the system roles in its table, while the default domain and domain-controller GPO entries are undefined. These are documented defaults, not observations of your domain.

The storage policy acts when a password changes. An account whose password predates effective deployment therefore belongs on a review list. This is a conditional inference from the policy's timing: its old password might already have avoided usable LM material because of length, previous configuration, or operating-system behavior. Password age alone proves neither presence nor absence.

This article focuses on LM storage and renewal. Broader password flags and service dependencies are covered in Active Directory password security and service-account hygiene. Use that guide for the surrounding account review; retain a separate closure decision for the storage question here.

How It Works: Stored Hashes and Network Responses Are Separate Controls

Microsoft's storage procedure documents NoLMHash as a DWORD set to 1 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa for Windows XP and Windows Server 2003. Its procedure for Windows 2000 SP2 and later uses a key instead. These historical registry procedures require a restart and differ in password-history handling; do not generalize their purge details across versions. KB 299656 also describes passwords of at least 15 characters producing an LM value unusable for authentication. Increasing a minimum-length policy does not demonstrate that an old password was renewed. See Microsoft's version-specific methods.

The independent LmCompatibilityLevel value controls network authentication behavior. The following table paraphrases the Microsoft LAN Manager authentication-level reference. Here, NTLMv1 names the legacy NTLM variant in Microsoft's table.

Level 3 changes client responses without imposing the level-5 server rejection. Level 5 still permits NTLMv2 and does not erase database secrets. Treat network hardening and storage suppression as separate work items.

Related ANSSI guidance: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory. The LM storage control described here is documented by Microsoft.

Detection: Collect Configuration and Renewal Evidence

The commands below are examples adapted from Microsoft documentation. They were not executed against a customer Active Directory environment. Run each measure separately on the relevant Windows system and retain its identity, timestamp, output, and any error.

1. Inspect the storage-control value

This combines Microsoft's reg query syntax with the path and value in KB 299656:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v NoLMHash

Look for the documented DWORD value 0x1 where the DWORD procedure applies. The query reads local configuration, not SAM or AD password material. A missing value or failed query requires interpretation against the OS and effective policy. It does not prove that an LM hash exists. Microsoft documents return code 0 for a successful registry query and 1 for failure.

2. Inspect the network-control value separately

This uses the same query syntax and the authentication-policy registry location:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LmCompatibilityLevel

Record this in a different field from NoLMHash. A network value of 0x5 is not evidence of storage suppression or password renewal. Keeping the two readings separate also makes an unexpected collector result easier to investigate.

3. Capture the computer policy report

The Microsoft gpresult reference documents computer scope and HTML output:

gpresult /scope computer /h lm-policy.html

Inspect the resulting computer-policy report alongside the registry readings. Microsoft documents a SysWow64 requirement for HTML reporting on ARM64 and firewall requirements for remote reporting. The local example above avoids remote-target parameters. A policy report provides configuration context; it does not examine stored hashes.

Build a candidate list without overstating the signal

Compare account password-renewal dates with the verified storage-policy rollout dates. Where effective deployment dates differ, preserve that uncertainty instead of assigning one convenient domain-wide date. This comparison is a review method inferred from the next-change behavior, not a direct LM detector or a measured finding about your environment.

Remediation: Enable Storage Suppression, Then Renew the Relevant Passwords

1. Identify dependencies and assign owners

Before changing anything, create a scoped list of DCs, applicable Windows versions, and accounts that need review. Add the relevant local-account systems if local SAM storage is part of the mission. Name an owner for each service-account change and an owner for checking policy distribution.

Microsoft's storage and authentication references describe compatibility impacts for legacy clients and some applications. Use that warning to plan tests for the actual dependencies in your estate. It is not evidence that any particular application still requires LM. Record a dependency only after the owner has identified it; avoid turning an untested concern into a permanent exception.

2. Enable the Microsoft storage policy

In computer security options, enable Network security: Do not store LAN Manager hash value on next password change. Microsoft locates it under computer configuration, Windows settings, security settings, local policies, and security options. The storage-policy page documents no restart requirement for this policy.

If a version-specific registry procedure is required, use KB 299656's applicable instructions, including its registry-backup guidance. Its historical XP/Server 2003 sequence includes restart followed by password change. Do not merge that sequence with the separate policy-page restart behavior.

3. Confirm effective distribution before scheduling closure

Repeat the three detection measures on each relevant DC and applicable local-account system. Retain the report and registry readings together. For each system, record a verified effective date or mark the date unresolved.

Do not use the presence of one compliant GPO as the deployment acceptance criterion. The collector implementation discussed below can pass when any inventoried GPO contains the network level, without proving coverage. The remediation record should therefore identify which systems were directly checked and which remain unverified.

4. Organize password renewal with service owners

Microsoft's storage-policy guidance calls for users to set new passwords at their next domain sign-in. Plan the corresponding account renewal after the storage control is effective.

For accounts that do not routinely sign in, assign a deliberate renewal task rather than waiting for an ordinary user logon. With service accounts, coordinate dependent services, scheduled tasks, and applications through their owners. The practical sequence should identify the account, prepare dependency updates, perform the approved change, test the service, and preserve the result. This is an operational rollout plan, not a claim that a mass rotation was performed.

A related lifecycle problem is explained in Kerberos RC4 fallback and password-dependent AES key generation. The shared planning lesson is to include account renewal in configuration projects. AES-key generation and LM suppression remain different mechanisms with different validation requirements.

5. Handle network hardening as its own change

Select and test the intended LAN Manager network level separately, using Microsoft's compatibility guidance. Do not treat a successful level-5 rollout as closure of LM storage cleanup.

Keep NTLMv1 negotiation, relay protections, WDigest memory exposure, and outbound NTLM Tier 0 restrictions in their existing workstreams. Repeating those projects here would obscure the missing deliverable: a documented storage-policy deployment followed by scoped account renewal.

Validation: Close the Review with a Scoped Evidence Record

Use a closure record that a second administrator can understand without reconstructing the project from chat or screenshots. The following is a suggested evidence format, not a Windows output schema and not an attestation that secrets were inspected.

Describe the conclusion at the level the evidence supports. For example, a record may establish that the intended storage setting was verified on the listed DCs and that the listed accounts were renewed afterward. It should not expand that claim to unreviewed accounts, password history across all Windows versions, or an inventory of all stored secrets.

Rerun the configuration checks after the change and reconcile any outstanding systems or accounts. Keep incomplete evidence visible: an unreachable DC, an untested service, or an unknown renewal date should have an owner and next action.

How EtcSec Detects This

The current etc-collector source provides two related network-policy checks. Neither reads NoLMHash or inventories LM secrets in SAM or AD. The following analysis is a static source review at collector commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c; it is not a customer scan result.

ANSSI_R23_LM_HASH_NOT_DISABLED

Despite its historical identifier and storage-oriented catalogue label, this detector evaluates LmCompatibilityLevel. In internal/audit/detectors/ad/compliance/anssi/anssi-r23-lm-hash-not-disabled.go:17, the loop at lines 30–43 skips nil policies or settings and marks the condition satisfied as soon as any inventoried GPO has a defined value greater than or equal to 5.

It returns Count = 0 when that condition is satisfied, and Count = 1 otherwise, including an empty policy set or missing values. The implementation does not calculate effective GPO precedence or prove coverage of every DC or OU. It also uses a numeric threshold rather than validation of Microsoft's documented 0–5 range: a collected value of 6 would satisfy the comparison, without becoming a documented Windows level.

The decisive source condition is:

if p.RegistrySettings.LmCompatibilityLevel != nil &&
    *p.RegistrySettings.LmCompatibilityLevel >= 5 {
    compliant = true
    break
}

This is a formatted excerpt of lines 35–38, not a standalone program. A zero count means that this network-policy condition was found in the supplied data. It does not confirm storage suppression, account renewal, or complete network hardening; the detector does not check minimum NTLM session-security settings.

NTLMV1_ALLOWED

The neighboring detector in internal/audit/detectors/ad/gpo/ntlmv1-allowed.go:22 reads the same field at lines 32–34. Lines 37–38 set Count = 1 when the selected value is absent or below 5; otherwise the count remains zero.

Selection differs. The helper internal/audit/helpers/gpo_policy.go:130 looks first for a defined value in the default DC policy, then the default domain policy, then another policy. This is the helper's selection rule, not a full Windows resultant-policy calculation.

Consequently, these checks can disagree. In a hypothetical input with a default DC policy at 3 and another GPO at 5, the ANSSI-named check returns zero while NTLMV1_ALLOWED returns one. That example follows the source logic; no such customer configuration was observed.