FCP FortiNAC-F Administrator study materials
FCP FortiNAC-F Administrator study resources

FCP FortiNAC-F Administrator cheat sheet

FCP FortiNAC-F Administrator · Keep the key ideas within reach.

Quick reference

FortiNAC-F Deployment and Initial Configuration

  • FortiNAC-F is the FortiOS-based virtual appliance (VMware ESXi, KVM, Hyper-V, and cloud images); configuration is done through the administration UI on port 443 and the CLI, not through FortiGate-style config files.

  • Minimum production sizing baseline: 4 vCPU, 8 GB RAM, 100 GB disk for small deployments; add vCPU/RAM for larger endpoint counts and separate disks or datastores for the persistent database volume where supported.

  • A FortiNAC-F appliance requires at least two network interfaces in most designs: one for management/administration and one (or more) for the isolation or enforcement network connected to the Layer 2/Layer 3 edge devices.

  • Initial access uses the default management IP and the admin account created during the deployment wizard; the CLI account and the UI admin account are separate credentials and both should be changed immediately after first login.

  • Licensing is applied from the UI (System Settings > License Management) using a license file tied to the appliance; registration with FortiCare enables FortiGuard updates and support entitlement.

  • The appliance must be able to reach FortiGuard or the configured update server for OS fingerprint and profiling updates; without updates, profiling accuracy degrades because new device signatures are missing.

  • Time synchronization via NTP is mandatory before adding network devices: certificate validation, RADIUS accounting timestamps, and log correlation all depend on accurate system time.

  • The persistent database should be backed up immediately after initial configuration and after each major change; FortiNAC-F stores configuration and endpoint history in a database that is not part of the OS image.

Quick reference

Network Device Integration and SNMP/CLI Modeling

  • A network device is added under Network > Inventory with vendor/model selection, IP address, SNMP credentials, and CLI credentials; the model determines which read/write capabilities FortiNAC can use.

  • SNMP read (v2c or v3) is used for topology, MAC address table, and interface state polling; SNMP write is optional and is used for some enforcement actions such as interface shutdown.

  • CLI access (SSH or Telnet) is required for enforcement actions that SNMP cannot perform, such as applying VLAN changes on many switch models; the CLI credential must have privilege level sufficient to enter configuration mode.

  • The 'Validate' or 'Test' function on the device record confirms SNMP reachability and credential correctness before the device is trusted; a device that fails validation will not be polled for endpoint data.

  • Device modeling maps the vendor's MIB objects and CLI command syntax to FortiNAC's internal read/write operations; an unsupported model can still be added using a generic model but may lack VLAN-change enforcement.

  • FortiNAC discovers the Layer 2 topology by reading bridge MIB and forwarding tables, so switches must be reachable on the management network and SNMP must be permitted by any intermediate ACL or firewall.

  • RADIUS and SNMP must be allowed from the FortiNAC appliance to the network devices; CoA (RFC 5176) traffic on UDP 3799 must be permitted in both directions for dynamic authorization to work.

  • When a device is added, FortiNAC reads its interface list and MAC table; interfaces can be marked as 'enforcement' or excluded so that uplinks, server ports, and trunk ports are not accidentally isolated.

Quick reference

Endpoint Detection, Profiling, and Device Registration

  • Endpoint detection uses multiple sources: MAC address table from switches, DHCP fingerprinting, RADIUS attributes, and active scanning; combining sources improves profiling confidence.

  • Profiling classifies endpoints by operating system and device type using DHCP option fingerprints, MAC OUI vendor lookup, and optionally NetBIOS/HTTP user-agent data; a device can match multiple profiles and the highest-confidence match wins.

  • The MAC OUI identifies the hardware vendor only; it does not identify the operating system, so OUI alone is a weak profiling signal and should not be used for access decisions.

  • A 'host' record in FortiNAC represents a discovered endpoint; its state moves through unregistered/unknown, registered, and (optionally) at-risk or quarantined states.

  • Device registration binds a host record to a user or to a persistent identity; registration can be done by an administrator, by the end user through a captive portal, or automatically by a policy.

  • Profiling updates are delivered as FortiGuard packages; without current packages, new device models and OS versions are classified as 'unknown' and may fall into a default deny or default allow policy.

  • DHCP fingerprinting requires FortiNAC to see DHCP traffic, either by being the DHCP server, a DHCP relay target, or by receiving mirrored/forwarded DHCP packets from the network.

  • A host that has not been seen for the configured aging period is purged from the active host table; long aging periods increase database size, short periods cause endpoints to be re-profiled and re-evaluated on every return.

Quick reference

Authentication, Identity Sources, and 802.1X/MAB

  • 802.1X uses EAP over LAN; the supplicant authenticates to FortiNAC acting as the RADIUS server, and the switch acts as the authenticator, relaying EAP between supplicant and FortiNAC.

  • MAB (MAC Authentication Bypass) sends the endpoint's MAC address as both username and password in a RADIUS Access-Request; it is used for devices without an 802.1X supplicant such as printers and IP phones.

  • MAB is weaker than 802.1X because the MAC address can be spoofed; MAB-authenticated hosts should be placed in a restricted VLAN or subjected to additional profiling before being trusted.

  • FortiNAC supports LDAP/Active Directory, RADIUS proxy, and local user databases as identity sources; the source is configured under Authentication and then referenced in policies and portal settings.

  • For LDAP/AD, the bind account must have read access to the user objects; group membership is used for role assignment, so nested group handling must be verified against the directory structure.

  • EAP methods supported include PEAP-MSCHAPv2 and EAP-TLS; EAP-TLS requires client certificates and is the stronger option, while PEAP-MSCHAPv2 relies on the user's directory password.

  • RADIUS shared secrets must match exactly between FortiNAC and each authenticator (switch or wireless controller); a mismatch causes Access-Requests to be silently dropped and the port to fail authorization.

  • The order of authentication methods matters: if MAB is attempted before 802.1X, devices that support 802.1X may be authenticated by MAC before the supplicant responds; configure the switch to try 802.1X first, then MAB as fallback.

