Recover from an SSO lockout
Requiring single sign-on for a domain means only that domain's connection can admit the people whose address is on it. If the provider stops signing anyone in — an expired client secret, a revoked application assignment, a Conditional Access policy that matches nobody, a deleted group — none of them reaches the company, including the administrators who could turn the requirement back off.
Members on a domain you never registered are unaffected: their password, passkey, and personal Google, Apple, or Microsoft sign-ins still reach the company. If one of them is an administrator, there is no lockout — they can turn the requirement off on the SSO page themselves. What follows is for the case where every administrator is on a required domain.
Recovery then goes through LedgerBee support.
Contact support
Email support@ledgerbee.com from an address on the domain the company has verified, and state:
- the company name,
- which domain requires single sign-on, and that it has locked every administrator out,
- what changed at your identity provider, if you know.
LedgerBee confirms you are an administrator of that company before changing
anything, out of band from the email itself. Expect a phone call to a number on
record or a request to publish a one-time TXT record in the verified domain.
An email alone does not establish who you are, and the lockout has already
proved the account's normal sign-in path is unavailable.
Once you are verified, LedgerBee turns the requirement off on every domain at that company. Every other sign-in method reaches the company again immediately: passwords, passkeys, and personal Google, Apple, or Microsoft accounts that already had access. The connections and the verified domains are left as they are, so nobody loses access and each domain is ready to require again once its connection works.
The change is recorded in the company's own activity log under Settings → Organization → Change log, with who made it, when, and the value before and after. Read it once you are back in.
Reduce the chance of needing this
| Do this | Why |
|---|---|
| Track your client secret's expiry date | An expired secret is the most common cause, and the provider gives no warning |
| Re-run the check (Check again, or just save) after any change at the provider | It is what proves your provider still accepts the stored credentials |
Keep the TXT record published | A lapsed record does not lock anyone out, but it does pause linking new members by email address |
| Keep one administrator on an address you have not registered | Their password or passkey still reaches the company, so the requirement can be turned off in-product |
A requirement is not relaxed automatically when the provider stops answering. One that switched itself off whenever a network lookup failed would be no requirement at all, and the most common failure leaves the provider serving its discovery document while refusing every user — so nothing would detect it.