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 presumes that the reader is generally familiar with SAML configuration, including:
- 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 symptoms for SSL VPN SAML issues, and their corresponding common causes.
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:
Related documents:
|
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 configured SAML User (config user saml) may not have been added to a corresponding User Group on the FortiGate, or the SAML User Group that was configured was not added 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 corresponding 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:
- 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:
- 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 likely a permission issue at the SAML level. Either:
- 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:
- The group attribute in the SAML IdP (e.g. Azure) is configured incorrectly and is not sending back correct group memberships.
Or:
- The FortiGate is not matching the right group-name (case-sensitive) with the attribute specified on the IdP.
|
| It is possible to authenticate to SAML successfully, but an 'Access Denied' page from the FortiGate appears afterwards. |
SAML IdP is configured with the wrong SP login URL and ends up redirecting the user to the wrong page on the SP (see Related Links above for guidance on the correct URLs 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 installed 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 debugs for the following output:
[3413:root:eda][fam_auth_send_req_internal:432] Groups sent to FNBAM: |
Likely a FortiClient issue. Recommended to upgrade FortiClient to the latest 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 are able to authenticate successfully to the FortiGate. However, some users may fail to authenticate, with SAML debugs indicating that no group info was received 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. |
