When using group mapping, the following caveats apply regardless of which delegated authentication method is used:
membership in synchronized groups will override any membership locally configured in SonarQube at each login
membership in a group is synched only if a group with the same name exists in SonarQube
membership in the default group sonar-users remains (this is a built-in group) even if the group does not exist in the identity provider
When group mapping is configured, the delegated authentication source becomes the one and only place to manage group membership, and the user’s groups are re-fetched with each log in.
So the group you’ve assigned to the user probably doesn’t exist in the X-Forwarded-Groups header.
You’ll need to coordinate with whatever team is populating that header in the first place (likely the team responsible for AD or otherwise authorization via proxy) to see how data is making it to the X-Forwarded-Groups. This will be specific to your organization.
Presumably, if you are authenticating via proxy, the team responsible for that proxy is making sure only groups to which the user actually belongs are being put in that header when the user browses your SonarQube instance. I would really recommend coordinating with the teams in your organization managing that proxy / authentication in general.