Trusted networks#
A login can be restricted to the networks it is allowed to sign in from. A sign-in from anywhere else is refused before the password is examined, however correct the password is. SQL Server has no equivalent; it is a Querona feature.
Nothing is restricted until you list networks for a login. Every existing login keeps signing in from anywhere.
Setting the networks#
Open the account under , edit it, and fill in Trusted networks with the networks the login may sign in from, separated by semicolons. Each entry is a network in CIDR notation or a single address:
10.0.0.0/8; 192.168.1.0/24; fd00::/8; 203.0.113.7
A single address stands for the network of that one address (/32, or /128 for IPv6). Clearing the
field lifts the restriction.
Write IPv4 addresses as plain dotted quads: a leading zero (010.1.2.3), a hexadecimal octet or a
shortened form is refused rather than read as another address - even where it would name the same one. Write
IPv6 addresses without brackets or a port. An IPv4 address written the way a dual-stack listener reports it
(::ffff:10.1.2.3) is read as the IPv4 address it stands for, so a value copied from the log of a refused
sign-in can be pasted as it is.
The list is checked when you save. An entry that is not a network is refused and named, and nothing is
stored. A prefix whose address has bits set beyond the prefix length, such as 10.0.0.1/8, is refused
rather than silently widened to 10.0.0.0/8: if the single address was meant, write it without a
prefix.
The same list can be read and written through the REST API as the trustedSources member of the user
edit model. A client that omits the member leaves the stored list as it is; an empty value clears it.
How it is enforced#
The check applies to every sign-in that names the login - with a password, with a Windows identity or through Microsoft Entra ID, over the SQL endpoint, through the web interface and through the data API - and a login’s own list is applied before its password is examined, so a refused attempt costs nothing and reveals nothing about the password. A Windows or Entra group login applies its list to every member that signs in through it, and the first group login that admits a member decides. When a Windows account with no login of its own signs in to the web interface with its Windows password, Windows checks that password first, because only then is the admitting group known; the group’s list is applied right after. The test of a Spark connection verifies its reverse account from within Querona, from no network: a login of the Spark reverse account type is not subject to its list there, while any other login chosen as the reverse account is held to its list, so the test refuses a restricted one.
The list is checked when a login signs in. A connection that is already open, and a web-interface session or API token already issued, is not checked again, so a restriction added later applies from the login’s next sign-in.
The address checked is the one the Engine sees: the peer address of the TCP connection, or of the HTTP request. Behind a reverse proxy or a load balancer that address is the proxy’s, so list the proxy’s network, or place the proxy where the client addresses reach the Engine unchanged. Forwarded-for headers are not consulted.
A restriction is enforced as written:
a login with a list is refused from an address that cannot be determined;
an IPv4 network admits IPv4 addresses and an IPv6 network admits IPv6 addresses - to admit both, list both (
0.0.0.0/0and::/0together admit everything);nothing is admitted implicitly, the loopback address included;
a list that can no longer be read - for example after it was edited outside Querona - admits nothing until an administrator corrects it.
Note
The data API connects back to the Engine over the loopback address, with the account the Querona
service runs as. If the login that admits that account - its own login, or BUILTIN\Administrators
when the service runs as a local administrator - has a list, include 127.0.0.1/32 and ::1/128 in
it, or every data API endpoint stops working.
A refused sign-in counts toward the Failed sign-in lockout of the login and origin like any other failure, and is audited like any other refused sign-in. Changing a login’s list is audited as an alteration of the login.
Where it fits#
The list is the network half of a login’s protection: a password that leaks - for example one left in a script - is of no use for signing in from outside the listed networks. It is meant, typically, for administrators and for service accounts that only ever connect from known hosts. The other half is the second factor, a one-time code in front of the password: a code stays valid for its window, so the list is also what bounds where a captured code could be replayed from.