Sophos XG does not recognize user group returned by NPS RADIUS server

In v20MR1 we have fixed one Radius group membership issue listed below: 

Prior to this fix: In scenario where user is part of  multiple groups and all groups are available in SFOS too. User group will be mapped to “Group and Other group memberships”.

Now in case all the groups are removed from this user on Radius, in this case user’s “Group” value use to retain and hence user was able to access resources as per last group policy.

Fix in v20MR1 is to resolve this issue:

• Radius server should respond with a list of Groups via any defined attribute e.g. Filter-ID.
• SFOS Radius server should have the same attribute set for “Group name attribute”.
• Group should pre-exists in firewall to map user correctly in those groups.
• In case group is not available in firewall user will fall in default group configured.

Please take a look at authentication server log if correct group value is returning from Radius server against attribute configured in SFOS server for “Group name attribute”.

We are investigating few customer deployments, who have reported issue to support post migration. We will post update in case we found any new issue during the investigation.

Suggestion is to reach out to support in case you are encountering issue post migration despite group attribute is provided by Radius server under configured value and same group exists in SFOS groups list.  

 -Alok

Thank you Alok! Meanwhile I have found a solution! Maybe the group membership with RADIUS does not work with the Filter-Id Attribute, but with with the Class Attribute my XG is able to put the users into my user group that I created! Would be nice if you could test this and maybe put it in your official docs.

Thanks Marcel for the update.

Ideally, it should work with any attribute which is configured on Firewall and sent by Radius with appropriate value. 

If same values are sent via Filter-ID or Class or any Other. I don't see a reason it should not work.

As from firewall PoV, it will retrieve the response from defined attribute under "Group name attribute" on SFOS and try to map with existing locally available group info.

-Alok

Cant explain this behavior. I know what you mean, when the GID is Filter-Id, it is Filter-Id. I dont know it only works with Class.

If it's possible we can arrange remote session to have a look at your setup with Fiter-ID and Class. 

I have DM you.

Very strange behavior:

I have just tested Marcel's suggestion to verify it.

Attempt 1: Original setting (“Filter-Id” on XG/NPS) => user ends up in the “Open Group”

Attempt 2: Attributes changed to “Class” on XG/NPS => user ends up in the correct group “SG-VPN-SOPHOS”

Attempt 3: I reset again to verify that the error occurs again (“Filter-Id” on XG/NPS) => user ALSO ends up in the correct group “SG-VPN-SOPHOS”

What the hell? :-D

I couldn't believe it and have just tested the scenario again on a second firewall (Sophos XGS) with the same result: as soon as you have used a different RADIUS attribute once and then switch back to Filter-Id, it works.

I also moved the user to a different group and connected it via NPS to rule out the possibility that Sophos is caching groups - this also works without any problems ...

Strange... Alok  Yes we can check it next week, but I didnt receive any DM from you.

By any chance you have debug logs of access server during the test, that should suffice to conclude on the problem. 

I will send DM to discuss this further. 

You should have it now.

We investigated the problem and now everything is working fine for the Filter-Id and the Class Attribute like in Christians case. We couldnt explain this behavior. As workaround, try to use the "Class" Attribute directly.