Skip to main content

NinjaOne Backup — SMB Credentials Rejected (System Error 86) Despite Correct Password: LmCompatibilityLevel / NTLMv2

Audience: T1 / T2 (the domain-controller / GPO fix below is T3-tier — it touches Group Policy) Use when: A NinjaOne backup to a NAS fails with a credential/authentication error, and manual SMB testing from the affected server returns "System error 86 has occurred. The specified network password is not correct" — but the same credentials work from another machine and/or from the NAS web UI.

Especially common when backing up a Windows domain controller to a UNAS/NAS. A DC is frequently the only machine at a site that fails this way: the Default Domain Controllers Policy forces its NTLM level low, so the DC sends NTLMv1 while every workstation and member server defaults to NTLMv2. On a DC the fix is not a registry edit — jump to Domain Controllers & GPO-Managed Servers below.

This is not a wrong-password problem and not a NinjaOne storage-location problem. The password is correct. The affected Windows server is refusing to send the authentication method the NAS requires. Confirm with the diagnostic step below before changing anything.

What This Error Means

SMB authentication uses NTLM. Windows decides which version of NTLM it will send based on a Local Security Authority (LSA) policy value, LmCompatibilityLevel:

  • Level 2 = "Send NTLM response only" — sends legacy NTLM (NTLMv1-style) only.
  • Level 3+ = "Send NTLMv2 response only" — sends NTLMv2.

Modern NAS platforms (UniFi UNAS / UniFi Drive, and others) require NTLMv2 and reject NTLM-only auth. A server stuck at Level 2 will be rejected at the protocol level with System error 86 even though the password is correct. Other servers on the same VLAN that work fine are already at Level 3.

This is why the failure is per-server, not per-credential: the credential is valid, but the failing server isn't allowed to present it in a form the NAS accepts.

Why This Hides From Normal Troubleshooting

This is an LSA policy, not an SMB client setting. The usual SMB diagnostics do not surface it:

  • Get-SmbClientConfiguration shows signing and guest settings — not the NTLM auth level. It will look clean.
  • net use * /delete (clearing cached sessions) won't fix it on its own — there's nothing wrong with the cached session. It is still a required step after the registry fix, or the surviving session masks the result. See Fix below.
  • Mapping by IP instead of hostname won't fix it — resolution isn't the problem.
  • Re-entering the password won't fix it — the password isn't the problem.

If you've cleared cached credentials, confirmed name resolution, confirmed the account works elsewhere, and you're still getting System error 86 — check LmCompatibilityLevel before anything else.

Diagnostic — Confirm Before Changing Anything

Run on the affected server (CMD or PowerShell):

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

Interpretation:

Result Meaning
LmCompatibilityLevel ... 0x2 Confirmed root cause. Server is NTLM-only; proceed to fix.
LmCompatibilityLevel ... 0x3, 0x4, or 0x5 Already NTLMv2. This is not your cause — stop, do not apply the fix, investigate elsewhere (NAS-side SMB user, share permissions, password mismatch).
Value does not exist / ERROR: ... unable to find Windows default applies (Level 3 negotiate on modern OS). Likely not your cause — investigate elsewhere before forcing a value.

Only proceed to the fix if the query returns 0x2.

Domain Controllers & GPO-Managed Servers — Read Before Fixing

LmCompatibilityLevel can be set locally (in the registry) or enforced by Group Policy. On a domain controller it is almost always enforced by the Default Domain Controllers Policy. This changes the fix completely:

On a GPO-managed server, a plain reg add will be reverted at the next Group Policy refresh (~90 min, or sooner on gpupdate / reboot). The durable fix has to be made in the winning GPO, not the registry.

A reg query returning 0x2 looks identical whether it's local or GPO-pushed — so on a DC (or any domain-joined server) confirm where it's set before you touch anything:

Option A — gpresult (works on any domain-joined box):

gpresult /h C:\lmcompat.html /f

Open the report and search for "LAN Manager authentication level". The Winning GPO column tells you where it's set — for a DC this is normally Default Domain Controllers Policy.

Option B — scan SYSVOL directly (run on the DC):

