FortiNAC-F Deployment and Initial Configuration
Domain 1 covers the decisions that turn a FortiNAC-F appliance into a working NAC platform: interface roles, licensing, time and certificate services, and the isolation path endpoints use before authorization. The exam tests operational judgment, not menu memorization.
Core rules
- Choose standalone or active-passive HA before production. HA pairs need matching model and firmware, a dedicated heartbeat path, a virtual IP for administration and RADIUS, and synchronized configuration. Do not build the secondary as an independent system.
- Map interfaces deliberately. The management interface carries admin UI, backups, syslog, and often RADIUS; the isolation interface serves the registration and guest portal network. Endpoints must reach the portal before they are authorized.
- Run the console or SSH setup wizard: hostname, management IP/mask/gateway, DNS, NTP, and time zone. NTP is not cosmetic; certificate validation, RADIUS, and log correlation depend on correct time.
- Install and verify licensing before cutover. Capacity is endpoint-based, so an undersized license becomes a production outage.
- Replace default certificates with trusted ones for the admin UI, portal, and EAP. If BYOD will use certificate onboarding, plan the CA chain now.
- Define the isolation VLAN on the switches and routers, and provide DHCP plus DNS. The appliance cannot enforce a VLAN that the network does not carry.
Worked example
A hospital deploys an HA pair for wired 802.1X and guest Wi-Fi. The engineer racks two identical appliances, loads the same firmware, configures the primary management IP and VIP, joins the secondary, and confirms config sync. Switch access ports are set to an isolation VLAN with a DHCP helper pointing to the FortiNAC DHCP scope; the guest SSID maps to the same VLAN. After licensing and certificate replacement, the engineer tests failover by pulling the primary heartbeat. The VIP moves, and a new guest still receives the portal. The reasoning: isolation reachability is a prerequisite for every later policy, and HA is only proven by a failover test.
Traps
- Treating the secondary as a second standalone server, causing split configuration.
- Forgetting DNS or NTP, which breaks portal resolution and certificate checks.
- Licensing after HA formation, then discovering capacity or sync issues.
- Leaving the isolation VLAN undefined on access switches.
- Using the default certificate in production and breaking supplicant trust.