A locked-out tenant

One person unable to sign in is a user problem. Everybody unable to sign in is a different article, because the ordinary remedies all begin with ask an administrator, and there is no administrator.

This is written to be read in that situation, so it starts with the two things worth doing in the first five minutes and explains the causes afterwards.

First: two things to try before anything else

1. Try an account whose email address is outside any federated domain you route. If your organisation uses identifier-first sign-in, everybody at the routed domain is sent to your identity provider and never offered a password box. An account at another domain still gets one, and if your identity provider is the thing that has failed, that account is your way in.
2. Try the emergency access account. If you created one and stored its credentials the way you store the keys to the building, this is what it is for. If you never created one, note it now for after the incident — it is the single control that turns this article into a ten-minute inconvenience.

If neither works, read on to identify which of the five causes you have, because they need different remedies and two of them cannot be resolved from outside.

The five ways an organisation locks itself out

1. A sign-on policy that refuses everybody

This is the one the platform actively tries to prevent, and understanding the guard tells you whether it is your cause.

Saving a sign-on policy that would deny every administrator is refused with HTTP 409, and the refusal names them. The check evaluates each administrator twice — from inside no network zone at all, and from inside every zone you have defined — so a policy is only refused when there is genuinely nowhere any of them could sign in from. Administrators who are already inactive, suspended, deprovisioned or locked out are excluded, so the check cannot report a survivor who could not actually have helped.

So a policy you saved cannot be the cause on its own. What can be the cause is a change made after it:

• The last administrator the policy did not cover was removed, suspended or deprovisioned afterwards. The guard runs at write time and cannot see the future.
• A network zone was edited so that the address range the policy relied on no longer matches your office.
• Rows were written straight into the database rather than through the API, bypassing the guard entirely.

2. Federated sign-in broke and nobody has a password

The most common cause in practice, and the least dramatic. Your domain routes to your identity provider; the provider has an outage, a certificate rolled, a client secret expired, or somebody removed the DNS challenge record and the domain was demoted after its seven-day grace period. Everybody at that domain now reaches a sign-in page that will not send them anywhere useful.

If people were provisioned through federation they may never have had a Qorionix password, so use a password instead is not available to them. Check three things in this order:

1. Is it your provider? Try signing in to something else that federates to it. If that is broken too, this is not a Qorionix problem and there is nothing to fix here.
2. Has the domain been demoted? An expired signing certificate on a WS-Federation trust and a removed TXT record produce different symptoms — the first fails at the provider, the second stops routing entirely and sends people to a password box. See Federated domains and domain verification.
3. Is there an account outside the routed domain? That is your way back in, and it is why the previous article recommends keeping one.

3. Every administrator has lost their second factor

Clearing somebody's authenticator requires an administrator, so an organisation whose administrators have all lost theirs cannot clear anything. Recovery codes do not currently help here: they work at a step-up prompt, from a session you already hold, and not at a password prompt. I enrolled MFA and now I cannot get in explains that gap in full.

This needs an operator too. It is also the single most preventable item on this list: two administrators with factors on separate devices survives one lost phone, and one does not.

4. Everybody was suspended or deprovisioned

Usually a bulk operation that did more than intended, or an offboarding script that ran against the wrong filter. Sign-in checks whether the account is active, so a suspended account is refused with user account is inactive regardless of anything else.

5. There was only ever one administrator, and something happened to them

They left, their account was disabled as part of an offboarding, their laptop and phone went together, or their address stopped receiving mail. Nothing in the platform is broken; there is simply nobody holding the role that could fix it.

This is a governance failure rather than a technical one, and it is the reason Who can see and do what recommends exactly two administrators — one being your backup — rather than one or five.

What we can and cannot do about it

Being direct about this is more useful than reassurance.

What we will ask for: your organisation's name and identifier, the email address of somebody who held admin, and what changed immediately before it stopped working. That last one is usually the whole diagnosis. Support access and what we can see sets out what an operator is able to reach and what is recorded when they do.

Preventing the next one

Four things, in the order they pay off. None takes more than ten minutes.

1. Two administrators, on separate devices, each able to clear the other's second factor. Test it once — have one clear the other and re-enrol. An untested recovery path is an assumption.
2. One emergency access account at an address outside any domain you federate, with a password and its own second factor, stored the way you store the keys to the building. Sign in with it once a quarter so you find out it works before you need it.
3. Activate a restrictive sign-on policy inactive first, and read the trace. An inactive rule appears in the evaluation as skipped, so you can confirm it is in the position you meant before it can decide anything. Sign-on policies and the decision trace.
4. Check the case of the status field on any policy you rely on. It is compared as the exact literal ACTIVE; a policy saved as active is stored, listed, displayed and silently never applied. That fails in the safe direction — but it means a policy you believe is protecting you may not be.

The uncomfortable pattern behind almost every one of these: an organisation protected every account well and left no way back in. Security controls that cannot be recovered from are not stronger than ones that can — they are just more likely to be the thing that stops you working.