Password change interval#

To limit local password changes in Sherpa Orchestrator, the installation administrator must enable interval checking. After a password is successfully set or changed, the next change is allowed after 24 hours. The rule applies to Users and Accounts, including administrator changes through the interface and API. LDAP, OpenID and Asset passwords are excluded.

Enabling the restriction#

Set the following in the installation's .env file:

USER_PASSWORD_CHANGE_INTERVAL_ENABLED=true

The default is false: there is no frequency restriction. The interval is fixed and cannot be configured. An invalid flag value causes a configuration error when changing a local password.

After editing .env, the configuration must be applied to every application instance. For a Docker installation, run this command from the installation directory:

docker compose up -d --force-recreate orchestrator

Restarting a container does not update its environment variables. Example: to enable the restriction, replace false with true and recreate the application container. Password length, complexity and history settings do not need to be changed.

Password change behavior#

The interval is measured in UTC from the successful password assignment or change, including initial record creation. For example, a password set on October 21 at 10:00 UTC can be changed starting on October 22 at 10:00 UTC. Midnight does not reset the interval.

If a change is attempted too soon, the form displays the reason and the next allowed change time in UTC. The current password remains valid. Failed attempts and edits to other fields do not move the date. Only one of simultaneous change requests can succeed.

Example: when an attempt is made to change the password for Account training.operator before the interval ends, the form remains open and shows the next change time. The screenshot shows the "Account" dialog with the rejection, in English.

Existing records without a known change date can be changed immediately. The interval starts after the first successful change. The date is also tracked while the restriction is disabled. Complexity checks and the prohibition on reusing any password in the full history remain in effect.

Password expiration is configured separately. If both checks are enabled and the validity period is at least one day, the minimum interval has already elapsed when the password expires. An ordinary administrator change does not bypass the restriction.

Restoring access#

If a password must be changed before 24 hours have elapsed, the installation administrator must:

1. Temporarily set USER_PASSWORD_CHANGE_INTERVAL_ENABLED=false and apply the configuration to every application instance.
2. Change the password through the standard procedure with the required access rights. Complexity and history checks remain mandatory.
3. Restore USER_PASSWORD_CHANGE_INTERVAL_ENABLED=true, apply the configuration and verify login with the new password.

If password expiration also blocks access, the separate USER_PASSWORD_EXPIRATION_ENABLED setting must be considered. If necessary, the administrator temporarily disables it as well, then restores its original value after recovery. Example: after an emergency change, the new password immediately starts another 24-hour interval. Database dates do not need to be edited.