Local user management password policy inconsistent behaviour

Hi Stewart — good reproduction and clear description. Short answer: lusrmgr (the MMC snap‑in) and the CLI cmdlets/tools use different API/code paths when creating a local account, so the complexity check that looks for parts of the user's full name can be skipped at creation time by lusrmgr. In practice that means New-LocalUser / net user enforce the "not contain parts of the user's full name" rule at creation, while lusrmgr sometimes sets the password before the Full Name is committed (or uses an API that doesn't validate against the full name), so the password is accepted. When you later change the password (full name already present), the filter runs and rejects it — which matches what you observed.
Why that happens (concise technical hypotheses)

• Different APIs / order of operations: MMC may call a different SAM/ADSI/NetUser API or set the FullName property after the password, so the password filter can't see the full name when the password is first set.
• Password filter semantics: the complexity check is performed by a password filter that compares the candidate password against the user attributes visible at the time of the call; if full name is not present yet it won't match.
• Not necessarily a security feature — more of an inconsistency/quirk in the snap‑in or underlying call sequence.

How to confirm and gather details (quick tests)

1. Confirm local policy: open secpol.msc -> Account Policies -> Password Policy and verify "Password must meet complexity requirements" is enabled. If the machine is domain‑joined, check the effective GPO (domain policies override local).
2. Reproduce with exact commands:
   • PowerShell (should fail):
     New-LocalUser -Name "TESTUSER1" -FullName "Max Mustermann" -Password (ConvertTo-SecureString "MaxPassword12345678" -AsPlainText -Force)
   • Create in lusrmgr (succeeds for you).
3. Immediately after creation in lusrmgr, check what Windows thinks the FullName is:
   • PowerShell: Get-LocalUser -Name TESTUSER1 | Format-List *
   • or net user TESTUSER1 and compare the "Full Name" field. If FullName is blank at creation time and is populated later, that supports the theory.
4. Try changing the password via PowerShell / net user and via lusrmgr and note the differing behavior.

Workarounds / recommendations

• For consistent policy enforcement, create users with New-LocalUser or net user (these enforce the policy at creation).
• If you must use lusrmgr, create with a compliant password or create the account with a temporary compliant password, then change it as required (but note changing to a non‑compliant password may be rejected later).
• If this is in a managed environment, avoid using the MMC snap‑in for bulk or policy‑sensitive account creation.

Is it a bug?

• It’s a behavioral inconsistency/quirk in Windows tooling and I would treat it as a bug or at least an oversight in MMC. If you can reproducibly show it (include Windows version/build, exact steps, and whether the machine is domain‑joined), file it with Microsoft (Feedback Hub) or open a support case so they can track/fix it.

If you want I can:

• Provide a short repro checklist you can run and paste results from (PowerShell output, secpol settings, OS build).
• Draft a concise bug report template you can paste into Feedback Hub including steps-to-reproduce, expected vs actual, and sample outputs.

Which would you prefer? Also, please tell me the Windows build (winver) and whether the machine is domain‑joined — I can help narrow the explanation further.