The Enable Password Resets setting under Site Settings → Password Resets controls whether users can request a password reset themselves. When on, the "Forgot your password?" link appears on the login page and clicking it kicks off the reset flow. When off, the link is hidden and users who forget their passwords have to contact an admin.
Note that this setting only governs self-initiated password resets. Admin-initiated resets — where an admin opens the user's profile and clicks Reset Password — are always available regardless of this setting. The on/off toggle is about whether users have a self-service path.
What users see when enabled
A "Forgot your password?" link appears below the password field on the login form. Clicking it opens a form asking for their email (or username, depending on the login mode). The user enters their identifier, the platform looks it up, and — if it matches a known account — sends a reset email (or SMS, depending on the Password Reset Method setting).
The user clicks the link in the email, lands on a password-change form, enters a new password (twice, for confirmation), and they're done.
What users see when disabled
The forgot-password link is hidden. Users without password access must contact an admin to have their password reset. The admin opens the user's profile, clicks Reset Password, and either sets a new password directly or sends a reset link via email.
This is more secure (no anonymous reset flow to abuse) but less convenient — your support team will get tickets for forgotten passwords.
When to disable
Three concrete scenarios where disabling makes sense:
1. High-security internal apps
For apps where every account is provisioned by an admin (not self-registered), it's natural for password resets to also be admin-only. The support team is small, accounts are few, and the convenience cost of admin-mediated resets is low.
2. Apps where email is the credential being reset
If a user's email account is compromised, an attacker could request a password reset and intercept it. For apps in industries where this is a concrete concern (banking, healthcare), disabling self-reset and requiring identity verification through an admin is safer.
3. Apps using SSO exclusively
For installs where users authenticate through Azure AD, Google Workspace, or another SSO provider, ActiveManage's own password isn't really used. Password resets aren't relevant.
Three real-world configurations
- Consumer SaaS: Enable Password Resets on, Method email, Time Limit 30 minutes, branded template. Self-service, convenient, expected.
- Internal corporate app: Enable on, Method email, Time Limit 15 minutes, restricted to corporate email domain via custom validation. Self-service but tightened up.
- Highly-regulated app: Enable off. Admins handle every reset and verify identity out-of-band before issuing.
Tip: Even with self-service password reset enabled, consider implementing additional friction for high-value accounts — e.g. admins or accounts that have access to financial data. A custom validation that requires multi-step verification for those accounts adds defence-in-depth without inconveniencing the bulk of users.