| Previous | Next |
| ERROR_NO_CALLBACK_ACTIVE | ERROR_PWD_TOO_RECENT |
ERROR_PWD_TOO_SHORT
What ERROR_PWD_TOO_SHORT means
The account provider evaluated the new password and rejected it before completing the change. The effective minimum can come from local policy, domain policy, fine-grained password policy, or an external identity provider.
Where it commonly appears
- Password-change and reset operations
- Account provisioning
- Domain joins and service-account rotation
- Applications that call Windows account-management APIs
Likely causes
- The password contains fewer characters than the effective minimum
- The application validated against stale or local policy instead of domain policy
- Normalization or encoding changed the submitted length
- A fine-grained policy applies specifically to the target account
Diagnostic checklist
- Identify the authoritative account store and effective policy for that account
- Compare character count after the same normalization used by the API
- Check fine-grained domain policies and identity-provider rules
- Avoid recording the rejected password in logs
Guidance for developers
Do not hard-code a minimum as the only client-side rule. Client validation can improve feedback, but the authoritative server result must be handled. Return a policy-oriented message without disclosing unnecessary security details to unauthenticated callers.
Guidance for administrators
Review the effective policy rather than only the local security policy. For service accounts, update rotation tooling so generated credentials satisfy the current minimum.
Example incident
A domain user is subject to a 16-character fine-grained policy while the application UI enforces only eight characters. The UI accepts the value, but the domain controller returns this code. Querying or documenting the effective policy fixes the user experience.
Related conditions
ERROR_PWD_TOO_LONG describes an upper-bound or provider limitation; ERROR_PWD_HISTORY_CONFLICT and ERROR_PWD_TOO_RECENT describe reuse and minimum-age rules.
Operational decision points
Engineering analysis should anchor this result in a minimum-length policy condition and not merely a transient API failure. For ERROR_PWD_TOO_SHORT, the deciding evidence is authoritative store, effective minimum, fine-grained policy, normalized character count. Preserving this first-occurrence evidence is more useful than increasing retry frequency for investigation sequence 18.
- Impact boundary: identify the exact process, account, device, file, session, host, or connection affected by this result; do not assume the whole machine is in the same state.
- State change required: the next attempt is justified only after the relevant minimum-length policy state can differ from the failed attempt.
- Partial outcome: verify whether the operation allocated resources, changed data, sent a request, or modified policy before this result was returned.
- Escalation evidence: preserve authoritative store, effective minimum, fine-grained policy, normalized character count together with component version and the first preceding failure.
Concrete recovery example
Consider a case where a client enforced eight characters while the account required sixteen. Repeating the same call leaves the underlying condition unchanged and produces another this result. The durable response is to request a new value satisfying the effective account policy. Validation for it should use one controlled operation and inspect both the returned status and the resulting state associated with case 18.
Monitoring and validation
A monitoring rule for it should distinguish first occurrence from repetition, group events by affected object, and correlate them with deployments or configuration changes. The recovery is complete only when the expected minimum-length policy state is present and consistent; absence of another log line by itself is not sufficient proof.
Retain the original this result event until validation for investigation case 18 is complete. After it is corrected, verify that no partial or stale artifact specific to remediation sequence 18 remains before declaring recovery complete. This it-specific verification prevents a hidden secondary problem from surviving after remediation step 18.
References
Looking for a different code? Search another status or error code.