Force Password Reset on Logon

What the password reset enforcer does

This Automox Worklet™ forces every local user account on a Windows endpoint to reset its password at the next successful logon. The Worklet does not change passwords or unlock accounts. It flips two account flags so Windows itself presents the password change dialog when the user signs in again.

The evaluation script is intentionally short. It returns exit code 1 unconditionally, which schedules remediation on every policy run. That design lets the same Worklet behave as either a one-shot FixNow action or a recurring enforcement loop, depending on how the policy is scheduled. Pair it with a one-time policy for incident response, or a daily schedule when you want every newly created local account to inherit the same reset-on-logon posture.

The remediation script enumerates accounts with (Get-CimInstance -ClassName win32_useraccount).Name and iterates each account. For every name it runs wmic useraccount WHERE "Name='$u'" set PasswordExpires=true to flip the password-never-expires bit, then net user $u /LogonPasswordChg:yes to set the must-change-at-next-logon flag. If a single account fails, the script catches the exception, writes the username to stdout, and continues with the rest of the list.

On a modern Windows host, the same outcome can be reached with the newer LocalAccounts module using Set-LocalUser -PasswordNeverExpires $false plus a NetUserSetInfo call. The WMIC and net user combination has the widest compatibility across Windows 7, Server 2008 R2, and every supported version since. The Worklet picks the broadly compatible path so a single policy works against the full Windows footprint.

Why force a password reset at the next logon

Stale local credentials are an unmanaged risk surface. A shared service account password set at provisioning, a contractor account left behind after a project ended, or an emergency break-glass account from a past outage will sit on the endpoint indefinitely. Nothing forces a rotation unless you build the trigger yourself. NIST 800-53 IA-5 (Authenticator Management) and NIST SP 800-63B both address event-driven authenticator rotation in response to suspected compromise or personnel change, the CIS Microsoft Windows Benchmark expects local accounts to be governed under its account-management controls, and HIPAA Security Rule 164.308(a)(5) requires password management procedures. Forcing a reset at the next logon is the fastest mechanical control that satisfies all three.

Local accounts also accumulate in the shadows. A service account a vendor installer created during a software deployment, a temporary admin a help-desk technician left active after a migration, a default Administrator account on a freshly imaged endpoint that never received its first password change. The Worklet enumerates every Win32_UserAccount on each evaluation, runs wmic useraccount to set PasswordExpires=true and net user /LogonPasswordChg:yes against each name, and reports the per-account result so a missed local account or a rebuilt golden image is caught by the next evaluation rather than the next audit.

How the password reset enforcement runs

1. Evaluation phase: The evaluation script exits with code 1 every run. There is no state read, no comparison, and no skip path. The design is deliberate. Remediation fires on every scheduled execution, so a freshly created local account on a long-lived host inherits the reset-on-logon flag the same way an account that was present at first deployment did.

2. Remediation phase: The remediation script collects every local account name from win32_useraccount and loops through the list. For each account it runs wmic useraccount to set PasswordExpires=true, then net user <name> /LogonPasswordChg:yes to require a change at next logon. Per-account failures are caught in a try/catch and printed as "Unable to modify User: <name>". Errors surface in the Automox activity log without halting the rest of the loop.

Force password reset requirements

• Windows 7 or later, Server 2008 R2 or later, with PowerShell 3.0 minimum (the Automox agent context already meets this on every supported Windows version)

• wmic.exe and net.exe on the endpoint PATH; both ship by default, but custom hardened images sometimes remove WMIC on Windows 11 24H2 and later – verify before scheduling broadly

• Administrative privileges to modify local user accounts (the Automox agent runs as SYSTEM, which satisfies this)

• A communicated password complexity policy already enforced via Group Policy or Local Security Policy, so the new passwords users choose at the change prompt meet your minimum length, complexity, and history rules

• Out-of-band notice to end users before a wide rollout; a fleet-wide reset prompt with no prior communication generates a help desk surge the morning after

Expected logon prompt after enforcement

On the next interactive sign-in, each affected local user sees the Windows message "The user's password must be changed before signing in." The user is sent through the standard credential-change flow before the desktop loads. Passwords that do not meet the configured complexity, length, or history requirements are rejected by Windows, not by the Worklet. Once a valid password is set, the session continues normally and the LogonPasswordChg flag clears for that account.

Validate the change in three ways. First, query the account directly with net user <name> and confirm that "Password expires" reads a near-immediate date and "User may change password" is Yes. Second, run Get-LocalUser | Select Name, PasswordExpires, PasswordRequired on Windows 10 1607 and later to see the same state in PowerShell. Third, review the Automox activity log for the policy run; a successful run reports exit code 0 with no "Unable to modify User" entries.

Exclude built-in or service-tied local accounts that legitimately must not be touched, such as an account that drives an unattended scheduled task. Filter the user list in the remediation script before the foreach loop, or scope the policy to device groups that do not contain those hosts. Re-running the Worklet against an account that already has the reset flag is safe. Windows re-applies the same state and the user still sees the change prompt on the next logon.