| Description | This article describes a solution for cases where an Azure user is redirected to the Microsoft portal and authenticates successfully, but is denied access afterwards by FortiGate. |
| Scope | All supported versions of FortiGate, SAML authentication, captive portal, SSL VPN, dial-up IPsec. |
| Solution |
This behavior occurs because there is no match between SSO group assertions settings on FortiGate and the assertions that arrive from Azure. A very common cause of this is when a user belongs in more than 150 groups on Azure (including nested groups).
If this happens, Azure substitutes the group attribute (usually 'http://schemas.microsoft.com/claims/groups' or just 'groups') with a 'group.link' attribute (see the documentation), which contains a link to https://graph.windows.net/<identityProviderID>/users/<UserObjectID>/getMemberObjects instead of a group ID as its value.
To resolve this, edit the Attributes and Claims which are on Single Sign-On at Azure, and change 'Security groups' to 'Groups assigned to the application'. |
