| Description |
This article describes the behavior of why SSL VPN users match the incorrect portal/authentication rule.
In this example, 2 local users (denice and rejean) are members of the 'SSLVPNGROUP' local user group, but there is additional access provided to the user 'denice'. The behavior is user 'denice' matches the web-access portal, but user 'rejean' matches the expected portal 'full-access' despite being a member of the same group.
Under the SSL VPN setting, the 'full-access' portal is mapped to this group. While the default (All Other Users/Groups) is mapped to 'web-access'.
By default, the 'All Other Users/Group' is authentication rule # 0, while the SSLVPNGROUP is authentication rule # 1. This can be confirmed via CLI also.
Viva-kvm41 # show vpn ssl settings
As shown below, user 'denice' is added directly to policy #4 since additional access was allocated, while the user group 'SSLVPNGROUP' is added to policy #3.
User 'rejean' tries to authenticate, it matches the 'authentication-rule' # 1 as expected because she is a member of the SSL VPN group.
But when user 'denice' tries to authenticate and connect via SSL VPN, it matches the authentication-rule #0 and gets mapped to the 'web-mode' portal even if being a member of 'SSLVPNGROUP'.
|
| Scope | FortiGate. |
| Solution |
To override this behavior, it is recommended to have matching 'users/group' on both 'firewall policies' and 'authentication-rule'.
In this case, it is either possible to create a new authentication-rule for user 'denice' specifically, or create a separate user group for the user and specify it on the new authentication rule.
Viva-kvm41 # show vpn ssl settings set banned-cipher SHA1 SHA256 SHA384 edit 1 set groups "SSLVPNGROUP" next edit 2 <----- set users "denice" set portal "full-access" next end end
|
