NSE6 Part 2: FortiAuthenticator Architecture and Local Authentication

FortiAuthenticator sits at the centre of the Secure Networking stack as the identity store and authentication broker. Before you can use it as a RADIUS server for FortiSwitch 802.1X or as a certificate authority for FortiAP mesh backhaul, you need to understand how it is deployed and how its local authentication database works.

---

What FortiAuthenticator Does

FortiAuthenticator provides several distinct services, often running simultaneously on the same appliance:

Service	What it does
RADIUS server	Receives auth requests from FortiGate, FortiSwitch, SSL-VPN, etc.
LDAP proxy	Validates against upstream AD, returns group membership
Certificate Authority	Issues, signs, and revokes X.509 certificates
SAML Identity Provider	SSO for web applications and FortiGate SAML SP
FortiToken OTP server	Validates TOTP codes from hardware tokens and FortiToken Mobile
Self-service portal	Password reset, token activation, guest account management
FSSO collector	Sends identity events to FortiGate for user-based policy matching

The FCA-FAC exam tests all of these. This part covers the foundation: deployment and local auth. RADIUS, LDAP, and 2FA follow in Parts 3 and 4.

---

Hardware Platforms and Sizing

Fortinet ships FortiAuthenticator as physical appliances and as a VM:

Physical appliances:

• FAC-200E — entry-level, 200 users included, upgradeable to 10,000
• FAC-300F — mid-range, 500 users included, scales to 100,000
• FAC-3000F — high-end, for large enterprise or MSSP

FortiAuthenticator-VM: runs on VMware ESXi, KVM, Hyper-V, or in the cloud (AWS/Azure). An evaluation VM licence includes 10 users — enough for a lab. Production VM licences are purchased per user tier.

User licence = the number of local users FAC can hold. Remote authentication pass-through (proxying to AD) does not consume the user licence unless FAC is caching the user.

FortiToken licences are separate: each FortiToken Mobile or hardware token activation consumes one FortiToken licence. A base FAC installation includes a small number of token licences; more are purchased via FortiToken-MOBILE-* or FortiToken-200CD-* SKUs.

---

Deployment Modes

Standalone

The default mode. One FAC instance handles all authentication, portal, and CA functions. There is no redundancy — if it fails, authentication stops. Acceptable for lab and small deployments.

Active-Passive HA

Two FortiAuthenticator units with a dedicated HA heartbeat link. Configuration, user database, token seeds, and certificates all synchronise to the standby. Failover is automatic when the primary heartbeat stops.

Key points:

• Both units must be on the same firmware version before enabling HA.
• The HA heartbeat interface is separate from the management/RADIUS interface.
• Failover: the standby begins responding on the primary’s IP within a few seconds.
• The standby unit is accessible for monitoring but does not process authentication in active/passive mode.

CLI check:

diagnose ha status

Load-Sharing Cluster (Active-Active)

Available from FAC 6.0+. Multiple units share authentication load using a virtual IP. Less common on the exam than active-passive, but you should know it exists.

---

Initial Setup

Out of the box, FortiAuthenticator ships with admin / (blank password) on the console port, and 192.168.1.99 on port1.

Step 1 — Console login and interface config:

config system interface
  edit port1
    set ip 10.0.0.10/24
    set allowaccess https ping ssh
  next
end
config router static
  edit 1
    set gateway 10.0.0.1
    set device port1
  next
end

Step 2 — Admin password:

config system admin
  edit admin
    set password <yourpassword>
  next
end

Step 3 — Hostname, DNS, NTP: Set under System > Dashboard > Status in the GUI, or:

config system global
  set hostname FAC01
end
config system dns
  set primary 8.8.8.8
end
config system ntp
  set ntpsync enable
  set server-mode enable
  set syncinterval 60
end

Step 4 — Licence upload: System > Administration > Licence. Upload the .lic file from the FortiCare portal. Without a licence, FAC operates in eval mode (10 users, 10 tokens).

