AD user can't change password

The issue you’re experiencing with users being unable to change their password despite meeting complexity requirements could be related to several factors within the Active Directory environment and its configuration. Here’s a breakdown of what might be causing the issue and how to resolve it: 1. Password History Enforcement • Current Configuration: Password history is set to 5. • Behavior: If the new password is detected as too similar to one of the last 5 passwords, it will be rejected. • Example: • MM##2222 to FF##2222 is accepted because it’s only slightly different and bypasses complexity checks by being treated as a variant. • MM##2222 to V@7v8F$0 is rejected because it doesn’t “pass” the similarity check due to more complex rules for detecting reused passwords. • Solution: Educate users that their new passwords must be significantly different from their last 5 passwords. 2. Password Complexity Validation • Details: Complexity requirements in AD enforce the use of: • At least one uppercase character • At least one lowercase character • At least one number • At least one special character • Behavior: Some password validation systems may still reject passwords if they include patterns resembling old passwords, even if they meet complexity requirements. • Solution: Test the rejected passwords using net user command or a PowerShell script on a test account to see if they meet AD complexity requirements. 3. Custom Fine-Grained Password Policies • Check if any Fine-Grained Password Policies (FGPPs) are applied to affected users, overriding the default domain policy. FGPPs allow specific password policies to be applied to users or groups, and they might have stricter requirements. • Solution: • Use PowerShell to check FGPPs: Get-ADUserResultantPasswordPolicy -Identity <username> • Ensure there’s no conflict with the default domain policy. 4. Third-Party Password Filter DLLs • If third-party password filters (e.g., for custom validation) are installed, they might impose additional restrictions, such as rejecting passwords with specific patterns or enforcing stricter similarity checks. • Solution: Review any installed password filters. Check the system logs for errors indicating a third-party password filter causing the rejection. 5. Active Directory Password Complexity Bugs • Occasionally, password complexity checks in AD might have bugs or inconsistencies. Ensure the domain controllers are updated with the latest patches and fixes. 6. Effective Password Policy • Verify the effective password policy applied to affected users using Group Policy Results or gpresult command: gpresult /h gpresult.html • Check if the default domain policy settings are indeed being applied. Recommendations 1. Educate users about password history requirements and the importance of significant differences between old and new passwords. 2. Test rejected passwords for compliance with complexity rules on a test user account. 3. Ensure no conflicting fine-grained password policies are applied. 4. Audit the environment for third-party password filters. 5. Update domain controllers with the latest patches and test for any potential bugs. 6. Use tools like the ADSI Edit or Group Policy Management Console (GPMC) to review password policy settings. If the issue persists after verifying all of the above, consider escalating to Microsoft Support or leveraging event logs for more diagnostic information.