Description
This article describes the reason for a group mismatch issue that may occur in FortiGate even if a correct group claim is correctly configured in the Enterprise Application in Microsoft Azure, and a successful sign-in is performed in Azure.
Scope
FortiGate v6.2.3 and above, SAML Authentication.
Solution
SAML authentication is widely used in several FortiGate features such as firewall policies, proxy policies, captive portals, and others. Most of those features can leverage group attributes to perform more granular access control based on the user's group membership.
In certain scenarios, a subset of users may experience issues authenticating while other users sharing the exact same configuration successfully authenticate. That may occur if a specific group match is configured in the firewall group object in FortiGate.
In the example below, the user 'level3@robertao.me' is a member of Azure AD group Level3-Group with group ID d4829628-fd49-4e6b-8d9d-85ef5d180447.
User 'level2@robertao.me' is a member of Azure AD group Level2-Group with group ID f9c9aab9-cdf5-4fc1-9479-89c7243b9eea.
FortiGate firewall group objects are configured to match specific group IDs.
Both groups are assigned to the Enterprise Application in Microsoft Azure.
Username and Group claims are configured correctly.
However, only user Level2@robertao.me is able to authenticate because user Level2@robertao.me is failing to match a group in FortiGate.
The example shown is for SSL VPN access, but the same concept is valid for other SAML-enabled features with groups associated with them.
From FortiGate debugs for SAML daemon (samld), it is possible to see the assertions included in the SAML response.
Note.
To enable debugs for the SAML daemon, run the commands below:
diagnose debug application samld -1
diagnose debug enable
User Level2@robertao.me can successfully authenticate and the SAML attributes are seen in the debug logs below.
User Level3@robertao.me successfully authenticates to Microsoft Azure.
However, it fails to match the group Azure-AD-Level3-Group in FortiGate.
FortiGate may be expecting the group attribute name 'group' with Azure group ID in its value, but the group attribute is sent by Azure in an unsupported format.
A link to the Microsoft Graph endpoint to obtain group information is included instead.
The reason the group attribute is sent as a link is that the user is a member of more than 150 groups, which exceeds the number of SAML assertions Azure can send in one token. The most common cause is the use of nested groups, but users may be legitimate members of more than 150 groups.
There are a few alternative solutions performed in the Microsoft Azure configuration.
Full details from Microsoft documentation are below:
Configure group claims for applications by using Azure Active Directory.
Method 1: If the user is believed to not be a member of this large number of groups, check its group membership and correct it.
Method 2: Filter the group membership returned in the SAML assertions to only 'Security Groups'.
Method 3: Filter the group membership returned in the SAML assertions to only 'Groups assigned to the application'.
Note.
If using Microsoft Azure free tier, since there is no option to assign a group directly to the Enterprise Application, no group id will be sent if this option is selected.
Related documents:
Troubleshooting Tip: Common problems and causes when using SAML with SSL VPN.
Troubleshooting Tip: Companion for troubleshooting SSL VPN with SAML Authentication.
Technical Tip: FortiGate SAML authentication resource list.
Configure group claims for applications by using Azure Active Directory.