Select-String -Path "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies\*\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf" -Pattern "LmCompatibilityLevel"

A hit = a GPO controls it. Map the GUID in the path to a name with Get-GPO -All | Select DisplayName,Id.

Fix

Pick the path that matches what the diagnostic showed.

Path 1 — Standalone / member server, value set locally (no GPO hit)

Set the server to send NTLMv2 (Level 3). Run in an elevated CMD:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 3 /f

No reboot required. Microsoft documents Network security: LAN Manager authentication level as having no restart requirement — the value takes effect when saved locally or applied by Group Policy, because LSA reads LmCompatibilityLevel per authentication attempt. Confirmed in production (August 2026): the reg add above cleared System error 86 immediately on a server that could not be rebooted. Do not schedule a maintenance window for this fix.

Existing SMB sessions and cached credentials survive the change, so clear them before retesting — otherwise the stale session makes a working fix look like a failure:

net use * /delete /y
cmdkey /list

Delete any stale saved credential the list shows for the NAS: cmdkey /delete:<target>

Do not run klist purge on a domain controller running Windows Server 2025 — it crashes LSASS. Use klist get krbtgt/<domain> instead.

Retest the SMB mount with the NAS File Services credentials (pull the actual credential from IT Glue — do not hardcode):

net use \\<NAS-IP>\<share> /user:.\<fsuser> *

Then re-run the NinjaOne backup job to confirm the credential error clears.

Path 2 — Domain controller, or any GPO-managed server (the durable fix) {#bkmrk-domain-controllers-gpo}

Edit the winning GPO from the diagnostic — for DCs this is normally the Default Domain Controllers Policy:

Group Policy Management → edit the winning GPO →
Computer Configuration → Policies → Windows Settings → Security Settings →
Local Policies → Security Options →
  Network security: LAN Manager authentication level → "Send NTLMv2 response only"

Then on the affected server:

gpupdate /force

Verify the value flipped and re-test (no reboot is normally needed after a GPO apply — reboot only if the value doesn't take effect):

(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel).LmCompatibilityLevel   # expect 3
net use \\<NAS-IP>\<share> /user:.\<fsuser> *

Then re-run the NinjaOne backup job to confirm the credential error clears.

Blast radius: the setting is linked at the Domain Controllers OU, so the change applies to all DCs in the domain. That's intended — you want every DC on NTLMv2.

Quick proof on a DC: you can reg add Level 3 to confirm the fix works immediately, but Group Policy will stomp it back to 2 on the next refresh — so always make the permanent change in the GPO.

Automation: enforcing NTLMv2 and detecting GPO management are being added to our Windows security configuration tooling — tracked in ninja-one-automation#22.

Rollback

If forcing NTLMv2 breaks SMB to some other legacy device this server talks to (a much older appliance that only accepts NTLMv1), restore the prior value. Record the original value from the diagnostic query before changing it. If the change was made in a GPO (Path 2), revert it in that GPO — a registry revert won't hold. For a locally-set value (Path 1), revert to Level 2:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 2 /f

No reboot is required to roll back either. Clear sessions and retest:

net use * /delete /y

A server needing Level 2 for one device and Level 3 for another is a conflict that should be escalated to T3 — the legacy device is the real problem and the long-term fix is to retire or update it, not to weaken the server's auth.

Compliance Note

Raising LmCompatibilityLevel from 2 to 3 is a hardening change — it forces NTLMv2 and refuses weaker NTLM/LM authentication. This is the correct direction for NIST 800-171 / CMMC environments (identification & authentication controls). There is no compliance downside to applying it. The only risk is the legacy-device operational conflict described under Rollback.

Why Web UI Access Works But SMB Doesn't

On UniFi UNAS / UniFi Drive devices, the web login is a UniFi Identity / UI.com SSO credential. The SMB mount uses a separate File Services credential assigned to the device's local user (default ubnt). These are different auth backends. Successful web login tells you nothing about whether SMB will authenticate — and in the System error 86 case here, SMB does have the right credential but is blocked by the host's NTLM level, not by the credential itself. See UNAS 2 Provisioning (page 2567) for the File Services credential and .\ prefix details.

Back to top