FCP FortiAuthenticator 6.5 flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

AAA framework

Authentication proves identity, authorization decides permitted actions, and accounting records activity. FortiAuthenticator concentrates on authentication and identity storage while enforcing devices apply authorization policy.

TACACS+ versus RADIUS

TACACS+ uses TCP 49, encrypts the full payload, and separates authentication from authorization, enabling per-command control. RADIUS uses UDP and combines authentication with authorization in a single reply.

TOTP algorithm

Time-based one-time password defined in RFC 6238. It derives a code from a shared secret and the current time in 30-second steps, usually producing six digits that must match within the accepted window.

HOTP algorithm

Counter-based one-time password from RFC 4226. Each authentication increments a shared counter, so the server and token must stay synchronized; drift is corrected by resynchronizing the next expected code.

Two-factor authentication

Requiring two factors from different categories: something you know, something you have, or something you are. A password plus a FortiToken OTP qualifies; two separate passwords do not.

Certificate-to-user mapping

FortiAuthenticator matches a presented client certificate to a user record by comparing a chosen field, such as Subject CN or SAN UPN, and requires the certificate to chain to a trusted CA.

Identity source realm

A realm is a namespace binding users to authentication methods and policies. One appliance can host multiple realms so separate organizations or domains get independent login behavior.

Group-based authorization

Group membership returned at authentication time drives policy. FortiGate matches a returned RADIUS or LDAP group name to a local user group referenced in firewall policy.

RADIUS Access-Challenge

Server response requesting additional credentials, typically an OTP, before a final decision. The client resubmits the request with the challenge response, ending in Access-Accept or Access-Reject.

RADIUS shared secret mismatch

When client and server secrets differ, the server silently discards the request. The client times out and the FortiAuthenticator log shows nothing, which distinguishes it from bad credentials.

RADIUS client registration

FortiAuthenticator only answers requests from NAS IP addresses configured as RADIUS clients with a matching secret. Traffic from unregistered addresses is dropped even with valid user credentials.

Fortinet-Group-Name VSA

Vendor-specific attribute returned in the RADIUS Access-Accept. FortiGate reads it to place the authenticated user into a firewall user group used by policy.

LDAP simple bind

Authentication method sending a distinguished name and password to the directory. Credentials are cleartext unless the connection uses LDAPS or StartTLS, so encrypted transport is required for secure deployments.

Remote LDAP group sync

FortiAuthenticator imports groups from a directory by base DN and filter, then refreshes membership on a schedule. Stale sync causes users to lose group-based access unexpectedly.

Local user authentication method

Per-user setting choosing static password, token OTP only, or password plus OTP. The choice determines whether the user is prompted for one or two credentials at login.

TACACS+ command authorization

After authentication, the network device queries the TACACS+ server per command to permit or deny it. This granularity is unavailable in RADIUS, which authorizes the session as a whole.

FortiAuthenticator HA mode

Active-passive clustering only. The primary and secondary synchronize configuration and optionally user data, and failover triggers on monitored interface failure or peer loss.

License binding

The FortiAuthenticator license is tied to the appliance serial number and caps managed users and FortiTokens. Replacing hardware requires obtaining and applying a new license file.

Management versus service ports

Interfaces are separated so administrative GUI and SSH traffic stays on a management network while RADIUS, LDAP, SAML, and portal services are exposed on service-facing interfaces.

FortiAuthenticator roles

A single appliance can serve as RADIUS server or proxy, LDAP server, SAML identity provider, and OIDC provider. Each role is bound to an interface and port.

Configuration backup scope

Default backup captures configuration only. User data and token seeds require the full backup option, and restores must target a compatible firmware version to avoid corruption.

Firmware upgrade path

FortiAuthenticator upgrades must follow supported routes between major releases. Skipping intermediate versions is unsupported and can damage the configuration database during conversion.

SAML identity provider role

FortiAuthenticator authenticates the user and issues a signed assertion containing attribute statements. The service provider validates the signature against the imported IdP certificate.

SP-initiated SAML flow

The user first accesses the application, which redirects to the IdP with an AuthnRequest. After authentication the signed assertion posts back to the Assertion Consumer Service URL.

IdP-initiated SAML flow

Authentication starts at the FortiAuthenticator portal and the assertion is sent without a prior AuthnRequest. Some service providers reject this flow because it lacks request correlation.

SAML attribute mapping

Assertion attribute statements carry username, group, and email claims. The service provider maps these names to local users and groups, so mismatched names break authorization after successful login.

OIDC ID token

A signed JWT returned by the token endpoint containing claims about the authenticated user. Requested scopes such as openid, profile, and email determine which claims appear.

Kerberos keytab requirement

Browser-based SSO to FortiAuthenticator needs a keytab exported from Active Directory plus a matching service account. Clock skew beyond domain tolerance invalidates tickets.

Single logout

SAML feature that terminates the IdP session and notifies participating service providers. Without it, signing out of the portal leaves application sessions still active.

FortiAuthenticator log categories

Authentication, admin, and system event logs. Each can forward to syslog or FortiAnalyzer for retention beyond local storage, and filters narrow by user, NAS IP, and result.

NTP clock synchronization

Accurate time is mandatory because TOTP windows, Kerberos ticket validity, and SAML assertion lifetimes all depend on it. Drift produces failures that look like wrong credentials.

Token drift resynchronization

When a token's counter or clock diverges, the user supplies the next expected code in the resync field. FortiAuthenticator recalculates the offset and restores successful authentication.