Network Management
SAML SSO with Okta fails: “Unknown user” and “Groups claim <X> is missing” in SolarWinds Platform
Users using Okta SAML SSO to access the SolarWinds Platform may see successful SAML authentication but fail authorization with “Unknown user” and 'Groups claim claim_name' is missing” messages. Root cause is a combination of SAML audience (SP Entity ID) mismatch between Okta and SolarWinds, and incorrect SAML group claim configuration (SamlGroupsClaimName and Okta group attribute statements).
First published date
Last published date
Overview
When SAML is configured with Okta as the Identity Provider (IdP) and SolarWinds as the Service Provider (SP), the login flow can reach Okta and return a SAMLResponse, but SolarWinds still denies access. The SAML Configuration Test shows that authentication is configured properly, yet the user is not matched to any SAML individual or group account, and the Groups claim is reported as missing.
This typically happens when:
- Okta’s AudienceRestriction / SP Entity ID does not exactly match what SolarWinds expects, and/or
SamlGroupsClaimNamein SolarWinds is set to a group value instead of a claim name, and Okta is not sending the expected group attribute.
This article explains how to identify these symptoms and correct both the audience and group claim settings.
Problem:
When using Okta SAML SSO to log in to the SolarWinds Platform Web Console, users see that SAML authentication succeeds but they cannot log in.
Typical symptoms:
-
On the SAML Configuration Test page:
-
Title:
SAML Authentication is configured properly, but cannot log in to SolarWinds Platform! -
Message (example):
User ID 'mailto:user@domain.com' has not been matched to any SAML individual account or SAML group. Groups claim 'NE' is missing. This claim is required for authorization via SAML groups and has to be configured in your Identity Provider. -
Groups:
[]orN/A -
IsGroupClaimMissing:
true
-
-
In SAML logs (
SAML.log/OrionWeb.log), messages like:WARN SolarWinds.Orion.AccountManagement.Saml.SamlManager - Groups claim 'NE' (or 'App-Okta-Solarwinds') is missing. SAML authorization via groups will not work without it. WARN SolarWinds.Orion.Web.Saml.SamlAuthorizationManager - Unable to authorize user mailto:user@domain.com with claim groups ''. No matching SAML account or group was found.
-
In some cases, additional error:
ComponentSpace.SAML2.Exceptions.SAMLProtocolException: The audience restriction https://short-host/ doesn't match the expected audience restriction https://fqdn-host.domain.com/.
Symptoms
SAML Test page reports:
- Authentication is configured properly, but the user cannot log in.
- User ID is shown (often as mailto:user@domain.com).
- Groups array is empty or N/A.
- Message includes:
Groups claim '<claim_name>' is missing. This claim is required for authorization via SAML groups and has to be configured in your Identity Provider.
Product section
Cause
There are two common misconfigurations that can occur together:
1. Audience / SP Entity ID mismatch
-
The SAML assertion from Okta contains an AudienceRestriction that does not match the audience (SP identifier) SolarWinds expects.
-
Example:
-
Okta sends audience:
https://<SolarWinds Platform>/ -
SolarWinds expects:
https://<SolarWinds Platform>.domain.com/
-
-
As a result, SolarWinds rejects or flags the assertion with a SAMLProtocolException about audience restriction.
2. Incorrect SAML group claim configuration
-
In SolarWinds Advanced Configuration,
SamlGroupsClaimNameis sometimes set incorrectly to a group value (e.g.App-Okta-Solarwinds) instead of a claim/attribute name (e.g.GroupsorOrionGroups). -
In Okta, no attribute with that name is being sent in the SAML assertion, or the IdP is not sending any group claim at all.
-
Effect:
-
SolarWinds looks for a claim named (for example)
App-Okta-Solarwinds, finds nothing, and sees no groups for the user. -
The SAML Test shows
Groups: []orN/AandIsGroupClaimMissing: true. -
Since group logins rely on matching SAML group values to SAML group accounts, authorization fails with “Unknown user / has not been matched to any SAML individual account or SAML group.”
-
Resolution
Step 1 – Fix the audience / SP Entity ID mismatch
Identify the correct SolarWinds URL / audience
- Use the fully qualified host name that users use to access SolarWinds, e.g.:
https://<SolarWinds Platform>.domain.com/ - This will be the SP Entity ID / Audience URI that both Okta and SolarWinds should agree on.
Check SolarWinds SAML configuration
- In the SolarWinds Web Console, go to:
Settings → All Settings → SAML Configuration. - Verify the Service Provider section:
- Ensure the web console URL and any displayed SP Entity ID or ACS URL correspond to the chosen FQDN (e.g. https://<SolarWinds Platform>.domain.com/Orion/SamlLogin.aspx/).
Update the Okta SAML app
- In Okta, open the SolarWinds SAML application.
- On the General / Sign On tab:
- Update the Audience URI (SP Entity ID) to match the SolarWinds audience exactly.
- Ensure the Single sign on URL / ACS URL matches the SolarWinds SAML login endpoint (e.g. https://<FQDN>/Orion/SamlLogin.aspx/).
- Save changes.
Re-test SAML
- Use the SAML Configuration Test in SolarWinds.
- Confirm the audience restriction error no longer appears in the SAML logs.
If the audience mismatch is resolved but the user still cannot log in, proceed to the group claim configuration steps below.
Step 2 – Configure SamlGroupsClaimName correctly in SolarWinds
Open Advanced Configuration
- Browse to:
http(s)://<SolarWindsServer>/orion/admin/advancedconfiguration/global.aspx - Use the search box to find SamlGroupsClaimName.
Set SamlGroupsClaimName to a claim name (not a group value)
- Example recommended value:
- Groups
- Alternative:
- OrionGroups or another clear claim name.
- Do not set this to the group name itself (e.g. App-Okta-Solarwinds).
- Save the change.
This tells SolarWinds: “Read the list of group values from the SAML attribute named Groups.”
Step 3 – Verify / create SAML group accounts in SolarWinds
- Go to Settings → All Settings → Manage Accounts.
- Click the SAML Groups tab.
- Confirm or create a SAML group account with:
- Group Name: the group value that will be sent by Okta.
- For example: App-Okta-Solarwinds.
- Group Name: the group value that will be sent by Okta.
- Assign appropriate permissions/roles/views to this SAML group.
- Save.
When SolarWinds sees App-Okta-Solarwinds inside the Groups claim, it will use this SAML group account.
Step 4 – Configure Okta to send the group claim
Open the SolarWinds SAML app in Okta
- Go to the Sign On tab.
- Click Edit.
Add a Group Attribute Statement
- Under Attribute Statements / Group Attribute Statements, add or edit a Group Attribute Statement:
- Name: must match SamlGroupsClaimName in SolarWinds, e.g.:
Groups - Filter / Value:
- Configure it so that it includes the Okta group used for SolarWinds access.
- Example: the Okta group App-Okta-Solarwinds.
- Name: must match SamlGroupsClaimName in SolarWinds, e.g.:
Check user membership
- Ensure the affected user (e.g. user@domain.com) is:
- Assigned to the SolarWinds SAML application in Okta.
- A member of the Okta group that should be sent in the Groups claim (e.g. App-Okta-Solarwinds).
After this, a SAMLResponse for that user should contain something like:
<Attribute Name="Groups">
<AttributeValue>App-Okta-Solarwinds</AttributeValue>
<!-- Additional group values, if applicable -->
</Attribute>
Step 5 – Re-test SAML in SolarWinds
- Go to Settings → All Settings → SAML Configuration in SolarWinds.
- Use the SAML Configuration Test with the affected user.
- In the test result JSON, verify:
- UserName is correct (e.g. mailto:user@domain.com).
- Groups is not empty and includes the group value you configured, for example:
"Groups": [ "App-Okta-Solarwinds" ] -
IsGroupClaimMissing is false.
-
Attempt a real SAML login from the login page using “Log in with Okta.”
- The user should now be successfully authorized and mapped to the SAML group.
Validation
The issue is resolved when:
- No more audience restriction errors appear in SAML logs.
- The SAML Configuration Test shows a non-empty Groups array including the expected group(s).
- The affected user can log in via Okta SSO and is granted the permissions defined in the mapped SAML group account.