Managing User Accounts
The user editor (Settings → Security → Users) includes controls for the state of a user's account: inviting by email, disabling, unlocking, forcing a password change, resetting two-factor authentication, marking service accounts and the External authentication method. None of these need a server setting; they are available to all administrators.
The Users list
Each row shows pills for the account's state:
Pill | Meaning |
|---|---|
Disabled | The account cannot sign in by any method. |
Locked | Temporarily locked after wrong passwords (only when Account Lockout is on). |
Service | A service account used by an integration; never prompted for 2FA or a forced password change. |
The row menu (⋯) offers Edit, Unlock (only while locked), Disable / Enable and Delete. The built-in admin row offers Edit and Unlock only.
Inviting a new user by email
Instead of telling a new user a temporary password, let them set their own:
Create the user as usual (name, login, email, groups).
Switch on Email the user a link to set their own password. The password fields disappear; a random password is generated behind the scenes and never shown to anyone.
Click Save & Apply. The user receives a welcome email with a Set your password link, valid for 72 hours.
The user clicks the link, chooses a password (the password security rules are listed and enforced if that setting is on), and signs in. If two-factor authentication is required, they set that up next.
Requirements: outgoing email configured (Settings → Scheduler → Mail Settings) and Public URL set in Security Settings. The switch is only offered for Password-type users with an email address; the editor shows a warning if email is not set up. You do not need to tick Require password change at next login — the link already lets the user choose their own password.
Customizing the welcome email: Settings → Server Settings → Security Settings → Self-Service Account Recovery → Welcome email. Edit the subject and the message; {product}, {username} and {firstname} are filled in automatically ({product} is the Product name from Settings → Server Settings). The Set-password button and the expiry note are always added below your message.
Sending a setup or reset link later
Open an existing Password-type user; under the password fields:
Send setup link — re-sends the welcome email with a fresh 72-hour link (for users who never signed in or lost the first email).
Send password reset link — sends a standard reset link valid for 1 hour.
Both work even if self-service password reset is turned off and are not subject to the self-service rate limit. Each send is recorded in the Audit Log.
Disabling a user
Disabling blocks a user from signing in by any method while keeping their account, dashboards, schedules, and permissions. Use it for employees on leave, contractors between engagements, or any account you may need to restore.
Open the user, scroll to Additional Options and turn on Account disabled (or choose Disable from the row menu in the list).
Click Save & Apply.
The user is signed out immediately if they are signed in. Any sign-in attempt afterwards fails with the standard invalid-login message, including SSO, Windows authentication, magic links and password reset — the user is not told the account is disabled (this avoids confirming account names to outsiders). The Audit Log records the disable and each refused sign-in as "Login refused – account disabled".
To restore the user, turn Account disabled off and save, or choose Enable from the row menu.
Disable vs. delete. Deleting removes the user and their content. Disabling keeps everything and can be reversed. A disabled user still appears in user lists and still counts toward licensing.
The built-in admin account cannot be disabled. Yurbi uses it internally; the switch is hidden for that account.
Unlocking a user
If Account Lockout is on and a user has entered the wrong password 5 times, the list shows a Locked pill and the editor shows Locked until with the time the lock expires. Choose Unlock from the row menu, or click Unlock in the editor, to let them sign in now.
Forcing a password change
Turn on Require password change at next login and save. The next time the user signs in with their password, they must choose a new one before reaching the application. The switch clears itself when they do.
Use this when you suspect a password has been shared. (For new users, the invite link above is the better option.)
This applies only to users who sign in with a Yurbi password. It has no effect on SSO, Windows or External users, and is skipped for service accounts.
Forcing a change for everyone. To require all password users — or all users whose password is older than a number of days — to change at next sign-in, use the ForcePasswordResetAll API call described in the API documentation, or contact support. Service accounts are not affected.
Two-factor authentication
The Two Factor Authentication dropdown has three values:
None — no administrator action. Users may still set up 2FA themselves if the server mode is Optional.
Ask to set up 2FA at next sign-in — the user sees the setup screen at their next sign-in. In Optional mode they may skip it, and are asked again each sign-in until they enroll.
Duo — assigns Duo to this user (shown only when Duo is an allowed method).
Below the dropdown, the Two-factor line lists the user's enrolled methods. Reset 2FA removes all of them, plus backup codes and remembered devices, and ends the user's current session — use it when a user has lost their phone or authenticator. See Two-Factor Authentication (2FA).
Service account
Turn on Service account (API integration) for accounts used by automation — API integrations, embedding host accounts, Server Sync, scheduled exports. A service account is never asked for a second factor or a forced password change, so those features cannot break the integration. See Service Accounts for Integrations and Embedding for the rules and recommendations.
Authentication method: External
The Authentication method list has an option External, alongside Password, SSO, and Windows. Choose it for users who are always authenticated by another system (for example, an identity provider that sends the SSO header) and should never have a Yurbi password.
External users:
Cannot sign in with a password, reset a password, use a magic link, or be invited by email.
Do not see the Change Password or Two-factor sections in their profile.
Are not subject to Account Lockout, forced password change, or two-factor mode. Those controls belong to the identity provider.
Existing SSO users are unchanged; External is simply the clearer choice for new accounts that will never use a local password.
Changing a user's password yourself
The Change password dialog from the Users list sets a new password immediately. If Enhanced Password Security is on, the same rules apply and a hint appears under the field; passwords are trimmed of leading and trailing spaces and a blank password is rejected. Each change is recorded in the Audit Log with the administrator who made it.
Audit trail
Invites, reset links, disable, enable, unlock, password changes, two-factor reset and service-account changes each write an entry to Settings → Audit Log with the administrator and the affected user.
Frequently asked questions
Does this change the user API my integration uses? No. Every new field is optional; requests that omit them behave exactly as before, and omitting the two-factor field never removes a user's own 2FA setup.
Can I disable or force a password change for many users at once? Not from the user interface. Each user is edited individually; the bulk forced-change option is available through the API.
I saved a user and got "User Login Name already exists." Another account already uses that login name. Login names must be unique; choose a different one.