How to configure sign-in and manage sessions

All cluster sign-in settings are in one place: password length, four requirements for password composition, the failed attempt limit, the counting window, and the lockout duration. The settings apply to the entire cluster; there is no separate policy for a VDC (virtual data center) or a role.

This page also covers sessions. Every request to the cluster needs one: without a valid session, a request is rejected before the operation is parsed. Understanding what invalidates a session saves time when investigating reports: half of the "unexplained" rejections turn out to be sessions invalidated after a password change.

Prerequisites

• The Cluster master role to change security settings and unlock accounts. Any authorized user can view password requirements.
• An active sign-in to the cluster interface.
• An understanding of the role model — see vStack Center access model.

How sessions work

At sign-in, the cluster issues a session token, which is then presented with every request. The token is not passed around inside the cluster: at entry, it is converted to a numeric user identifier, which is used for all permission checks. A request without a token is rejected with -9494 "No session token". This is an authentication rejection rather than a permission rejection, and the operation itself never starts.

A token becomes invalid in three cases: the user signs out, the session expires, or the user's password is changed. An invalid token results in -11000: the session is not among the active sessions.

Step 1. Review the current settings

1. Open the Settings section and find the Security policy block.

2. Review the password requirements: minimum length and four character requirements — an uppercase letter, a lowercase letter, a digit, and a special character.

3. Review the lockout settings: how many failed attempts are allowed, the window in which they are counted, and how long the account is locked.

Password requirements are visible to any authorized user: the password change form must show them to everyone. Access to lockout settings is granted by the Edit Security Settings privilege (9001), rather than by the role number. Cluster Master has this privilege, and it can also be assigned to a custom role: only role management privileges (7111, 7112, 7113) are prohibited for custom roles. Therefore, "the block has no lockout settings" means "privilege 9001 is missing," and does not necessarily mean "you are not the cluster administrator."

Editing the policy is more restricted than reading it: only Cluster Master can save changes; privilege 9001 alone is not sufficient.

Step 2. Change the policy

1. Open Settings → Security policy.

2. Enter new values in the numeric settings and toggle the password requirements. You do not need to change the entire policy: settings you do not change retain their previous values.

3. Save the changes.

Parameter	Value	What it controls
max_failed_attempts	integer, at least 1	the number of failed attempts allowed before lockout
failed_attempts_window_minutes	integer, at least 1	the window in minutes in which attempts are counted
lockout_duration_minutes	integer, at least 0	the lockout duration in minutes; 0 means manual unlocking only
password_min_length	integer, at least 1	the minimum password length
password_require_uppercase	toggle	require an uppercase letter [A-Z]
password_require_lowercase	toggle	require a lowercase letter [a-z]
password_require_digits	toggle	require a digit [0-9]
password_require_special	toggle	require a special character

Two values affect the platform's behavior more strongly than the others. A zero lockout duration makes automatic lockout permanent: it does not expire, and only the cluster administrator can unlock the account. This mode is appropriate where every incident is investigated, but it also leaves the user without access until they contact support. A limit of one failed attempt locks the account after the first typo.

Step 3. Verify that the policy works

The quickest check is to set a password for a test account that is known not to meet the requirements. A short value returns -22730 "Password is too short". Each remaining requirement has its own error code.

Code	Policy requirement
-22730	minimum password length
-22731	an uppercase letter
-22732	a lowercase letter
-22733	a digit
-22734	a special character
-22735	the password must not match the account name
-22737	the new password must not match the current password for the same account

The last two requirements always apply and cannot be disabled in the settings.

Next, check lockout: reach the failed attempt limit with the test account and check its state in the Users & Roles section, on the Users tab. For unlocking instructions, see How to manage users.

How to end a session

Signing out of the interface reaches the cluster: the session token immediately stops working. Any user can sign out without a privilege, and signing out does not affect other users' sessions in either mode.

Sign-out scope	What happens	When to use it
current session (default)	only the session you signed out from is ended; other sessions for the same user remain active	normal sign-out from the interface
all user sessions	all sessions issued to this account are ended	signing out from all devices, for example after using someone else's workstation

The cluster records a successful sign-out as a single auth.logout security event, with the user, time, and address. The event appears only after a successful sign-out: a repeated attempt to sign out with an already invalidated token is rejected during authentication and does not create a second event.

Mandatory password change at first sign-in

An account can have a requirement to change its password at first sign-in. After signing in, the user is taken to the password change form rather than the interface, and only that form is available until the password is changed. The form shows the current password requirements before submission, rather than after a rejection.

The user has 5 minutes to change the password; after that, they must sign in again. The permission is single-use and applies only to the user's own password; it cannot be used to change another account's password. After a successful change, the requirement is cleared and the user signs in normally.

If an operation is rejected

Code	Reason	What to do
-9494 "No session token"	the request was sent without a session token	sign in to the interface again
-11000	the session is not among the active sessions: it expired, the user signed out, or the password was changed	sign in again
-403 "Access denied"	a user other than the cluster administrator is changing security settings	perform the operation as Cluster master
-29101 "Security settings not found"	settings are stored in a single record per cluster, and that record is missing	contact support: the settings can be read and updated, but cannot be recreated
-29102	a database error occurred while reading or writing settings	retry; if retrying does not help, contact support
-125 "Temp token expired or invalid"	more than 5 minutes elapsed while changing the password at first sign-in, or the change has already been completed	sign in again and change the password immediately
-126 "Method not allowed with temp token"	another operation was requested before changing the password at first sign-in	change the password, sign in normally, and retry the operation
-127 "Temp token allows changing own password only"	an attempt to change another account's password at first sign-in	the first sign-in form can only change your own password
-22730…-22735, -22737	the new password does not meet the policy	view the current requirements in Settings → Security policy

See also

• Unlocking an account and changing a password as an administrator — How to manage users.
• Roles, privileges, and scopes — vStack Center access model.
• Exact field sets and a summary of error codes — Fields and error codes for access methods.
• Events in the auth category — sign-ins, sign-outs, and authentication rejections — are covered in How to read the log and filter events; the log's structure is covered in Security log.

API methods

API operations covered on this page: auth-security-settings-get, auth-security-settings-set, auth-logout, user-set-password, user-unlock — see the API reference.