I’ve been trying to integrate SAML authentication between FortiGate and Azure Active Directory, but despite everything being configured correctly, I’m encountering issues logging in.
SAML settings on FortiGate are correctly configured, including Entity ID, Single Sign-On URL, Single Logout URL, and IDP Entity ID (matching the Azure AD SAML application).
The SAML assertion received from Azure AD contains the correct username and group values as per the FortiGate SAML configuration.
Reply URL and Assertion Consumer Service (ACS) URL in Azure AD are set to match FortiGate's settings.
SAML signing certificate is correctly set in both Azure and FortiGate.
When trying to log in, after authentication through Azure AD, it redirects back to the FortiGate login page instead of granting access. Everything looks correct in the SAML response, but it doesn’t seem to pass the authentication in FortiGate.
SAML assertion contains the correct values.
Groups and user attributes match the configured settings in FortiGate and Azure AD.
Has anyone experienced this issue before? Any tips or things I might have overlooked?
Hello,
Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.
Thanks,
Hey Yuttakarn,
one thing that I frequently encounter as an issue - what SP login/logout URLs did the FortiGate generate for itself?
-> depending on the firmware, the SP URLs may look like "[...]/remote/saml/?acs" and "[...]/remote/saml/?sls" instead of "[...]/remote/saml/login" and "[...]/remote/saml/logout"
-> if you see the '?sls' and '?acs' URLs, I suggest changing them to 'login' and 'logout' URLs
-> this needs to be done via CLI, under 'config user saml'
If your FortiGate is already using the "/login" and "/logout" URLs, I would suggest collecting some saml debug in CLI to see what's going on:
#dia de reset
#dia de app samld -1
#dia de console timestamp en
#dia de en
That can give you some insight into why SAML authentication is returning to the login page again instead of proceeding.
Cheers,
Debbie
I have a question,
But why is it that when I disconnected from WiFi or skip the next day when connecting, I have to log in entra id again every time? Can we set it to remember?
Hey Yuttakarn,
with SAML authentication, how long the authentication is remembered depends on two factors:
- how long the authentication cookie is valid for
- how long the browser used for SAML authentication stores the cookie
So, you would need to check in Azure how long SAML cookies are valid for; this is maybe helpful?
https://learn.microsoft.com/en-us/entra/identity-platform/configurable-token-lifetimes#token-lifetim...
If the browser used for SAML authentication clears cookies automatically when closing down, then (as the cookie is deleted), new authentication will always be required.
If you're using FortiClient and NOT launching an external browser, then I think FortiClient stores the cookie for a day? But I'm really not certain on that point, apologies.
Cheers,
Debbie
This is related to Security > Conditional Access > Persistent browser session or Sign-in frequency. or not on entra id
User | Count |
---|---|
2551 | |
1356 | |
795 | |
646 | |
455 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.