---

Local Users

Local users are the core of the FAC identity store. RADIUS clients (FortiGate, FortiSwitch) authenticate against them.

Creating a local user (GUI): Authentication > User Management > Local Users > Create New

Key fields:

Field	Notes
Username	Case-sensitive
Password	Stored as bcrypt hash
Email / Mobile	Used for email OTP delivery and self-service portal
Token	Assign a FortiToken for 2FA (covered in Part 4)
User Groups	Determines RADIUS response attributes (covered in Part 3)
Account expiry	Optional; useful for contractors
Enable	Must be checked for auth to succeed

CLI:

config user local
  edit "micheal.garner"
    set type password
    set passwd <password>
    set email-to "[email protected]"
    set mobile-number "07700900000"
  next
end

---

User Groups

User groups serve two purposes:

1. Organisational — collecting users for bulk operations.
2. RADIUS attribute mapping — a group membership can cause FAC to return specific RADIUS attributes in the Access-Accept, such as a Fortinet-Group-Name VSA that FortiGate uses for RBAC, or Tunnel-Private-Group-ID for VLAN assignment on FortiSwitch.

Creating a group: Authentication > User Management > User Groups > Create New

Group types:

• Local — members are local FAC users
• LDAP — members pulled from an AD group via LDAP filter (covered in Part 3)
• RADIUS — for pass-through remote auth groups

For the exam: understand that the group an account belongs to is what drives the RADIUS response attributes, not the username directly.

---

Password Policies

Authentication > User Account Policies > Password Policy

Key policy settings:

Setting	Exam-relevant detail
Minimum length	Exam favourite — default is 8
Complexity	Upper/lower/numeric/special character requirements
Maximum age (days)	Forces periodic reset; 0 = never expires
Reuse history	Number of previous passwords disallowed
Lockout threshold	Failed attempts before lockout
Lockout duration	Minutes locked out; 0 = admin unlock required

The account lockout threshold and duration are exam favourites. Know that if lockout-duration = 0, the admin must manually unlock the account — the user cannot wait it out.

---

Account Lockout and Unlock

When a user exceeds the failed-attempt threshold, their account state changes to Locked. The admin unlocks it at: Authentication > User Management > Local Users > [select user] > Unlock

Or via CLI:

execute user unlock <username>

The self-service portal can be configured to allow users to unlock their own accounts via an email verification step — covered in Part 4.

---

Admin Profiles and Remote Admin Authentication

FortiAuthenticator supports multiple admin accounts with role-based access:

• Super admin — full access including HA, licensing, and CA
• Read/write — configuration access but no system changes
• Read-only — monitoring only

Admin accounts themselves can be authenticated locally or via a remote LDAP/RADIUS server. This creates a chicken-and-egg problem: if remote auth is broken, ensure a local fallback admin account exists.

System > Administration > Admin Profiles

Remote admin auth via RADIUS is sometimes tested: the admin account maps to a specific admin profile based on a RADIUS VSA (Fortinet-Admin-Profile = <profile-name>).

---

Key Diagnostic Commands

# Test local auth directly (no RADIUS, no token)
diagnose test authserver local <username> <password>

# View current user lockout states
diagnose user list

# Show RADIUS service status
diagnose radiusd show-clients

# Real-time debug of authentication attempts
diagnose debug application authd 255
diagnose debug enable
# ... reproduce issue ...
diagnose debug disable
diagnose debug reset

The authd debug stream shows exactly which authentication path FAC is taking — local, LDAP, or RADIUS — and at what point a failure occurs. This is the first thing to reach for on the exam when a question says “users can’t authenticate — what should you check?”

---

What to Have Ready for Part 3

Before moving to RADIUS service configuration, confirm you have:

• At least one local user created and enabled
• That user assigned to a group
• FAC accessible on the network from the device that will be the RADIUS client (FortiGate or FortiSwitch)
• Time synchronised (critical for FortiToken TOTP — covered in Part 4)