FCP FortiNAC-F Administrator common mistakes
FCP FortiNAC-F Administrator · Understand the traps and how to avoid them.
Treating FortiNAC-F as if it were the legacy FortiNAC virtual appliance and looking for the same menu paths, service names, and CLI syntax during deployment and initial setup questions.
Most study material circulates around the older CentOS-based FortiNAC product line, so candidates memorize outdated navigation and initialization steps and then misapply them to FortiNAC-F, which runs on a FortiOS-based foundation with a different configuration and management model.
What to do instead
Study the FortiNAC-F administration guide and the appliance's own GUI/CLI structure directly. Practice the initial configuration flow on a lab instance: management IP, DNS/NTP, licensing, and the FortiNAC-F-specific configuration objects. When a question asks about a menu or CLI command, verify it against FortiNAC-F documentation rather than memory of the legacy product.
Configuring SNMP on the switch but forgetting to also enable the required CLI access (SSH/telnet credentials or read-write account) that FortiNAC-F needs for enforcement and for reading information SNMP does not expose.
Candidates assume SNMP read access alone is sufficient for full device modeling, but FortiNAC-F uses SNMP primarily for topology and status polling while CLI is used for many read and write operations such as VLAN changes and port state. The device may appear 'up' in the model but enforcement silently fails.
What to do instead
For each managed device, verify both SNMP (correct community/version, allowed source, view) and CLI credentials with the correct privilege level. Test connectivity from FortiNAC-F itself, confirm the device model shows as successfully modeled, and validate that a test VLAN change actually applies on the switch port before relying on the integration.
Assuming endpoints will be profiled and registered automatically without checking that the required detection methods (DHCP fingerprinting, SNMP-based MAC/ARP learning, RADIUS accounting, or agent-based methods) are actually receiving data.
Profiling depends on multiple passive and active data sources. If DHCP relay/helper is not pointing at FortiNAC-F, or RADIUS accounting is not configured on the NAD, endpoints stay 'unknown' and policy matching fails. Candidates often blame the profiling rules when the data feed is missing.
What to do instead
Map each detection method to its prerequisite: DHCP helper/relay to FortiNAC-F, SNMP read access for MAC/ARP tables, RADIUS accounting enabled on the authenticator, and any agent deployment. Verify in the endpoint's detail view which sources have reported, then troubleshoot the missing feed before editing profiling rules.
Mixing up 802.1X and MAB behavior in policy design, such as expecting MAB to perform user authentication or expecting 802.1X to work on devices that cannot supply supplicant credentials.
Both methods feed the same policy engine, so candidates conflate them. MAB authenticates the device's MAC address only, while 802.1X authenticates a supplicant identity (user or machine certificate). Questions often hinge on which method applies to printers, cameras, or IoT devices versus managed laptops.
What to do instead
Learn the decision tree: devices with supplicants use 802.1X (EAP methods, certificates or credentials); devices without supplicants use MAB with MAC-based identity. Understand how FortiNAC-F orders authentication methods on a port and how fallback from 802.1X to MAB is configured on the NAD. Practice writing policies that explicitly match the identity type each method produces.
Writing access policies that reference the wrong policy layer or evaluation order, so a device lands in the wrong VLAN even though the intended rule exists.
FortiNAC-F evaluates policies in a defined hierarchy and order (for example, network access policies versus other policy types, and rule order within a policy). Candidates build a correct-looking rule but place it after a broader catch-all, or attach it to the wrong policy object, so the catch-all wins.
What to do instead
Study the policy evaluation order and precedence for the FortiNAC-F version you are testing. Design rules from most specific to most general, place default/guest catch-alls last, and use the policy test/preview or logs to confirm which rule matched. Verify the resulting VLAN is actually applied on the switch port, not just that the rule exists.
Configuring guest self-registration but skipping the pieces that make it usable end to end, such as the guest portal reachability, sponsor approval workflow, or the enforcement action that moves the guest into the correct VLAN after registration.
Guest onboarding spans multiple subsystems: captive portal/DNS, registration and sponsorship settings, and the access policy that grants network access after registration. Candidates configure the portal and assume access is granted, but the post-registration policy or VLAN assignment is missing.
What to do instead
Walk the full guest flow in a lab: unauthenticated device hits the portal, registers or is sponsored, FortiNAC-F updates the endpoint record, the access policy re-evaluates, and the port moves to the guest VLAN. Confirm each step in logs. For BYOD, also verify onboarding method (agent, certificate, or portal) matches the device type.
Assuming high availability is active-active or that failover preserves all state automatically, without verifying which components are replicated and what manual steps remain after a failover.
Candidates generalize from other products. FortiNAC-F HA has specific primary/secondary roles and replication behavior, and some configuration or integration state may need verification after failover. Backup/restore procedures are also distinct from HA and are often confused with it.
What to do instead
Study the FortiNAC-F HA documentation for the exact role model, heartbeat/synchronization requirements, and failover behavior. In a lab, force a failover and confirm device models, policies, and endpoint data survive. Separately practice configuration backup and restore, and know which maintenance tasks are HA-safe versus disruptive.
Troubleshooting enforcement failures by reading only the FortiNAC-F event log while ignoring the NAD-side logs and the RADIUS exchange, leading to misdiagnosis of the root cause.
Enforcement failures can originate on the switch (VLAN not defined, port in wrong mode, CoA rejected), in the RADIUS conversation (shared secret mismatch, attribute mismatch), or in FortiNAC-F policy evaluation. Candidates stop at the first log they find.
What to do instead
Adopt a layered troubleshooting method: confirm the policy matched in FortiNAC-F, inspect the RADIUS request/response and CoA exchange, then check the switch's own authentication and port logs. Use packet capture or debug on the NAD when needed. Correlate timestamps across all three sources before concluding.
Memorizing that a specific VLAN or role is 'always' assigned to guests or unknown devices instead of deriving the assignment from the configured policy and the endpoint's actual state.
Default behaviors vary by configuration and version. Candidates learn a single example topology and apply its VLAN numbers and roles to every scenario question, even when the question describes a different policy set.
What to do instead
For enforcement questions, read the scenario's stated policy and endpoint state, then reason about which rule matches and what action it produces. Learn the concepts (isolation VLAN, registration VLAN, guest VLAN, corporate VLAN as policy outcomes) rather than fixed numbers, and confirm defaults against FortiNAC-F documentation.
Skipping verification that licensing, NTP/time sync, and DNS are correct before troubleshooting higher-level features, so time-skewed logs and failed lookups masquerade as policy or authentication bugs.
Initial configuration steps feel trivial, so candidates rush them. Clock skew breaks certificate validation and log correlation, DNS failures break portal and directory lookups, and licensing limits features. These faults surface later as confusing symptoms in other domains.
What to do instead
Build a pre-flight checklist for any lab or exam scenario: license status valid, NTP synchronized and consistent with NADs and directory servers, DNS resolving internal and external names, and management connectivity verified. When a symptom appears unrelated to configuration, re-check these foundations first.