Quick reference

Network Access Policies, VLAN Assignment, and Enforcement

  • A policy is evaluated top-down; the first matching policy wins, so specific rules (known device, compliant host) must be placed above broad catch-all rules.

  • Policy conditions can reference user/group, host profile, device type, location/network device, and time; conditions are ANDed within a policy and ORed across policies.

  • VLAN assignment is delivered to the switch through RADIUS attributes: Tunnel-Type (VLAN), Tunnel-Medium-Type (IEEE-802), and Tunnel-Private-Group-ID (the VLAN ID or name).

  • The switch must be configured to accept the VLAN from RADIUS (for example, 'authentication dynamic-vlan' or the vendor equivalent); otherwise the port stays in its default VLAN regardless of the policy.

  • Enforcement actions include VLAN change, ACL application, port shutdown, and CoA (Change of Authorization) to re-evaluate a session; CoA is sent to UDP 3799 and requires the switch to support RFC 5176.

  • A failed policy match falls to the default/fallback policy; if no fallback is defined, the endpoint may be left in the default VLAN or denied, depending on the authenticator's behavior.

  • Role-based access can be combined with VLAN assignment: the policy assigns a role that maps to a VLAN, which keeps policy logic separate from network topology details.

  • Testing a policy change requires re-authentication of the endpoint or a CoA; without a CoA, the existing session retains its previously assigned VLAN until the next authentication.

Quick reference

Guest and Bring-Your-Own-Device (BYOD) Onboarding

  • Guest self-registration uses a captive portal hosted by FortiNAC; the guest supplies an email or phone number, receives credentials or a sponsor approval, and is placed in the guest VLAN by policy.

  • Sponsor approval workflows route the guest request to a sponsor (an admin or a designated user) who approves or denies access; approval can be time-limited.

  • Guest accounts have an expiration; when the account expires, the host is re-evaluated and moved out of the guest role at the next authentication or CoA.

  • BYOD onboarding typically requires the user to authenticate with directory credentials, then enroll the device (install a certificate or agent) before the device is registered and permitted on the corporate VLAN.

  • Device registration in BYOD binds the device MAC to the user account; a user can be limited to a maximum number of registered devices to prevent sharing of credentials.

  • The onboarding portal must be reachable from the pre-authentication VLAN; DNS and HTTPS access to the portal are required before the device is authorized.

  • Guest and BYOD traffic should be isolated from corporate resources by VLAN and ACL; the guest VLAN should not route to internal management networks.

  • Certificate-based BYOD onboarding requires the FortiNAC certificate authority or an external CA to be configured, and the endpoint must trust the issuing CA for the enrollment to complete.

Quick reference

High Availability, Backup, and System Maintenance

  • FortiNAC-F high availability pairs two appliances in an active/passive configuration; the secondary synchronizes the database and configuration from the primary and takes over if the primary fails.

  • HA requires a dedicated heartbeat/replication network between the nodes and matching software versions, licenses, and network settings on both appliances.

  • A failover is not instantaneous: the secondary must detect the failure, promote itself, and re-establish RADIUS and device connections; sessions may need to re-authenticate.

  • Backups should be taken before upgrades and before major policy changes; the backup includes the database and configuration but not the OS image, so a rebuild requires reinstalling the same software version first.

  • Software upgrades follow the vendor's supported upgrade path; skipping major versions can leave the database schema incompatible, so intermediate versions may be required.

  • The appliance's persistent storage holds logs and the database; disk usage should be monitored because a full disk stops logging and can corrupt the database.

  • HA status and replication health are visible in the UI; a secondary that is out of sync will not provide a clean failover, so replication errors must be resolved promptly.

  • Restoring a backup to a different appliance requires matching software version and re-licensing; the restored configuration includes network device credentials and must be handled as sensitive data.

Quick reference

Monitoring, Logging, Reporting, and Troubleshooting

  • The dashboard shows endpoint counts, authentication success/failure rates, and policy hits; a sudden drop in successful authentications usually indicates a RADIUS secret mismatch or an unreachable authenticator.

  • Event logs record host state changes, policy evaluations, and enforcement actions; the log level can be raised for targeted troubleshooting and should be returned to normal afterward to avoid disk pressure.

  • RADIUS troubleshooting starts with verifying shared secrets, then UDP 1812/1813 reachability, then the authenticator's configuration; FortiNAC logs the Access-Request and the returned attributes.

  • A host stuck in 'unregistered' state usually means the portal was unreachable, the user did not complete registration, or the policy has no matching rule for that profile.

  • Profiling failures appear as 'unknown' device type; check that FortiGuard profiling updates are current and that DHCP traffic is actually visible to the appliance.

  • CoA failures show as sessions that do not change VLAN after a policy change; verify UDP 3799 reachability and that the switch supports and is configured for RFC 5176.

  • SNMP polling failures cause missing MAC table data and stale topology; check community strings, SNMPv3 credentials, ACLs, and that the device validated successfully in inventory.

  • Reports can be scheduled and exported; retention settings determine how long event and host history is kept, and long retention increases database size and backup time.