| Previous | Next |
| STATUS_IO_REPARSE_TAG_NOT_HANDLED | STATUS_STOWED_EXCEPTION |
STATUS_PWD_TOO_LONG
Find the component that imposes the upper bound before shortening passwords globally
STATUS_PWD_TOO_LONG reports an upper-length rejection. Unlike the standard Windows Minimum password length policy, an upper bound can come from the account provider, a legacy authentication package, a password filter, a synchronization connector, or another policy layer used by the account. The NTSTATUS value alone does not name that component.
Trace the password-change path end to end while protecting the secret. Record character or byte length at trusted boundaries, the account authority, and the exact provider that returns the failure. A Unicode-capable UI can hand data to an older connector with a fixed-size field, or a workflow can transform a generated passphrase before submission. Those are implementation limits, not reasons to reduce password length for every user.
Do not log the password to prove where truncation occurs. Instrument lengths, encoding, return codes, and correlation IDs instead. If the effective directory policy is correct but one legacy client fails, fix or replace the incompatible client. Security guidance increasingly favors longer passwords and passphrases, so a discovered application-side maximum deserves explicit compatibility treatment.
What to inspect
- The account provider and password-changing component that actually returns the status.
- Character count, encoded byte count, and any transformation or truncation at each trusted API boundary, without recording the password.
- Whether the same account accepts the value through a native administrative tool but rejects it through one connector or application.
References
- Microsoft: Windows password policy settings
- Microsoft: Fine-grained password policies for AD DS
- NIST SP 800-63B: Password guidance
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.