Security configuration

Security configuration

Use this checklist when preparing a Password Reset installation for real users. Authentication, target-account authorization, directory permissions, and transport security must all be configured; a valid-looking UI is not an authorization control.

Authenticate and authorize the reset

Use an authentication method that remains available when the directory password is forgotten. Configure the AuthN SAML SP with your own trusted IdP metadata and signing certificates. Keep signature and assertion validation enabled; test both successful and rejected sign-ins. The bundled NoOpPwdReset configuration is a synthetic demonstration, not a production identity check or a real password reset.

For a delegated reset, the trusted IdP and pipe must restrict which target account the actor can manage. Require both on_behalf_of_user_name and on_behalf_of_display_name in the server-side session. Never treat a target name typed by a browser as permission to reset that account. See On behalf of configuration.

Protect transport and credentials

• Serve the browser-facing application over HTTPS in production. Verify the public URL, reverse-proxy configuration, and SAML endpoints together.
• For Active Directory password operations, use LDAPS. Keep ssl_trust_all set to false on both lookup and reset connections. Trust the directory CA through the JVM or a configured truststore. A connection with certificate errors should fail rather than be made to work by disabling trust checks.
• Delegate only the AD permissions needed for the managed accounts; see AD permissions. Keep cloud application permissions limited to the required reset integration.
• Store deployment credentials, private keys, and truststores in protected customer configuration. The documentation's placeholder passwords are not usable deployment values. Do not commit real credentials or include them in support reports.

Understand password-rule enforcement

The API returns the selected rule list to the browser. The UI evaluates those rules and disables submission until they pass. repeat compares the two browser fields; breach performs a browser-side check against an external service. Neither is an independent directory-side policy.

The reset handler forwards the selected password_policy_id and the new password to the configured pipe; it does not itself evaluate the submitted password against every configured rule. Enforce the required server-side policy in the directory or reset integration as well. Do not rely on a disabled browser button to enforce a security boundary.

The reset API requires an authenticated session and XSRF protection. Preserve the X-XSRF-TOKEN handling in any custom client. For a test installation, verify that a reset without an authenticated session or without a valid XSRF token is rejected before it reaches the reset pipe.

Keep secrets out of logs

Do not dump reset requests, sessions, or token-bearing state. A reset request contains new_password. Use CEF events and the trace identifier for operational follow-up, and keep temporary diagnostics scoped to a synthetic test environment. Remove diagnostics when the investigation is complete.

Verify before use

With synthetic accounts, test a successful reset followed by a real directory sign-in; a rejected password; an unauthenticated request; a failed authentication; and a delegated request outside the actor's scope. Check that failure responses do not disclose whether an arbitrary account exists. Review the collected logs for password, token, assertion, and private-key material before sharing them.