apereo/cas · error
Using no-op password change implementation. Appropriate…
Error message
Using no-op password change implementation. Appropriate password management service is not configured.
What it means
NoOpPasswordManagementService is the fallback PasswordManagementService installed when no real password-management backend (LDAP, JDBC, REST) is configured. Its changeInternal logs this warn and returns false, meaning every password change attempt silently does nothing — the user is told the change failed.
Solutions
- Add the appropriate password-management module (cas-server-support-pm-ldap, -jdbc, or -rest) to the build
- Configure cas.authn.pm.ldap/jdbc/rest connection and search settings so the real service bean is created
- Disable cas.authn.pm.enabled if password management is not intended
- Verify at startup that the active PasswordManagementService bean is not NoOpPasswordManagementService
Example fix
// before implementation "org.apereo.cas:cas-server-support-pm-webflow" // after implementation "org.apereo.cas:cas-server-support-pm-webflow" implementation "org.apereo.cas:cas-server-support-pm-ldap" // plus cas.authn.pm.ldap[0].ldapUrl=... etc.
Defensive patterns
Strategy: validation
Validate before calling
// at startup, fail fast if PM is enabled but no-op
if (casProperties.getAuthn().getPm().isEnabled()
&& passwordManagementService instanceof NoOpPasswordManagementService) {
throw new IllegalStateException("PM enabled but only the no-op service is configured");
} Type guard
boolean isNoOpPmService(PasswordManagementService svc) {
return svc instanceof NoOpPasswordManagementService;
} Try / catch
try { pmService.change(changeRequest); }
catch (Exception e) { log.error("Password change failed", e); }
// always check the boolean result — no-op returns false Prevention
- Add a PM implementation module whenever cas.authn.pm.enabled=true
- Assert the active bean type in a startup health check
- Monitor changeInternal returning false as an indicator of a no-op deployment
When it happens
Trigger: Password reset flow reaches the change step while no cas.authn.pm.* backend module (pm-ldap, pm-jdbc, pm-rest) is on the classpath/configured, so CAS wires the no-op implementation.
Common situations: cas.authn.pm.enabled=true but no implementation module added to the build; LDAP PM module present but connection properties missing so the fallback is used; overlay copied without the pm dependency.
Related errors
- No storage service is configured to handle the account…
- No user can be accepted because none is defined
- Not all requested multifactor providers could be found…
- Cookie name is undefined
- List of candidate multifactor authentication providers is…
AI-assisted analysis of apereo/cas@e7288fc434 (2026-09-08).
Data as JSON: /api/errors/ade33a219fc33105.
Report an issue: GitHub.
Appendix: source
Thrown at support/cas-server-support-pm-core/src/main/java/org/apereo/cas/pm/impl/NoOpPasswordManagementService.java:25
import org.apereo.cas.util.crypto.CipherExecutor;
import lombok.extern.slf4j.Slf4j;
/**
* This is {@link NoOpPasswordManagementService}.
*
* @author Misagh Moayyed
* @since 5.1.0
*/
@Slf4j
public class NoOpPasswordManagementService extends BasePasswordManagementService {
public NoOpPasswordManagementService(final CipherExecutor<Serializable, String> cipherExecutor,
final CasConfigurationProperties casProperties) {
super(casProperties, cipherExecutor, new InMemoryPasswordHistoryService());
}
@Override
public boolean changeInternal(final PasswordChangeRequest bean) {
LOGGER.warn("Using no-op password change implementation. Appropriate password management service is not configured.");
return false;
}
}
View on GitHub (pinned to e7288fc434)