HA Failover Leaves RADIUS and SAML Pointing at the Dead Node
A university deploys two FortiAuthenticator 6.5 VMs in active-passive HA on VMware for 6,000 users. FortiGates use RADIUS for SSL VPN and SAML for administrator SSO. The primary node holds the SCEP server and internal CA. During a planned primary shutdown, VPN users fail RADIUS and SAML users see invalid signature. The FortiGate RADIUS configuration points to 10.10.10.10, the primary node address, and the SAML SP metadata points to https://fac1.example.edu/idp/metadata. The secondary reports HA role Secondary but its configuration checksum differs from the primary. The secondary has a base license but no FortiToken Mobile licenses. The primary generated a new IdP signing certificate two days before the maintenance. The secondary can ping the FortiGate but not the old CRL URL. Both nodes run the same firmware, and HA uses a dedicated VLAN.
1. Why did the HA failover not preserve RADIUS and SAML service? Address both client targeting and certificate/license state.
Read the worked answer
Two separate failures are visible. The FortiGate RADIUS configuration points at the primary node address, not an HA virtual IP or DNS name, so after shutdown RADIUS requests have no listener. The SAML metadata also points at fac1, so SPs send assertions to the failed node. On the certificate side, the new IdP signing certificate was generated on the primary two days earlier; the secondary must have the same certificate and private key, and the SP must trust it. A configuration checksum mismatch means the secondary did not receive the latest configuration. Missing FortiToken Mobile licenses on the secondary can also break MFA after failover even if token seeds exist. Check HA status, config sync, certificate presence, and licensing before blaming the network.
2. Which HA health and synchronization checks should be completed before the next maintenance window?
Read the worked answer
Before maintenance: confirm both nodes run the same firmware and have synchronized time; verify HA role and that the configuration checksum matches; check the HA heartbeat and dedicated HA link; confirm the HA virtual IP and DNS records; verify FortiToken licenses on both nodes; confirm the IdP signing certificate and private key exist on the secondary; test SCEP and CRL reachability from the secondary; and fail over during a test window with a pilot user. Also export the primary configuration and record the certificate serials. If the checksum still differs, resolve sync before touching production; do not assume HA is protecting you.
3. Propose a target design for RADIUS and SAML endpoints that survives node failure.
Read the worked answer
Put RADIUS and SAML endpoints behind an HA virtual IP or a DNS name that resolves to the HA address, not a node address. Use the same IdP signing certificate and key on both nodes, and import the new metadata into every SP after renewal. License FortiToken on both nodes so MFA survives failover. Keep SCEP and CA services on a shared, reachable endpoint, and ensure CRL/OCSP URLs are reachable from both nodes. Test both SP-initiated and IdP-initiated SAML plus RADIUS EAP and token flows after a controlled failover. Document that node-level IPs are for management only.