# 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 | `/.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//v2.0`. ### Okta: org versus custom authorization server `https://.okta.com` and `https://.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://.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](/guides/sso/lockout-recovery).