FCP FortiAuthenticator 6.5 cheat sheet

AAA separates into authentication (who you are), authorization (what you may do), and accounting (what you did); FortiAuthenticator primarily owns authentication and identity storage, while FortiGate enforces authorization policy.

RADIUS combines authentication and authorization in one Access-Accept or Access-Reject; TACACS+ separates them, which is why TACACS+ is preferred for administrative device command authorization.

LDAP is a directory protocol on TCP 389 (636 for LDAPS); FortiAuthenticator binds to an external directory as a client, or serves its own local database to clients via LDAP.

An identity source hierarchy in FortiAuthenticator: local users, remote LDAP or Active Directory, RADIUS, and SAML or OIDC identity providers; each realm can be bound to a specific authentication method.

Two-factor authentication requires factors from different categories: knowledge (password, PIN), possession (token, certificate, push), and inherence (biometric). Two passwords are not 2FA.

OTP algorithms: HOTP is counter-based (RFC 4226), TOTP is time-based with a default 30-second step (RFC 6238); both use a shared secret and typically 6 digits.

Certificate-based authentication maps a client certificate to a user by matching a field such as Subject CN, SAN UPN, or SAN email against the user record; the certificate must chain to a trusted CA.

Group membership is the usual bridge between identity and authorization: RADIUS attributes or LDAP group DNs returned at authentication time drive FortiGate firewall policy and admin profiles.

FortiToken Mobile is a software OTP app; FortiToken hardware tokens are physical. Tokens are assigned per user and can be in push, OTP, or email/SMS fallback modes.

RADIUS authentication flow: Access-Request, then Access-Challenge (optional, for OTP), then Access-Accept or Access-Reject; accounting uses Accounting-Request on UDP 1813.

RADIUS shared secret must match on client and server; a mismatch produces silent drops, so the FortiAuthenticator log shows no request while the client times out.

FortiAuthenticator RADIUS clients are defined by NAS IP plus shared secret; a FortiGate sending from an unregistered IP is ignored regardless of correct credentials.

Vendor-specific attributes (VSAs) return group or role data to the NAS; FortiGate reads Fortinet VSA 1 (Fortinet-Group-Name) to attach the user to a firewall group.

Authorization on FortiGate for a RADIUS user depends on the returned group matching a local user group name; a returned group that does not exist locally yields no policy match.

Local user authentication methods include static password, token-based OTP, and password plus OTP (two-factor); the method is set per user or inherited from the realm.

LDAP bind types: simple bind sends credentials in clear unless TLS is used; anonymous bind is read-only and cannot validate a user password.

User group types in FortiAuthenticator: local groups, remote LDAP groups synced from the directory, and RADIUS groups; group membership can be static or dynamic via LDAP filter.

TACACS+ runs on TCP 49 and encrypts the entire payload; use it when per-command authorization on network devices is required.

FortiAuthenticator is deployed as a VM or hardware appliance; initial access is over HTTPS to the management IP, with CLI access via console or SSH for recovery.

Base licensing limits the number of managed users and FortiTokens; the license file is bound to the appliance serial number, so a replaced unit needs a new license.

HA supports active-passive only; the cluster synchronizes configuration and, when configured, the user database, and failover is driven by monitored interfaces.

Interface configuration separates management and service traffic: a management port for admin GUI/SSH and service ports for RADIUS, LDAP, SAML, and portal traffic.

A realm is a namespace of users and authentication policy; multiple realms allow one appliance to serve separate organizations or domains with distinct methods.

Certificate management: import a CA chain under Certificate Management, then create a local or remote certificate for portal HTTPS, SAML signing, and LDAP over TLS.

FortiAuthenticator can act as a RADIUS server, RADIUS proxy, LDAP server, SAML IdP, and OIDC provider; each role is enabled on the relevant interface and port.

Backup and restore covers configuration only by default; user data and token seeds require the full backup option, and restore must target a compatible firmware version.

Firmware upgrade path must follow supported upgrade routes; skipping major releases is unsupported and can corrupt the configuration database.

SAML roles: FortiAuthenticator acts as Identity Provider (IdP) and issues assertions; the FortiGate or application acts as Service Provider (SP) and consumes them.

SAML assertion signing uses the IdP certificate and private key; the SP validates against the imported IdP signing certificate, so a certificate roll requires updating the SP.

SP-initiated flow: user hits the SP, is redirected to the IdP with an AuthnRequest, authenticates, and posts a signed assertion back to the Assertion Consumer Service URL.

IdP-initiated flow starts at the FortiAuthenticator portal; the assertion is sent without a prior AuthnRequest, which some SPs reject for security reasons.

SAML attribute statements carry username, group, and email; the SP maps these to local users or groups, and mismatched attribute names break authorization even when login succeeds.

OIDC uses an ID token (JWT) plus an access token from the token endpoint; scopes such as openid, profile, and email determine which claims are returned.

FortiAuthenticator SSO to FortiGate can use the agentless FSSO via RADIUS accounting or the SAML portal; the SAML method avoids installing a collector agent.

Kerberos SSO requires a keytab exported from Active Directory and a service account; clock skew beyond the domain tolerance causes ticket validation failure.

Single logout (SLO) terminates the IdP session and notifies SPs; without SLO, signing out of the portal leaves the SP session active.

Log categories include authentication events, admin events, and system events; each can be sent to syslog or a FortiAnalyzer for retention beyond local storage.

The Log Access page filters by user, NAS IP, and result; a failed login shows the reason such as invalid password, unknown user, or token failure.

RADIUS debugging on FortiAuthenticator is enabled per client or globally; the debug output shows the received attributes and the reply, which identifies attribute mismatches.

Common RADIUS failure causes: wrong shared secret, NAS IP not registered, user in the wrong realm, and timeout from an unreachable LDAP backend.

LDAP authentication failures usually trace to bind DN format, base DN scope, or an expired service account password; test with the built-in LDAP browser before blaming the client.

NTP synchronization is mandatory: TOTP validation, Kerberos, and SAML assertion validity windows all fail when the appliance clock drifts.

HA troubleshooting: check the heartbeat interface status, the peer serial and firmware match, and the sync status; a firmware mismatch blocks configuration sync.

Token issues: resync drift with the Next Token Code field, reassign a lost token, and check that the token is provisioned and activated for the user.

Maintenance tasks include reviewing admin accounts and profiles, rotating certificates before expiry, verifying backups restore, and monitoring license user and token counts.