17.7Troubleshooting
Last updated
SAML and OpenID Connect
| Symptom | What to check |
|---|---|
| Test connection fails | The server must be able to reach the metadata URL or discovery document (proxy, firewall, DNS). For OpenID Connect, the Authority must be https:// and match the issuer the provider declares — watch for a missing or extra trailing slash or /v2.0 |
| The identity provider reports a reply URL / redirect URI mismatch | Copy the ACS URL or Redirect URI again from the Single sign-on page, opened on the address users sign in through, and register it exactly. If you use several public addresses, check App:AlternatePublicBaseUrls |
| "Your account has no access to this application" | The account is deactivated; or an account with the same address can sign in with a password, is waiting for password setup, holds System Admin, or is linked through the other protocol or to another identity; or the identity provider sent no email address; or, for OpenID Connect, the address is not marked as verified while an account with it exists |
| The person is signed in but can do nothing | The account has no role. Assign one, or set the Default role for new SSO users for future accounts |
| Sign-in worked once, then fails after the provider rotated certificates | If you pasted metadata XML, paste the new metadata, or switch to Metadata URL |
| The sign-in button is missing | The method is not enabled and saved, or the sso licence module is not active |
Windows sign-in
| Symptom | What to check |
|---|---|
| Continue with Windows is not shown | Offer Windows sign-in is off; the host you are on is not in Allowed hosts; the IIS layout is not applied or the application pool was not restarted |
| The browser shows a credential prompt | The site is not in the Local intranet zone (or not in AuthServerAllowlist), or there is no SPN for the host name so Kerberos falls back |
| Sign-in returns "Windows sign-in did not complete" | The Windows account is not linked to a platform user; it is disabled in Active Directory; it is not in a trusted connection; the page was opened over HTTP; or the request passed through a reverse proxy |
| A role did not change after a group change | Group changes apply at the next Windows sign-in; sign out and sign in with Windows again. Check that the role is named in a mapping and that the group is a domain group |
| The whole API answers with errors after changing IIS | Make sure the layout was applied with the wizard or the script, not edited by hand in web.config, and restart the application pool. To back out, run Set-WindowsSignIn.ps1 -Disable or choose Off in the wizard |
| "Windows sign-in has no trusted Active Directory connection yet." when linking | Choose at least one trusted connection on the Windows form and save |
| "That Active Directory connection is not trusted for Windows sign-in." when linking | Add the account's connection to Trusted connections, or link an account from a trusted connection |
| "That Windows account is already linked to another platform account." | Remove the link on the other user's page first |
| "The System Admin role cannot be granted by an Active Directory group." when saving | Remove the mapping to System Admin; it can only be assigned by hand |
Tip: Keep at least one System Admin account that signs in with a password and two-factor authentication. Single sign-on depends on systems outside the platform, and a password account is your way back in if the identity provider, the domain or IIS is unavailable.
Last updated
Thank you for your feedback.