Passwords and Resets
Where eConnect holds a password, it is set on the user record and must satisfy the policy configured under Security Policy.
Resetting somebody's password
From their record, set Password and Confirm Password, and save. Give them the new password through a channel that is not the account you just reset, and have them change it at first sign-in.
The policy it must satisfy
Password rules are set system-wide and can be turned off entirely. When enabled they can require:
| Rule | Effect |
|---|---|
| Minimum Complexity | Which character classes must appear |
| Minimum Length | Shortest acceptable password |
| Lockout After | Failed attempts before the account locks |
| Lockout Duration | How long a lock lasts |
| Password Expires After | Days before a password must be changed; 0 never expires |
The full detail is in Security Policy. A password that does not satisfy the policy is rejected when you try to set it, so if a reset will not save, the policy is why.
Lockout
Repeated failed sign-ins lock an account for the configured duration. A lock clears itself when that time passes.
Lockouts are worth looking at rather than merely clearing. A user locked once has forgotten their password; an account locked repeatedly, especially outside working hours, is worth investigating before it is reset. Their session history shows the attempts.
Expiry
Where the password policy sets an expiry, a person whose password has aged past it is challenged at sign-in: they are asked to set a new one before the application opens, rather than being refused or let in on an expired credential.
That makes expiry something people deal with themselves, at the moment it matters, instead of a support call.
Where passwords expire, users are required to change them on the schedule set. Setting expiry to zero disables it.
Modern guidance favours long passwords that do not expire over short ones that do, since forced frequent rotation tends to produce weaker, more predictable passwords. Whichever your organisation requires, apply it deliberately rather than by default.
Directory-authenticated accounts
Where an account authenticates against your directory service, eConnect holds no password and none of the above applies — the directory's own policy governs, and resets happen there.
This is worth confirming before spending time on an eConnect reset that will have no effect. Such accounts are marked in the user list.
Users changing their own
People can change their own password from their profile, which is preferable — a password an administrator set is a password an administrator knows.
What is recorded
Password changes are audited under the user administration type. The password itself is never recorded — the audit trail shows that a credential changed, who changed it and when, which is what a review needs. See Reading the Audit Trail.
Failed sign-ins appear in session history, which is where a pattern of attempts becomes visible.