Summary

Question

Why all of a sudden an SSO-configured administrator in RUCKUS One receive an HTTP 422 error ("User not authorized as administrator") after successfully authenticating through Azure AD, even though the user is correctly mapped and assigned in

Customer Environment

Symptoms

1. HTTP 422 Error after SSO authentication — The user successfully completes Azure AD (or other IdP) authentication but is redirected back to RUCKUS One with a 422 error: "User not authorized as administrator."

2. Inconsistent login path behavior — Some login attempts redirect to Azure AD SSO as expected; others unexpectedly trigger a RUCKUS IDM/MFA challenge instead.

3. User can authenticate via RUCKUS IDM despite being configured as SSO-only — The administrator logs in through RUCKUS IDM even though they are not provisioned as a local IDM user.

4. Backend log error — Kibana/service logs show:

   StatusRuntimeException: NOT_FOUND: No role for admin: <user_email> on tenant: <tenant_id>

5. Only affects users who previously logged in via IDM — Administrators who have only ever used SSO are not impacted. The issue specifically affects users whose first authentication was through RUCKUS IDM before switching to SSO.

Root Cause

Troubleshooting Steps

1. Confirm the user's authentication history

   • Determine whether the affected administrator ever logged into RUCKUS One using RUCKUS IDM (username/password) before SSO was enabled.

   • Compare with a working SSO-only user on the same tenant to confirm the pattern.

2. Verify Azure AD / IdP configuration

   • Confirm that the SAML Entity ID, Reply URL, and IdP metadata are correctly configured.

   • Validate that the user is a member of the mapped SSO group in Azure AD.

   • Confirm that Azure AD shows a successful authentication event for the affected user (check Azure AD Sign-in logs).

3. Verify RUCKUS One user configuration

   • Navigate to Administration > User Privileges on the tenant.

   • Confirm the user is listed with Auth Method = SSO with 3rd Party.

   • Check whether the user also appears as a RUCKUS IDM user or has dual entries.

4. Check backend logs for role resolution failure

   • Search Kibana logs for the error: No role for admin: <email> on tenant: <tenant_id>

   • This confirms the SSO login path cannot resolve the user's account due to the record format mismatch.

5. Test with a fresh SSO-only user

   • Add a new administrator who has never authenticated via RUCKUS IDM.

   • If the new user can log in via SSO without issues, this confirms the root cause is a prior IDM login corrupting the account record.

6. Delete the affected user and re-add as an SSO user
   • The SSO login works as expected
   • The user switches to Ruckus IDM based authentication, and able to authenticate successfully
     
     
   • The user tries to authenticate with SSO again, and all subsequent attempts fail with the HTTP error 422

Workaround

Delete and re-create the affected administrator as an SSO-only user:

1. Navigate to Administration > User Privileges in RUCKUS One.

2. Delete the affected administrator account entirely (this removes the corrupted IDM-format record).

3. Re-add the user as an SSO administrator:

   • Set Auth Method to SSO with 3rd Party.

   • Ensure the user is correctly mapped via the Azure AD SSO group or individual assignment.

4. Instruct the user to authenticate exclusively through Azure AD SSO going forward.

5. Do not allow the user to access the RUCKUS IDM login page or authenticate via IDM at any point after re-creation.

?? Important: Once the user is re-created as SSO-only, they must never authenticate via RUCKUS IDM again, or the issue will recur.

Resolution

This is a confirmed design limitation