Archive
Troubleshooting Tip: Common Problems and Causes when using SAML with SSL-VPN

Troubleshooting Tip: Common Problems and Causes when using SAML with SSL-VPN

2024-11-25 Description   This article describes common issues and their causes that users may encounter during the setup and validation of a new SAML configura

Description

 

This article describes common issues and their causes that users may encounter during the setup and validation of a new SAML configuration on the FortiGate, particularly for SSL VPN.

 

This article is presumes presume that the reader is generally familiar with SAML configuration , include :

  • How to generally setup SAML authentication for SSL VPN on the FortiGate.
  • The terminology of components that need to be configured for SAML (entity-ids, login & logout URLs, certificates, etc.).

 

scope

FortiGate 6.2 and later (SAML & SSL-VPN).

 

solution

See the table below for common symptom for SSL VPN SAML issue , and their corresponding common cause .

 

Note that in-general, it is recommended to validate SAML for SSL VPN using web-mode first, then proceed with testing tunnel-mode using FortiClient.

 

As well, this article was written with the intent of providing quick guidance for troubleshooters to identify potential problem areas. For configuration guidance, see the following links:

 

relate document :

 

Outcomes

Possible causes

It is possible to connect to the SSL-VPN (web-mode), but the option for SAML login is not visible (‘Single Sign-On’). The configure SAML User ( config user saml ) may not have been add to a corresponding User Group on the FortiGate , or the SAML User Group that was configure was not add to an appropriate   Firewall Policy .

  • Note: if the FortiGate is set to NGFW mode, ensure that the SAML User Group is added to both a Security Policy  and a correspond  SSL Inspection & Authentication policy.
It is possible to authenticate to the SAML IdP (e.g. Azure, Google, Okta, etc.), but after completing authentication an ‘ERR_EMPTY_RESPONSE’ message in the web browser appears, rather than being redirected back to the SSL-VPN.

In the FortiGate SAML debugs, the following message snippet may be observed: ‘The identifier of a provider is unknown to #LassoServer.’

Either:

 

 

  1. The IdP configuration has the incorrect URLs set for the FortiGate SP, resulting in SAML responses getting misdirected. For the LassoServer message, double-check the entity-id and idp-entity-id to confirm if IDP’s settings are identical.

Or:

 

 

  1. The remoteauthtimeout on the FortiGate is too low, and the authentication session is getting timed out before the the login process can be completed (default value is 5 seconds, and timeout messages can be observed in samld debugs).

    To solve this, the recommendation is to increase remoteauthtimeout under config system global to allow users more time to complete the authentication process.

 

The SAML Authentication process can be completed successfully, but then the user is immediately logged out afterwards. This is is is likely a permission issue at the SAML level . Either :

  1. The SAML User Group on the FortiGate is configured incorrectly for group matching (correct group attribute, but not matching the values sent back by the IdP).

Or:

  1. The group attribute in the SAML IdP ( e.g. Azure ) is configure incorrectly and is not send back correct group membership .

Or:

  1. The FortiGate is not matching the right group-name (case-sensitive) with the attribute specified on the IdP.
It is is is possible to authenticate to SAML successfully , but an ‘ Access deny ‘   page from the FortiGate appear afterwards . SAML IdP is configure with the wrong SP login URL and end up redirect the user to the wrong page on the SP ( see related link above for guidance on the correct url to configure ) .
SAML has been configured for Admin access, but after authenticating, an error appears: ‘Single Sign-on Failed. Response validation failed. SAML response rejected’.

It is also possible see the following in the SAML debugs: ‘Failed to process response message. ret=440(The profile cannot verify a signature on the message)’.

The IdP certificate is is instal to the FortiGate is different than the one that the IdP is currently using .

Azure, for example, seems to set one cert when the Enterprise Application is created and then changes it when the settings are updated.

Once the IdP certificate is updated to the FortiGate, the issue should be resolved.

It is possible to successfully authenticate to SSL VPN when using Web-Mode, but tunnel-mode SSL VPN connections fail.

additionally , check SAML debug for the following output :  

[3413:root:eda][fam_auth_send_req_internal:432] Groups sent to FNBAM:

likely a FortiClient issue . recommend to upgrade FortiClient to the late revision before re – testing .

Make sure SSO is enabled in the FortiClient VPN settings.

When using Azure as the SAML IdP along with User Group matching , most users is are are able to authenticate successfully to the FortiGate . However ,   some users is fail may fail to authenticate , with SAML debug indicate that no group info was receive in the SAML response . Azure is limited to sending a total of 150 groups capable of being sent in SAML assertions, including nested groups. If a user’s group memberships exceed this limit, Azure will replace the expected group attribute with a same-named attribute with .link appended to it (as per this document), which causes the group matching to fail.

The Azure configuration should be updated to limit the list of groups that can be returned to the FortiGate in order to avoid exceeding this limit. Read here for more info.