Troubleshooting: Inline Password Reset Does Not Honor the Password Complexity Ruleset

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected: All
     
     

    Overview

    Inline Password Reset can accept, or reject, a new password differently than the Password Complexity Ruleset displayed to the user on the Inline Password Reset page would suggest.

     

    Cause

    Inline Password Reset uses the same configuration page as a dedicated Password Reset Realm, which makes it easy to assume it also enforces Identity Platform's configured Complexity Rules the same way before submitting a new password. It does not. Inline Password Reset is a UI layered on top of the underlying Datastore's own password-change process (Active Directory, for example) that displays Identity Platform's configured Complexity Rules to the user for guidance only. The new password is sent straight to the Datastore, and it is the Datastore's own password policy, not Identity Platform's displayed rules, that determines whether the change succeeds. If the Datastore's policy is stricter than what Identity Platform displays, a password that appears to meet every displayed rule can still be rejected by the Datastore. See SecureAuth's Inline Password Change Configuration Guide for the available configuration options. 

    Resolution

    There is currently no way to make Inline Password Reset directly enforce Identity Platform's Complexity Rules before submitting the new password to the Datastore. The best way to reduce failed resets is to set Identity Platform's Inline Password Reset Complexity Rules to match the Datastore's actual password policy as closely as possible, so what is displayed to the user accurately reflects what the Datastore will accept.


     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.