Alright, let's see if the hive mind has encountered this particular flavor of vendor-induced headache. We've been on AuditBoard for about a year, and the SSO setup (SAML 2.0 via Azure AD) has been... mostly fine. Until it isn't.
The maddening part? The configuration is identical for everyone. No custom claims, no fancy group rules—just a standard setup. Yet, for a persistent subset of users (seemingly random, across different departments), they hit the AuditBoard login page, click our SSO button, and get unceremoniously bounced back to the login page in a silent loop. No error message, just a polite rejection. Meanwhile, the rest of us sail right through.
Before you ask the obvious:
* Yes, their Azure AD accounts are provisioned and active in AuditBoard. Double and triple-checked.
* No, it's not browser cache/cookies (tried incognito, different browsers).
* No, it's not a time sync issue on our IdP side.
* The SAML response, as far as our side can tell, is identical between working and non-working users.
This screams "undocumented logic" on AuditBoard's side. Maybe a hidden user limit on our tier? A silent failure on some attribute mismatch they don't bother to log? Their support's current trajectory is the classic "re-create the user" which feels like treating a broken leg with a band-aid.
Has anyone else dug into the logs (yours or theirs) and found a smoking gun? I'm particularly suspicious of:
* **Role or permission assignment quirks** within AuditBoard itself, even if SSO is "just" for authentication.
* **Just-in-time provisioning glitches** where something times out silently.
* **AuditBoard's session management** conflicting with our IdP session length.
Any war stories or gotchas would be appreciated. I'd rather not pay for a "premium support" ticket to learn they have a known bug they don't publicize.
Show me the contract
That silent loop is a classic symptom. You've ruled out the usual suspects, so let's move to the subtle ones.
The most likely culprit is a mismatch in the NameID format between what Azure AD is sending for those users and what AuditBoard expects for their account record. Even with a "standard" setup, individual user attributes in Azure, like their user principal name format, can affect the outgoing SAML assertion. Check AuditBoard's side to see exactly what identifier they have stored for a failing user. It might be a numeric ID vs. an email, for instance.
Also, press AuditBoard support for their sign-in logs. They should be able to see the SAML response hitting their system and why it's being rejected. If they claim they can't, that's a support red flag. The randomness across departments points to a user-specific attribute quirk, not a config-wide problem.