|
Overview.
In environments using SAML authentication integrated between FortiGate and Microsoft Entra ID (Azure AD), the correct alignment of SAML attributes is critical for the firewall to properly identify users and groups.
When the attributes configured on the FortiGate do not exactly match the attributes sent by Microsoft Entra ID, authenticated traffic fails to match identity-based firewall policies, resulting in the application of the implicit deny policy (Policy ID 0).
Environmental architecture.
The authentication and authorization flow works as follows:
-
The user authenticates against Microsoft Entra ID.
-
Entra ID sends a SAML assertion to the FortiGate.
-
The FortiGate:
-
Validates the authentication.
-
Extracts the SAML attributes.
-
Maps the user to the received groups.
-
Traffic is evaluated against group-based firewall policies.
Any inconsistency in the attributes breaks this flow at step 3.
Critical configuration on FortiGate.
On the FortiGate, under User & Authentication -> Single sign-on, the attributes expected from the IdP are defined:
These names are not symbolic: they must exist exactly as defined in the SAML assertion sent by Microsoft Entra ID.
Corresponding configuration in Microsoft Entra ID.
In Microsoft Entra ID -> Enterprise Applications -> Single sign-on -> SAML -> Attributes & Claims, claims must be configured to match the FortiGate expectations, for example:
| Claim Name |
Value |
| username |
user.userprincipalname |
| group |
user.groups |
Important notes:
-
The claim name (username, group) is what FortiGate validates.
-
The value defines which user attribute is sent in the SAML assertion.
Common issue:
Symptoms:
-
User successfully authenticates via SAML.
-
FortiGate logs show successful authentication.
-
Traffic does not match any group-based policy.
-
Traffic is blocked by Policy ID 0 (implicit deny).
Root cause:
The attributes configured on the FortiGate do not match those sent by Microsoft Entra ID, for example:
-
FortiGate expects: group.
-
Entra ID sends: groups, roles, or a different namespace.
-
Or the claim exists but does not contain the expected groups.
As a result:
-
FortiGate cannot map the user to any group.
-
The user is authenticated but has no group association.
-
No identity-based firewall policy is matched.
Firewall impact.
When no group match occurs:
-
Group-based firewall policies are not applied.
-
Traffic does not inherit expected permissions.
-
FortiGate applies the implicit deny policy (ID 0).
This behavior occurs even when authentication is successful, which often confuses troubleshooting.
Recommended best practices.
-
Standardize attribute names: The claim name in Entra ID must exactly match the attribute configured on the FortiGate.
-
Validate the SAML assertion:
-
Avoid redundant or unnecessary attributes: Keep only the claims required for authentication and authorization.
-
Use temporary test policies: Create a test policy to confirm group recognition.
-
Enable authentication logging: Helps identify authenticated users without group mapping.
Conclusion.
In FortiGate environments integrated with Microsoft Entra ID via SAML, authentication does not equal authorization.
If SAML attributes, especially the group attribute, are not perfectly aligned between Microsoft Entra ID and the FortiGate:
-
The firewall cannot associate users with groups.
-
Identity-based firewall policies are not applied.
-
Traffic is blocked by the implicit deny policy (Policy ID 0).
Ensuring attribute consistency is essential for proper identity-based policy enforcement.
|
