Skip to main content
mtse
Staff
mtse
Staff
October 26, 2021

Troubleshooting Tip: SAML group mismatch issue in SSL VPN

  • October 26, 2021
  • 0 replies
  • 51860 views

Description

 

This article describes how to troubleshoot a scenario in which a user could log in initially and get logged out immediately afterward.

SAML can be used for user authentication and grouping in FortiGate.
 
In such a scenario, once a user logs in to SSL VPN, the user is immediately presented with 'Session Ended' in the browser.
 
Scope
 
FotiGate.


Solution

 

To troubleshoot the SAML login process, the following debug can be collected while the user is logging in:
 
diagnose debug console timestamp enable
diagnose debug application samld -1
diagnose debug application eap_proxy -1
diagnose debug application sslvpn -1
diagnose debug enable
 
In this scenario, the SAML log showed 'SAML group mismatch' and No group info in SAML response:
 
[09:22:41][176:root:2ab5]fsv_saml_login_response:498 Got saml username: acd@COM.COM. 
[09:22:41][176:root:2ab5]fsv_saml_login_response:536 No group info in SAML response.
[09:22:41][176:root:2ab5]sslvpn_auth_check_usrgroup:3050 forming user/group list from policy. 
[09:22:41][176:root:2ab5]sslvpn_auth_check_usrgroup:3097 got user (0) group (2:0). 
[09:22:41][176:root:2ab5]sslvpn_validate_user_group_list:1940 validating with SSL VPN authentication rules (0), realm ((null)). 
[09:22:41][176:root:2ab5]sslvpn_validate_user_group_list:2946 got user (0:0), group (2:0) peer group (0). 
[09:22:41][176:root:2ab5]sslvpn_update_user_group_list:1834 got user (0:0), group (2:0), peer group (0) after update.[09:22:
[176:root:2ab5]fsv_saml_login_response:477 No group info in SAML response.
[09:22:41][176:root:2ab5]fsv_saml_login_resp_cb:173 SAML group mismatch.
 
This indicates the group name 'group' configured was different from what was returned from the SAML IdP.
 
Configured group in FortiGate:

Attribute Name: 'group'.

Attribute Value: 'SSL-SAML'.

 
config user saml
    edit "ras.test"
        ..
        set group-name "group"                 <----- Attribute name for group-name.
 
config user group
    edit "azure_test"
        set member "ras.test"
            config match
                edit 1
                    set server-name "ras.test"
                    set group-name "SSL-SAML"     <------ Attribute value for group-name.
                next
            end
 
However, the debug log showed the Attribute Name returned was 'http://schemas.microsoft.com/groups' (instead of 'group').
 
[09:22:41]samld_send_common_reply [120]:     Attr: 10, 104, 'http://schemas.microsoft.com/groups' 'SSL-SAML'
 
The solution is to correct the attribute name in IdP from 'http://schemas.microsoft.com/groups' to 'group' (or vice versa: configure the 'group-name' in FortiGate to match the returned attribute-name  'http://schemas.microsoft.com/groups').
 
config user saml
    edit "ras.test"
..
    set group-name "http://schemas.microsoft.com/groups"
 

Another possibility is in the case that a firewall policy is configured with the wrong user group or a policy with the correct group exists, but the schedule on the policy is set to 'none' as shown below:

 

config firewall policy
    edit "vpn policy"
    .....
        set groups "saml group"<- If the group name does not match the authentication rule, this could lead to a group mismatch issue.
        set schedule "none" <- Need to change to 'always' to make sure the policy matches the SSL VPN authentication rule, even if it has the right SAML user group.
    next
end

Notes:

 

Related articles:

Technical Tip: Configure group based policies for SAML users

Technical Tip: Configuring SAML SSO login for FortiGate administrators with Azure AD acting as SAML IdP

Terms & ConditionsAccessibility statement