Troubleshoot SSO
Every SSO error surfaces on the page that caused it. The connection check is what makes a connection live, so a failed check leaves the previous state untouched and locks nobody out.
Domain verification
| What you see | What it means | Fix |
|---|---|---|
| Awaiting DNS after Check now | The TXT record is not visible yet. | Confirm the host is _ledgerbee-sso with no domain appended, and allow for your provider's propagation delay. |
| Use the main domain, not a subdomain | You entered a subdomain. | Claim the apex domain, acme.dk rather than mail.acme.dk. |
| Free email domains cannot be claimed | The domain is a public mailbox provider. | Claim a domain your company controls. |
| That is not a valid domain name | The value is not a resolvable domain. | Enter the part of your email address after the @, with no scheme or path. |
| Record missing on a verified domain | The record stopped resolving. | Re-publish it. Existing members keep signing in; linking a new person by email is paused until it returns. |
| Also claimed elsewhere | Another company verified the same domain. | Both claims stay valid. Each company routes only its own members. |
The most common cause of a stuck verification is entering the fully-qualified
name in the DNS provider's name field. Providers append their own zone, which
turns _ledgerbee-sso.acme.dk into _ledgerbee-sso.acme.dk.acme.dk. Enter
_ledgerbee-sso alone.
Connection check
| What you see | What it means | Fix |
|---|---|---|
| We could not read the identity provider's configuration | <issuer>/.well-known/openid-configuration did not return a document. | Open that URL in a browser. If it 404s, the issuer is wrong. |
| The identity provider reports a different issuer than the one entered | The document's issuer differs from what you saved. | Copy the issuer value out of the document verbatim. |
| The issuer must be a public https address | The URL is not https, or its host does not resolve to a public address. | Use the provider's public issuer. Private and internal addresses are refused. |
| The identity provider's configuration is missing an endpoint sign-in needs | The document lacks an authorization, token, or JWKS endpoint. | Use an issuer whose document declares all three. |
| The connection is missing its issuer, client ID or client secret | One field is empty. | Complete all three and save; saving runs the check. |
Entra ID: the wrong tenant endpoint
https://login.microsoftonline.com/common/v2.0 and /organizations/v2.0
declare an issuer that differs from the one their tokens carry. Use your
directory's tenant ID:
https://login.microsoftonline.com/<tenant-id>/v2.0.
Okta: org versus custom authorization server
https://<your-org>.okta.com and https://<your-org>.okta.com/oauth2/default
are different issuers with different documents. Take the Issuer URI shown on
the authorization server you registered the application against — and prefer the
org one, https://<your-org>.okta.com, which Okta recommends for OIDC single
sign-on and which needs no access policy.
The check passes but nobody can sign in
The check proves your provider accepts LedgerBee's credentials. It does not prove a given person is admitted. When it passes and a first sign-in still fails, the cause is at the provider or in the claim mapping:
| Cause | Fix |
|---|---|
| The application is assigned to no users or groups | Assign the people who should sign in, in the provider's application settings. |
| The subject claim is wrong for this provider | sub unless your provider documents otherwise. oid is the Entra opt-in that lines up with SCIM's externalId. |
| The redirect URI does not match | Re-copy it from LedgerBee with the Copy button and replace it at your provider. It must match byte-for-byte. |
| The person is not a member of the company | Bring them in through SCIM or an invitation. A sign-in never creates an account. |
Member sign-in
A member whose sign-in fails returns to the login page with a generic error. The reason is deliberately not shown to them, so an unsuccessful attempt reveals nothing about who exists.
| Cause | What the member should do |
|---|---|
| Not an active, accepted member of the company | Ask an admin to invite them, or accept a pending invitation. |
| Email address at a domain that is not verified | Ask an admin to add and verify that domain. |
| Provider reports the address as unverified | Verify the address in the identity provider. |
| The connection's credentials changed | Saving the new credentials re-runs the check and brings it back online. |
| A stored identity was issued by a different provider | An admin confirms the issuer, then re-runs the check with Check again. |
An admin can see the specific reason in the company's login events under Settings → Workflows & access.
Enforcement
Each of these refuses the Require single sign-on switch, which lives in the panel the row's Configure enforcement action opens.
| What you see | What it means | Fix |
|---|---|---|
| Single sign-on cannot be required for this domain yet | The connection this domain points at is incomplete, or has not passed the check. | Finish the setup steps and save - saving runs the check. |
| The connection behind this domain last failed to sign anyone in | A sign-in through it has failed since the last passing check. | Fix the cause, run the connection check, then set the requirement. |
| Your own email address is on this domain, and you did not sign in through its connection | Requiring it would end your own session at this company. | Use Sign in through your provider on the same page, then set the requirement. An administrator on a different domain does not hit this. |
| This domain belongs to your organization | The requirement for an organization-owned domain is set per member company by the organization, not by the company. | Ask an organization owner to set it under the organization's SSO tab. |
Locked out
Disabling a connection, removing a domain, or letting a client secret expire stops SSO sign-ins. While no domain requires single sign-on, a member's password, passkey, or personal Microsoft, Google, or Apple sign-in still reaches the company, so anyone who has one can sign in and repair the connection.
A member whose address is on a required domain reaches the company only through that domain's connection. Members on addresses you have not registered are unaffected and can still sign in with any method, so a lockout means every administrator is on a required domain — see Recover from an SSO lockout.