Trouble with Azure AD SSO to F5 SP- Issue with 150 group limit

[davidstuffle]

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?

[bwakely]

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

Resolution:

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:

• Azure - Define the required Application Roles
• Splunk - Update the SAML configuration "Role Alias" to use: http://schemas.microsoft.com/ws/2008/06/identity/claims/role
• Splunk - Create SAML groups to match the Application Role names.

Related Links:

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...

--Benji

[jpondrom_splunk]

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
https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/app-roles

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.

[colbym]

Has anyone successfully implemented this workaround? We are not having any luck.

[jpondrom_splunk]

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.

[bpdubs]

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.

[ASierra]

This is done through Azure group filtering options in the Enterprise App for Splunk that you created.

1. Add the security groups that you want to give access to the Splunk App in users and groups
2. Go into Single-signon, click edit Attributes and Claims.
3. Click on the first claim option that was automatically created usually user.groups [SecurityGroup]
4. Change from "Security groups" to "Groups assigned to the application".

No more issues with users that have large membership groups. Not sure why I didn't find this answer anywhere else.

@bpdubs 

[jbuxton]

@ASierra  - 

We have run into the security group count issue. Currently, we map security groups via the 'SAML Groups' page, where the security group I maps to a specific role.

@jpondrom_splunk offers a solution that would require adding the app roles from Azure into the 'SAML Groups', then modify the 'SAML Configuration' 'Role Alias' to a different value. This would retool all of the SAML authentication from 'groups' to 'roles'.

Clarifying question(s) on step 1: Did you mean 'Add the Azure App Roles to the SAML Groups'? Or is it the case that having mapped Azure Security Groups to Splunk Roles via the 'SAML Groups' interface, I don't need to do anything else? 

It would be wonderful if a simple Azure change could provide the fix. I'm not averse to adding the Azure App Roles to the SAML Groups mapping, but the method you offer is much easier.

[ASierra]

In the Azure Splunk Enterprise Application, under Users and Groups, I add my Azure security groups that have the members that want access inside them. Then you go into the Single sign-on portion and review the Attributes and Claims. You should have an entry that says "groups" as the claim name. Under the value, it should be set to "Groups assigned to the application" and Source Attribute as "Group ID". This will send just the groups assigned to the application that the sign-in user is a part of instead of every single group which might go over the limit.

In the splunk side, you enter your AD group name or sometimes with other versions it has to be the object-id of the azure group and then map it to the correct internal splunk role you have created for that team.

[jbuxton]

Thanks for the clarification! I am running this by the team now...

[bpdubs]

This seems to be working so far. You are a rock star! Many thanks.