| Solution | Core problem: After SAML SSO succeeds: The authentication works (access granted, policies match), but the displayed username in FortiGate's authenticated users list is the connecting FortiClient's UID. This often confuses admins monitoring sessions or applying user-based policies/logging. The following is the authentication list output for an authenticated user: diagnose firewall auth list 192.168.192.10, F5A7D248073844F9AE951871D295D29D <----- Username. type: fw, id: 0, duration: 736, idled: 736 flag(400): ha packets: in 0 out 0, bytes: in 0 out 0 group_id: 6 group_name: VPN-GROUP 192.168.192.11, F5A7D248073844F9AE951871D295D29D <----- Username. type: fw, id: 0, duration: 292, idled: 292 flag(400): ha packets: in 0 out 682, bytes: in 0 out 48654 group_id: 6 group_name: VPN-GROUP ----- 2 listed, 0 filtered ------ Cause: The FortiClient UID is used as the username for a VPN connection if FortiGate is not able to read another username from the SAML Response. Usually, this is a result of a mismatch between IdP and FortiGate configuration- the IdP (Azure Entra ID, Okta, etc.) sent the intended username in an attribute that does not match the attribute defined in FortiGate SAML configuration. config user saml edit <saml server> set user-name 'username' <----- Common FortiOS default. next end Resolution: To view the attributes sent by the IDP in FortiOS, collect a SAML debug of an authentication attempt. diagnose debug application samld -1 diagnose debug application eap_proxy -1
diagnose debug enable ... samld_send_common_reply [95]: Attr: 10, 99, 'http://schemas.microsoft.com/identity/claims/tenantid' '97b655bc-62f8-123456789'samld_send_common_reply [95]: Attr: 10, 107, 'http://schemas.microsoft.com/identity/claims/objectidentifier' 'd27853ef-f3af-4390-b29b-12345678'samld_send_common_reply [95]: Attr: 10, 80, 'http://schemas.microsoft.com/identity/claims/displayname' 'Test User'samld_send_common_reply [95]: Attr: 10, 132, 'http://schemas.microsoft.com/identity/claims/identityprovider' 'https://sts.windows.net/97b655bc-123456789/'samld_send_common_reply [95]: Attr: 10, 146, 'http://schemas.microsoft.com/claims/authnmethodsreferences' 'http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password'samld_send_common_reply [95]: Attr: 10, 142, 'http://schemas.microsoft.com/claims/authnmethodsreferences' 'http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/x509'samld_send_common_reply [95]: Attr: 10, 117, 'http://schemas.microsoft.com/claims/authnmethodsreferences' 'http://schemas.microsoft.com/claims/multipleauthn' To stop the debugging: diagnose debug disable diagnose debug reset Resolution: Configure the IdP to send the expected attribute as defined on the FortiGate, or modify the FortiGate to use the attribute shown in the SAML debug output. In the example above the FortiOS configuration change to resolve the issue would be as follows: config user saml edit <saml server> set user-name 'http://schemas.microsoft.com/identity/claims/displayname' next end Afterwards, the username is displayed correctly in the Authentication List: diagnose firewall auth list 192.168.196.11, Test User type: fw, id: 0, duration: 10, idled: 10 flag(400): ha packets: in 0 out 0, bytes: in 0 out 0 group_id: 6 group_name: VPN-GROUP Note: If SAML users are able to connect to VPN successfully but never appear in the authentication list, configure the intended user group(s) on firewall policies instead of the VPN phase1-interface. See Technical Tip: How to use multiple groups with EAP for IKEv2 (SAML/RADIUS/local). |