| Description | This article explains how FortiAuthenticator forwards the SAML username to Azure Entra ID when operating as an IdP proxy. It also highlights a common issue that may be encountered, and what to consider when configuring the remote SAML server settings on FortiAuthenticator. |
| Scope | FortiAuthenticator after v6.5.0. |
| Solution |
FortiAuthenticator can be configured as an IdP proxy for FortiGate, forwarding SAML authentication requests from clients to Azure. After receiving the SAML attributes from Azure, FortiAuthenticator relays them back to the client for authentication and group matching.
This setup can be used for FortiGate SSL VPN, IPsec VPN, or any other connection where FortiGate acts as the SAML Service Provider (SP).
For detailed configuration steps, refer to the following guide: FortiGate-ssl-vpn-with-FortiAuthenticator-as-the-idp-proxy-for-azure
Example: FortiGate SSL VPN authentication via FortiAuthenticator IDP proxy.
When a user initiates an SSL VPN connection from FortiClient to FortiGate, the FortiGate redirects the client to the FortiAuthenticator SAML login page, where the username and password must be entered.
The SAML username received from Azure Entra ID typically follows the format username@domain.com (for example, testuser@fortinet.com). After the user clicks Login, FortiAuthenticator looks for the login_hint value in the username, which is required by Microsoft Azure.
To verify this process, debug logs can be checked under Log Categories → Others → GUI on the FortiAuthenticator debug page (https://<FortiAuthenticator_IP>:<port_number>/debug).
Sample Debug Log:
2025-09-12T13:38:28.303976+10:00 FortiAuthenticator gui[8408] debug fac.home.www-data.FastAPI.apps.saml.views.samlidp __init__ 140480964953920 SamlIdpLoginView.dispatch: GET client_ip 192.168.92.19 sp_prefix 9kryhzkyv3g2tl9w sessionid z7553u7883fs99tdunjdcvvy22fq8s8c iam False ({})
2025-09-12T13:38:28.304658+10:00 FortiAuthenticator gui[8408] debug fac.home.www-data.FastAPI.apps.saml.views.samlidp __init__ 140480964953920 SamlIdpLoginView.dispatch - login hint was not found - using "username" query parameter None
2025-09-12T13:39:19.476063+10:00 FortiAuthenticator gui[8407] debug fac.home.www-data.FastAPI.apps.saml.views.samlidp __init__ 140480964953920 SamlIdpLoginView.dispatch - reading login hint from URL query parameters - username: testuser@fortinet.com
In this scenario, FortiAuthenticator identifies the username as ‘testuser’ and the realm as ‘fortinet.com’. By default, FortiAuthenticator sends only the short username (testuser) to Azure as the login_hint, without appending the realm. As a result, the Microsoft login page receives ‘testuser’ instead of testuser@fortinet.com. Example is shown as below:
Sample Debug Log:
Microsoft login services expect usernames in User Principal Name (UPN) format (username@domain.com). If only a short username is provided (e.g., testuser), Azure attempts to append a domain suffix automatically. This is typically the tenant’s default domain (for example, @tenantname.onmicrosoft.com or the first verified custom domain). When an unexpected postfix is applied (e.g., testuser@something.onmicrosoft.com), Azure authentication fails, which in turn causes authentication failure on the FortiGate side.
To prevent this issue, it is suggested to disable the option ‘Strip realm from username before sending’ (enabled by default) under: Authentication → Remote Auth. Servers → SAML → IdP Metadata.
When the option ‘Strip realm from username before sending’ is disabled, FortiAuthenticator sends the full UPN (e.g., testuser@fortinet.com) to Azure as the login_hint. This ensures a successful login on the Azure side.
Sample debug log:
It is also worth noting that the Realm configured in FortiAuthenticator for remote SAML authentication must match the realm in the SAML username. In this case, the realm should be ‘fortinet.com’.
This is because FortiAuthenticator will check whether the realm in the entered username matches a configured realm. If no match is found, it falls back to the default realm (local realm configuration) and generates the login_hint accordingly.
2025-09-24T21:24:36.391098+10:00 FortiAuthenticator gui[8408] debug fac.home.www-data.FastAPI.apps.saml.views.samlidp __init__ 140480964953920 SamlIdpLoginView.dispatch - reading login hint from URL query parameters - username: testuser@fortinet.com
This is because FortiAuthenticator will check whether the realm in the entered username matches a configured realm. If no match is found, it falls back to the default realm (local realm configuration) and generates the login_hint accordingly. For example, if the Realm in the FortiAuthenticator above is configured as ‘fortinet-test.com’ instead of ‘fortinet.com’, the following error will be observed in the debug log:
2025-09-24T21:24:36.391098+10:00 FortiAuthenticator gui[8408] debug fac.home.www-data.FastAPI.apps.saml.views.samlidp __init__ 140480964953920 SamlIdpLoginView.dispatch - reading login hint from URL query parameters - username: testuser@fortinet.com
In this case, the login_hint is sent as testuser@fortinet-test.com instead of the correct testuser@fortinet.com, causing authentication to fail.
Related documents: FortiGate-ssl-vpn-with-FortiAuthenticator-as-the-idp-proxy-for-azureNew Feature in FortiAuthenticator 6.5.0 |
