| Description |
This article describes the problem of logging into SSL VPN via RADIUS remote authentication despite the group matching has been configured correctly.
In the test environment, the user group has been configured with proper group matching in the RADIUS server:
In the RADIUS server, the user has been configured appropriately and the RADIUS server is configured to respond with the VSA variable for Fortinet Group Name for group matching purposes:
The configuration of the SSL VPN has been done accordingly in FortiGate. It is possible to enable the debug of remote authentication verification by issuing the following command in FortiGate CLI:
diagnose deb app fnbamd -1 diagnose deb en
In the debug log shown above, it is possible to see the RADIUS response with code 2 (Access-Accept) packet.
RADIUS server is responding the group name accordingly 'FORTINET attr, type 1, val SSL-VPN' and the authenticate result of the RADIUS request is 0, which means that the authentication via RADIUS server is successful. However, the login request ends with 'Failed group matching'.
This is because a missing Firewall policy was configured for the RADIUS group of 'SSLVPN-RAD' that was configured. Firewall policy may have been configured previously, but during upgrade or restoration of the configuration file for rollback purposes, the firewall policy may not get imported correctly. |
| Scope | FortiGate SSL VPN, RADIUS authentication. |
| Solution |
Review the firewall policy configured for SSL VPN users and ensure that the configured user group is being configured accordingly.
Once the user group is configured accordingly, the user should not fail group matching while logging into the SSL VPN service:
Note : Sometimes, even when an attribute value is configured, FortiAuthenticator does not send it. This is because the group filter needs to be enabled in the radius policy of the FortiAuthenticator; if it is not, attribute values will not be transmitted. |
