FortiAuthenticator Deployment and Configuration
What this domain tests
FortiAuthenticator Deployment and Configuration tests the practical order of setup: management access, network services, licensing, identity sources, RADIUS and certificate services, FortiGate integration, HA, and backup. Questions often hinge on dependencies, such as why NTP or DNS must be correct before testing authentication.
Initial configuration order
- Set the management IP, hostname, DNS, and NTP. DNS is needed for LDAP, SAML, OCSP, and firmware lookups. NTP is needed for OTP, certificates, SAML assertions, and consistent logs.
- Create administrative accounts with appropriate admin profiles, apply the license, and take a backup before building complex policy.
- Replace or trust certificates before production use; clients must trust the FortiAuthenticator certificate for HTTPS, SAML, or certificate services.
Identity and service configuration
- Add LDAP/AD with a working bind account, test connectivity, then import or map users and groups.
- Create FortiAuthenticator user groups that match the authorization model used by FortiGate.
- Add each FortiGate or NAS as a RADIUS client with the correct IP and shared secret.
- If using certificates, configure the built-in CA, SCEP enrollment, and CRL or OCSP as required.
- Integrate with FortiGate through RADIUS, FSSO, or SAML depending on the use case.
HA and lifecycle
FortiAuthenticator supports active-passive HA with configuration synchronization and heartbeat interfaces. Plan which interface carries HA traffic and test failover. Keep firmware consistent and verify licensing before an upgrade.
Worked example
You need FortiGate SSL VPN users to authenticate with AD password plus FortiToken through FortiAuthenticator. Configure DNS and NTP, add the LDAP server and test the bind, import the required group, create a user group, add the FortiGate as a RADIUS client, assign tokens, then configure the FortiGate RADIUS server and policy. Reasoning: the FortiGate cannot authenticate users until FortiAuthenticator can reach AD and validate tokens, and token validation depends on correct time.
Traps that cost marks
- Building RADIUS clients before DNS or NTP is correct, then chasing false authentication failures.
- Forgetting that a FortiGate must be defined as a RADIUS client by IP and secret.
- Assuming HA removes the need to license or size both nodes correctly.
- Leaving the default certificate in place and breaking trust with SAML or HTTPS clients.
- Not testing LDAP bind credentials before blaming FortiGate policy.