We are trying to get Azure AD SSO to Splunk working but we have AD users that contain more than 150 group memberships which therefore means Azure sends the group information as a digest link instead of the actual groups added to the assertion. We are trying to use the F5 as the SP and have it add the group claims into the SAML assertion.
We currently got the policy setup with the Azure IDP to F5 SP, on prem query, pulling out the group memberships. We setup the IDP to SP connection, with the needed attributes added, but we're getting a loop once we get to splunk reaching back. We see requests coming from splunk, but no response from the F5.
Has anyone run into this same issue with the Azure 150 group limit while trying to get the SSO working with Splunk and do you have a better solution?
We're hitting the limit here,
we haven't resolved it yet, but this might be at least more info for anyone else coming across the issue...
Update via Splunk support:
The issue is an Enhancement Request : SPL-159073 is that if an Azure SSO user is a member of more than 150 groups a link is sent rather than the group details, and at present Splunk doesn't handle that link. We also encountered some cases where there are more than 100 groups, not 150 as indicated.
There's also a (draft as at time of support ticket) Splunk knowledge article support provided (reproduced with permission):
Title - Splunk - Azure SAML/SSO authentication error "saml response does not contain group information"
Summary - Instructions on how to avoid receiving the error "saml response does not contain group information" when connecting to Splunk with SAML via Azure configured.
Description: To ensure that the token size doesn't exceed HTTP header size limits, Azure AD limits the number of objectIds that it includes in a groups claim. If a user is member of more groups than the overage limit (150 for SAML tokens, 200 for JWT tokens), then Azure AD does not emit the groups claim in the token. Instead, it includes an overage claim in the token that indicates to the application to query the Graph API to retrieve the user's group membership.
How to Identify:
- Splunk is configured for SAML authentication with Azure AD as the Identity Provider
- You attempt to login to Splunk with an Azure AD user which is a member of a SAML group configured in Splunk, and a member of more than 150 Azure AD groups in total (including nested groups).
- You receive the error "saml response does not contain group information" when logging in to Splunk.
Investigation: Enhancement Requests: SPL-134770 SPL-159073
Option 1: Reduce the overall group membership for each connecting Azure AD user to less than 150.
Option 2: Use Azure Application Roles instead of Azure AD Groups for authorization:
Using Application Roles: https://social.technet.microsoft.com/wiki/contents/articles/40055.azure-ad-application-roles-essenti...
Details on Azure AD group sending behavior: https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-Active-Directory-now-wi...
In talking with some folks I think we found a good way to approach this and make it work for you.
If you can restrict the roles being sent to Splunk to be less than 150 per users, then Azure will not send the url and actually send the roles for Splunk to map.
The normal approach taken is to leverage Azures Application Roles
This issue can be worked around by leveraging "Application Roles" in Azure instead of Azure AD Groups.
This is done by:
1. 1) Configuring appropriate Application Roles on the Azure side
2. 2) Updating the Splunk SAML configuration "Role Alias" to use: http://schemas.microsoft.com/ws/2008/06/identity/claims/role
3. 3) Creating SAML groups to match the Application Role names
This should get you a valid workaround to the issue you are facing if needed never hesitate to open a support case.
We are here to help make you a success with Splunk.
Has anyone successfully implemented this workaround? We are not having any luck.
While I have never run into this one myself, I am aware of the issue.
Azure AD limits the number of objects it includes in the groups claim. If a user is a member of more groups than 150 for SAML, then Azure AD does not emit the groups claim in SAML Assertion. Instead, it will replace the group attribute (usually named http://schemas.microsoft.com/claims/groups) with a group.link attribute (http://schemas.microsoft.com/claims/groups.link) that will contain a link back to https://graph.windows.net//users//getMemberObjects.
This will cause the role mapping on the platform to be ineffective for the user the Assertion is applicable to.
Maybe filtering the number of groups passed in the assertion would work, however, I am not sure how best to approach that.
There is currently an enhancement request opened to have a way to work around this Microsoft limitation added to Splunk.
Is there any update to this issue? The workaround of using roles instead of groups within Azure AD does not work for Splunk Cloud since it requires the ability to edit the app registration, and the SSO app registration for Splunk Cloud is owned by Splunk. There is only one role available within the Splunk Cloud app registration, "Splunk Users", so it would only work if all your SSO users including your admins have the same role within Splunk, since that is the only role available to Azure AD to pass to Splunk. The situation could be improved somewhat if Splunk added additional roles within the app registration such as "Splunk Admins", "Splunk Power Users", etc. but it would still not provide the same granularity of roles that you can currently achieve by mapping groups to roles within Splunk itself.
This is done through Azure group filtering options in the Enterprise App for Splunk that you created.
No more issues with users that have large membership groups. Not sure why I didn't find this answer anywhere else.
This seems to be working so far. You are a rock star! Many thanks.