Setting a user’s password

An administrator can set a new password for a standard (SQL) account from user management. Users change their own password from their profile instead, which needs no permission at all — see Changing your password.

Set the password

1. Go to ADMINISTER ‣ User management.

2. Select the account and open it for editing.

3. Tick Change password.

4. Fill in New password and Confirm password.

5. Save the account.

This path requires the Alter any login permission — see Access rights.

You are not asked for the account’s current password, and cannot supply it. Only the account owner is asked to prove knowledge of the current password, and that is what makes a self-change safe to allow without any permission.

Note

The one exception is your own account. Open your own login here and the form asks for your current password as well, because setting your own password is a self-change however you reach it. If you sign in with a code from an authenticator app, the field is labelled Current password (with your authenticator code in front): type the six-digit code the app shows now, then your current password, with nothing in between - exactly as you sign in. The password on its own is refused, and the refusal does not say whether the code or the password was wrong. Changing your password is the shorter route.

Warning

Setting a password does not end sessions the account already holds, and does not require the user to choose a different one when they next sign in. An account whose password is reset because it may have been exposed keeps any session opened before the reset.

Which accounts have a password to set

Querona applies the same rule to both paths, and applies it on the server, so it holds however the request arrives — from the profile, from user management, or from a client calling the API directly.

Account	Password can be set
Type Power User or End User, password authentication	Yes — by an administrator here, and by the user from their profile.
Any account using integrated authentication	No. The account holds no password in Querona; the directory that issues the identity holds it.
Type Spark reverse account	No. Its secret is managed by Querona — see Managing Apache Spark.
Type System	No. It is reserved for internal use.

Where the password cannot be set, Querona refuses the change whichever path it arrives by, and the profile tells the user why instead of offering the password fields: an integrated-authentication account is told that its password is managed by the organisation’s directory (Windows or Microsoft Entra ID) and is changed there; any other account is told The password of this account cannot be changed here.

What is recorded

Both paths are audited — see Logging & diagnostics. A user changing their own password and an administrator setting someone else’s are recorded as two distinct actions, and an attempt refused because the current password did not match is recorded as a failed one.

Passwords are never written to the audit trail or to any Querona log, in either path, whether the attempt succeeds or fails.

Changing the password while signing in

A SQL client can ask to change the password as part of the sign-in itself - SqlConnection.ChangePassword in .NET, sqlcmd -Z, and the prompt SQL Server Management Studio shows for an expired password. Querona does not support a password change during sign-in and refuses such a sign-in outright with error 40620, Password change during login is not supported in this version of SQL Server, before the current password is examined; nothing is changed, the current password still signs in and the client reports the failure. The refusal is audited as a failed sign-in under the name the client supplied and is not counted against the login’s failed attempts, since no credential was examined. Change the password from the profile or the user list instead.