FCP FortiAuthenticator 6.5 common mistakes
FCP FortiAuthenticator 6.5 · Understand the traps and how to avoid them.
Treating FortiAuthenticator as an LDAP server that stores user passwords, and configuring local users for directory-integrated authentication instead of pointing to the existing AD/LDAP backend.
FortiAuthenticator is primarily an identity broker and RADIUS/SSO front end; candidates who come from a directory background assume it is a replacement directory and misread questions about where credentials are validated. Exam items frequently contrast local users, remote LDAP/AD users, and RADIUS users.
What to do instead
Memorise the user categories: local users (stored in FortiAuthenticator), remote users (authenticated against an LDAP/AD or RADIUS backend), and the role of the LDAP/AD configuration object with its server, bind, and user-search settings. For each scenario, decide first whether credentials are validated locally or remotely, then choose the feature.
Confusing authentication with authorization when answering questions about FortiGate integration, so that group membership lookups are described as authentication and password checks are described as authorization.
The two terms are used loosely in day-to-day work, and FortiAuthenticator blurs them because a single RADIUS reply can carry both the accept/reject decision and the group attributes used for firewall policy. Candidates therefore misclassify the purpose of a feature.
What to do instead
Anchor on the definitions: authentication proves who the user is (credential validation, OTP, certificate), authorization determines what they may do (group membership, FortiGate policy matching, role assignment). Read each question for the decision being made and map it to the correct half.
Configuring a FortiGate as a RADIUS client against FortiAuthenticator without matching the shared secret, source IP, and authentication port, then assuming FortiAuthenticator is broken when authentication fails.
The RADIUS client entry on FortiAuthenticator must match the FortiGate's source address and shared secret, and candidates often add the client with a management IP while the FortiGate sources traffic from a different interface. Port mismatches (1645/1812) compound the problem.
What to do instead
Verify the RADIUS client entry's IP matches the FortiGate interface that originates the request, confirm the shared secret is identical on both sides, and confirm the port. Use FortiAuthenticator's RADIUS debug/log view to see whether the request arrives at all before changing authentication policy.
Deploying two-factor authentication without correctly ordering the primary and secondary factors, or enabling OTP for users who have not yet delivered a token, and then expecting a first-login success.
FortiAuthenticator separates the initial credential check from the OTP check, and token delivery (SMS, email, FortiToken push) requires prior user contact data and provisioning. Candidates skip the provisioning state and misread failure questions.
What to do instead
Know the sequence: primary authentication (password, certificate, or directory) succeeds, then the OTP or push challenge is issued. Confirm the user has an assigned, activated token and a valid delivery method (mobile number, email) before testing. In troubleshooting questions, check token assignment state before blaming the RADIUS link.
Building a portal-based guest or self-registration flow without enabling the correct portal policy, sponsor approval, or realm, so users land on a portal that authenticates against the wrong user store.
FortiAuthenticator portals bind together a user database, authentication policy, and sometimes sponsorship and realm selection. Candidates configure the portal page but forget the policy that decides which users may authenticate and how, leading to loops or rejections.
What to do instead
For each portal scenario, list the four moving parts: which user database the portal authenticates against, which authentication policy applies, whether sponsorship or self-registration approval is required, and which realm the request resolves to. Test with a user from the intended store and confirm the log shows the expected policy match.
Assuming FortiAuthenticator can act as a full SAML identity provider or relying party in any direction and any combination, and misassigning the IdP/SP roles in a federation question.
FortiAuthenticator supports SAML in specific roles (for example acting as an IdP for service providers and integrating with external IdPs for admin or portal SSO), and candidates generalise from one deployment they have seen. Role confusion produces answers with the wrong metadata direction and wrong assertion consumer URL.
What to do instead
For every SAML question, write down who initiates the login, who issues the assertion, and where the assertion consumer service URL lives. Verify the supported role in the FortiAuthenticator documentation for that release before answering, and treat unsupported role combinations as distractors.
Mixing up RADIUS-based administrative SSO to FortiGate with SAML-based SSO, and choosing the wrong protocol when a question asks how FortiAuthenticator provides single sign-on for administrators.
Both paths exist and both appear in real deployments; the exam tests whether the candidate can select the mechanism that matches the described requirement (for example, no portal interaction versus browser-based federation). Candidates answer from habit rather than from the stated constraint.
What to do instead
Build a comparison table in your notes: mechanism, what the user experiences, what the FortiGate needs configured, and what FortiAuthenticator must hold (RADIUS client, SAML IdP/SP config, group mappings). Answer by matching the question's stated constraint to the mechanism, not by picking the one you deployed last.
Reading FortiAuthenticator logs only at the top level and concluding 'authentication failed' without drilling into the specific authentication, RADIUS, or SSO log entry that names the rejecting policy or the failing backend.
FortiAuthenticator records events across several log categories, and the summary view hides the decisive detail such as which policy matched, which LDAP server timed out, or which token was invalid. Candidates stop at the first error line.
What to do instead
Practise navigating the log and monitor views by category: authentication logs for user-level results, RADIUS logs for request/reply detail, and system/event logs for configuration and backend errors. In troubleshooting scenarios, state which log category you would open first and what specific field you would inspect.
Ignoring HA and backup considerations when answering deployment questions, such as describing a single-node design for a requirement that explicitly demands resilience or a tested restore path.
Candidates focus on the authentication feature being asked about and treat the surrounding deployment as scenery, missing that the question's constraint (uptime, maintenance window, disaster recovery) changes the correct answer.
What to do instead
Scan each deployment question for resilience and recovery keywords before choosing. If present, address FortiAuthenticator HA configuration and the backup/restore of configuration, and note that a backup is only useful if restoration has been validated.
Answering certificate and PKI questions by treating client certificates as a replacement for all other authentication, rather than as one factor that must be mapped to a user and validated against a trusted CA.
Certificate-based authentication in FortiAuthenticator depends on the CA being trusted, the certificate being mapped to a user identity, and the relevant policy allowing certificate authentication. Candidates skip the mapping step and expect a certificate alone to identify a user.
What to do instead
For certificate scenarios, verify three things in order: the issuing CA is trusted by FortiAuthenticator, the certificate maps to the intended user (by subject or configured mapping), and the authentication policy permits certificate authentication for that realm or portal. State this chain explicitly in your answer.