Security policy settings

Security policy settings#

Querona can disable an account that has not signed in for a configurable time. The rule covers every login except the system and spark accounts - standard logins, Windows logins and Microsoft Entra ID logins alike, administrators included. The check runs once an hour on the primary instance by default, so an account is disabled at the first check after it crosses the threshold, not at the moment it crosses it.

The rule is off by default. It judges inactivity by the sign-ins that logon tracking records, so it cannot run without it.

Settings#

Configuration option

Default value

Requires restart?

Description

Disable logins inactive for [days]

0

No

How many days an account may go without signing in before it is disabled. 0 switches the rule off; the largest value is 3650. A value above zero is refused while logon tracking is off, and logon tracking cannot be switched off while the value is above zero - set it to 0 first. A change takes effect at the next check.

Inactivity counted since

Empty

Read-only. The moment from which inactivity is counted. Querona stamps it when the rule is switched on and again when logon tracking is switched back on while the rule is on, and clears it when the rule is switched off. No account is judged on any time before this moment, so switching the rule on never disables an account for time before the rule existed. It also moves after a start whose stored sign-ins end more than the period ago; see Known limits.

How often the check runs is not shown in the Administration Portal. It is the System_Core_SecurityPolicy_InactivityCheckInterval row of the EngineConfiguration table in the metabase, a time span in the d.hh:mm:ss form, 01:00:00 by default. It is read when Querona starts, so a change requires a restart, and the first check runs one interval after the start. A value below one minute, or longer than 24 days, is replaced by the default and reported in the Engine log. Saving the configuration in the portal keeps the stored value.

What counts as activity#

An account’s clock restarts at each of the following:

  • A successful sign-in of any kind - a SQL client over the TDS endpoint with a password, Integrated Windows Authentication or Microsoft Entra ID, or a sign-in to the web interface or the REST API. Every sign-in logon tracking records counts; a failed attempt does not.

  • For a group login (a Windows or Entra ID group), a sign-in by any member through the group. A member that has a login of its own is admitted by that login and does not keep the group’s clock running.

  • An open session on the instance running the check - a client connection, a portal session, or a job that is running under the account at that moment. An application that keeps a connection pool under steady load never opens a new connection and so never signs in again; its account stays enabled as long as a session is open.

  • Re-enabling the account. An administrator who clears Disabled restarts the clock, and the account then shows a sign-in at that moment with no protocol or program name.

An account created after the rule was switched on, and not yet signed in, counts from its creation. An account is disabled once more than the configured number of days has passed since the latest of these moments and the Inactivity counted since moment.

Accounts that exist at installation or upgrade#

Every account that exists when this version is installed is assumed to have signed in at that moment, unless a sign-in is already recorded for it - a recorded sign-in is never overwritten. An upgrade therefore starts every clock at the upgrade, and an account that had never signed in shows Last sign-in at the installation or upgrade moment, with no protocol or program name, until it next signs in.

Administrators#

Administrators are not exempt: a stale administrative account is disabled like any other. Keep at least one administrator signing in within the period, or choose a period long enough for the way the installation is run.

Should every administrator be disabled at once, stop the Engine, re-enable one account by editing the metabase directly, and start the Engine again - a running Engine does not read a login changed outside it:

-- SQL Server, SQLite
UPDATE UserAccount SET Disabled = 0 WHERE Login = 'admin';
-- PostgreSQL
UPDATE "UserAccount" SET "Disabled" = false WHERE "Login" = 'admin';

then sign in with that account within the hour of the start. A direct edit records no activity, so the next check disables the account again unless a sign-in has been recorded for it since.

What a disabled account sees#

Every sign-in path refuses a disabled account. A SQL client signing in over the TDS endpoint with a password, or with Microsoft Entra ID under the account’s own name, is refused with error 18470, Login failed for user ‘<name>’. Reason: The account is disabled. - once its password proved right; a wrong password is answered as any wrong password is (error 18456), the order SQL Server applies. Integrated Windows Authentication over the TDS endpoint, the web interface and the REST API report the general login failure instead, without naming the reason. Each of these refusals counts as a failed attempt for the account.

A disabled group account - BUILTIN\Administrators, a Windows group or an Entra ID group - admits none of its members: it is skipped as if it did not exist, and a member that no other login admits sees the general login failure. Nothing is counted against the group.

To re-enable an account, open it under ADMINISTER ‣ User management and clear Disabled. Re-enabling restarts the clock, as described above.

What is recorded#

Each disable is audited as an alteration of the login by the internal system account, with the text ALTER LOGIN <name> DISABLE - the same event the portal records when an administrator disables an account - see Logging & diagnostics. The audit event reaches a target only where an audit is set up, so the Engine log is the record to count on: one line per disabled account naming its last activity moment, and one summary line per check giving how many accounts were examined, disabled, skipped and why, and how many disables failed.

The text is how the audit describes the change; it is not a statement Querona runs.

Known limits#

  • The portal shows a disabled account as plainly disabled; whether it was disabled by an administrator or for inactivity is visible in the audit trail and in the Engine log only.

  • Sessions the account already holds are not ended. A pooled connection keeps working until it is closed.

  • Jobs run under their owner and requests served through the Data API do not sign in, so a disabled account keeps working in both; a job that happens to be running when the check passes also keeps its owner enabled, as any open session does.

  • Re-enabling an account while logon tracking is off records no activity. Turning tracking and the rule back on stamps a new enforcement moment, so the account counts as active from then on for a full period.

  • An account re-enabled by a direct edit of the metabase needs a sign-in within the hour, as described under Administrators.

  • The open-session check covers the primary instance only; a session held on another instance of a cluster does not keep its account enabled.

  • The check reads the rule from the metabase each time, so a change saved through any instance of a cluster applies at the next check.

  • When the sign-ins stored in the metabase end more than the configured period before the first check after Querona starts - a metabase restored from an old backup, or Querona stopped for longer than the period - Inactivity counted since moves to that check, and no account is disabled for the time before it. A metabase restored from a backup younger than the period is not detected: an account that signed in only after that backup is judged by its sign-ins before it.