When FortiAuthenticator is configured to act as a self-signed or local Certificate Authority (CA), its primary function is to manage a Public Key Infrastructure (PKI). This fundamentally involves the entire lifecycle management of digital certificates, which includes creating certificate signing requests (CSRs), signing them to issue X.509 certificates, and revoking them when they are no longer valid.

To operate within a broader trusted environment, FortiAuthenticator must also be able to recognize and trust other CAs. This is achieved by importing the certificates of other trusted CAs and their corresponding Certificate Revocation Lists (CRLs), which allows it to validate certificate chains and the status of certificates issued by those external authorities.

A. OCSP (Online Certificate Status Protocol) is a method for checking a certificate's revocation status, serving as an alternative to CRLs, not a tool for validating another CA's CRL.

B. SCEP (Simple Certificate Enrollment Protocol) is used for automating certificate enrollment and renewal processes, not for merging or managing local and remote CRLs.

1. FortiAuthenticator 6.4 Administration Guide

Page 138

Section: "Certificate Management > Local CAs > Certificate authorities". This section states

"As a CA

FortiAuthenticator can sign certificate signing requests (CSRs) from other devices

and manage the Certificate Revocation List (CRL)." This directly supports the capability of creating

signing

and revoking certificates (Option D).

2. FortiAuthenticator 6.4 Administration Guide

Page 151

Section: "Certificate Management > Remote CAs > Trusted CAs". The documentation states

"You can import remote CA certificates to FortiAuthenticator. These are certificates of CAs that you trust." This supports the capability to import other CA certificates (part of Option C).

3. FortiAuthenticator 6.4 Administration Guide

Page 152

Section: "Certificate Management > Remote CAs > Certificate revocation lists". This section details the process: "You can import a certificate revocation list (CRL) from a remote CA." This supports the capability to import CRLs (part of Option C).

4. FortiAuthenticator 6.4 Administration Guide

Page 153

Section: "Certificate Management > SCEP". This section describes SCEP's function for certificate enrollment

confirming it is not used for CRL management

which invalidates Option B.

The most efficient and supported method for migrating a large number of local users from one FortiAuthenticator to another is by using the built-in import/export feature. The administrator can export the entire local user database from the source device into a comma-separated value (CSV) file. This CSV file can then be directly imported into the new FortiAuthenticator device, which will create all the user accounts in its local database. This process is designed for bulk user management and migration.

A. Import users using RADIUS accounting updates: RADIUS accounting is a protocol used for collecting information about user sessions (e.g., start/stop times, data transferred), not for populating a user database.

B. Import the current directory structure: This is not a standard FortiAuthenticator feature for local users. This terminology is more applicable to synchronizing with external directory services like LDAP or Active Directory.

C. Import users from RADIUS: RADIUS is an authentication protocol, not a user database source for bulk import. While you can configure RADIUS users, you cannot import a static user list from the protocol itself.

1. FortiAuthenticator 6.4 Administration Guide

Page 53

Section: "Authentication > User Management > Local Users".

The guide explicitly details the user management interface: "To import multiple users from a comma-separated value (CSV) file

select Import." and "To export the user list to a comma-separated value (CSV) file

select Export." This directly confirms the CSV method for bulk user migration.

The FortiClient SSO Mobility Agent is installed directly on client workstations. It monitors the user's Windows session status locally and sends logon and, crucially, logoff events directly to the FortiGate or FortiAuthenticator in real-time. This agent-based approach is transparent to the user and provides the most reliable method for logoff detection. It completely bypasses the need for a central Collector Agent to poll workstations using external mechanisms like WMI to verify if a user session is still active, directly addressing the requirements of the question.

A. RADIUS accounting reports the termination of a network access session (like VPN or 802.1X), not necessarily a user logging off their OS.

C. DC polling is effective for detecting user logons from event logs but is inherently unreliable for detecting logoffs, often requiring WMI polling to confirm session status.

D. Windows AD polling is functionally the same as DC polling and suffers from the same inability to reliably detect user logoffs without supplemental checks.

1. FortiAuthenticator 6.4 Administration Guide

Page 143

"FSSO Methods": "FortiClient SSO Mobility Agent... The agent is installed on clients and sends user logon information directly to FortiAuthenticator... This method provides reliable logoff detection."

2. Fortinet Single Sign-On (FSSO) 6.2 Administration Guide

Page 10

"FortiClient Single Sign-On Mobility Agent": "The FortiClient SSO Mobility Agent is an application that is installed on individual hosts. It allows the host to send user logon information directly to the FortiGate... This removes the need for polling."

3. FortiAuthenticator 6.2 Study Guide

Page 110

"FortiClient SSO Mobility Agent": "The agent is installed on clients and sends user logon information directly to FortiAuthenticator... This method provides reliable logoff detection." This source explicitly contrasts it with polling methods that have challenges with logoff detection.

FortiAuthenticator is a centralized identity and access management solution within the Fortinet Security Fabric. Its three primary functions are:

1. Identity Management: It serves as a central point for managing user identities, providing authentication, authorization, and accounting (AAA) services. It integrates with various directories like LDAP and Active Directory and supports numerous authentication methods, including two-factor authentication with FortiTokens.

2. Portal Services: It offers customizable captive portals for various use cases, including guest management, social Wi-Fi logins, and user self-service for password resets or device registration.

3. Certificate Authority (CA): It can function as a local CA to issue, manage, and validate digital certificates for users and devices, which is critical for secure network access methods like 802.1X EAP-TLS and VPNs.

D. Log server: FortiAuthenticator generates logs for its own events but is not designed as a primary log aggregation and analysis server like FortiAnalyzer.

E. RSSO server: While FortiAuthenticator can function as a RADIUS Single Sign-On (RSSO) server, this is a specific SSO feature. The chosen options represent broader, more fundamental capabilities of the platform.

1. FortiAuthenticator 6.5.0 Administration Guide

"Introduction

" Page 7: "FortiAuthenticator is the gatekeeper of the Fortinet Security Fabric

providing centralized

secure two-factor authentication and identity management... FortiAuthenticator is the Certificate Authority for the Security Fabric

managing the certificate lifecycle for all of the other Fabric elements." This supports options A and C.

2. FortiAuthenticator Datasheet

Page 1: The datasheet highlights key features under "Highlights

" including "Guest and contractor management with customizable captive portals

" "Certificate management for the enterprise (CA)

" and "Secure access management with two-factor authentication

RADIUS

LDAP

802.1X

and SAML." This directly supports options A

B

and C.

3. Fortinet Certified Professional - FortiAuthenticator 6.4 Study Guide

"Introduction to FortiAuthenticator

" Page 6: This official study guide outlines the core functions

stating

"FortiAuthenticator is a centralized authentication server... It can also be used as a certificate authority (CA)... FortiAuthenticator also provides guest management services through its captive portal." This confirms A

B

and C as key features.

FortiAuthenticator provides an "emergency code" feature specifically for situations where a user cannot use their primary two-factor authentication method, such as a lost token. An administrator can generate a one-time use code and provide it to the user (e.g., over the phone). The user can then enter this code instead of their regular token code to gain temporary access to the resource. This method maintains security by providing a single-use credential without disabling the 2FA policy.

A. Generate and provide an HOTP to the user: This is incorrect because generating a new HOTP token is part of provisioning a new, permanent token, not providing temporary emergency access.

C. Disable two-factor authentication on the resource: This is a significant security risk. Disabling the policy for all users to solve a single user's temporary issue is an insecure and inappropriate administrative action.

D. Refresh the FTM provisioning status for the user: This action is used to resynchronize a FortiToken Mobile (FTM) application. It is irrelevant if the user's token is lost and does not provide an access code.

1. FortiAuthenticator 6.4 Administration Guide

Page 101

"Emergency codes".

The document states

"Emergency codes are one-time use codes that can be used in place of a FortiToken when a user has lost or forgotten their token. The administrator can enable this feature and provide the user with a code to allow them to log in." This directly supports the use of emergency codes as the correct procedure.

2. FortiAuthenticator 6.2 Administration Guide

Page 91

"Emergency codes".

This guide provides the same explanation: "Emergency codes are one-time use codes that can be used in place of a FortiToken when a user has lost or forgotten their token." This confirms the feature's purpose.

When configuring a remote LDAP server on FortiAuthenticator, server type templates (e.g., Microsoft Active Directory, OpenLDAP) are used to simplify the setup process. These templates contain pre-defined schema information specific to the selected LDAP server type. By choosing a template, FortiAuthenticator automatically populates the query element fields, such as the Username attribute, User object class, Group object class, and Group member attribute, with the standard values used by that directory service. This saves the administrator from having to manually look up and enter these schema-specific attributes.

A. They autopopulate the simple and regular bind settings.

Bind settings require specific administrator credentials (username and password) to connect to the LDAP server, which a generic template cannot provide.

B. They automatically set the LDAP user auto provisioning settings.

User auto-provisioning is a separate configuration option that determines if and how users are created on FortiAuthenticator; it is not controlled by the server type template.

D. They define the connection security and domain authentication settings for each LDAP server you integrate with.

Connection security (e.g., LDAPS, STARTTLS) and server IP/FQDN are environment-specific settings that must be configured manually for each individual server connection.

1. FortiAuthenticator 6.4 Administration Guide

Page 111

Section: "Authentication > Remote Auth. Servers > LDAP > Create New".

The guide states: "The Server type drop-down list allows you to select a template for the LDAP server you are connecting to. The template will automatically populate the query element fields with the appropriate defined attribute and class values." This directly supports the correct answer (C) and refutes the other options. The fields populated are listed as Username attribute

User object class

Group object class

etc.

In a FortiAuthenticator active-active High Availability (HA) cluster, the primary goal is to synchronize configuration and user data to ensure consistent service. However, certain types of data are intentionally not synchronized to maintain node independence and reduce replication overhead.

The FortiAuthenticator Administration Guide explicitly states that real-time, high-volume data such as FSSO logon events are not synchronized. Each node maintains its own table of FSSO events.

While FortiToken data is synchronized, the term seeds can refer to system-level cryptographic seeds for functions like random number generation. These are unique to each appliance and are not synchronized as part of the HA process.

A. Group mappings: This is fundamental configuration data that defines user access and policies. It is always synchronized to ensure consistent behavior across the cluster.

B. User certificates: These are critical components of user identity data. The official documentation explicitly lists user certificates as data that is synchronized between HA members.

1. FortiAuthenticator 6.4 Administration Guide

Page 171

"High Availability" > "Synchronization".

This section provides a list of data that is not synchronized: "The following information is not synchronized between cluster members: FSSO logon events

RADIUS accounting data

Syslog data

Debug logs." This directly supports that FSSO events (C) are not synchronized.

The same section lists data that is synchronized

including: "Configuration"

"User data (local users

remote user sync data...)"

and "User certificates". This directly refutes option B and indirectly refutes A (as group mappings are part of the configuration).

2. FortiAuthenticator 6.2 Administration Guide

Page 160

"High Availability" > "Synchronization".

This guide contains the same lists

confirming that FSSO logon events (C) are not synchronized

while "User certificates" (B) and "FortiTokens" are synchronized. The synchronization of FortiTokens implies their essential data is replicated

but system-level seeds (D) for other cryptographic functions remain node-specific.

Portal authentication is the appropriate method for this scenario. It redirects users on unidentified devices, such as Android BYOD, to a captive portal web page. This portal can be configured with a self-registration option, allowing users to create their own accounts and credentials to gain network access. This is ideal for guest or BYOD environments where users do not have pre-existing credentials and their devices are not part of a corporate domain, making transparent authentication methods unsuitable.

A. Syslog messaging or SAML IdP: Syslog is a passive identification method based on logs from other devices. SAML is for single sign-on, assuming credentials already exist. Neither allows for self-registration.

C. Kerberos-based authentication: This method is for domain-joined devices and requires pre-existing user credentials within an Active Directory environment, which is not applicable to unidentified BYOD devices.

D. SSOMA: The Single Sign-On Mobility Agent (SSOMA) is software installed on endpoints to provide transparent authentication. It cannot be used on devices that do not have it pre-installed.

1. FortiAuthenticator 6.4 Administration Guide

Page 120

"Portals": "Captive portals are used to authenticate users on a network. When an unauthenticated user attempts to access a protected resource

they are redirected to a portal page to authenticate."

2. FortiAuthenticator 6.4 Administration Guide

Page 151

"Guest portals": "Guest portals allow temporary users to self-register for network access. The guest portal can be configured to require guests to enter their name

email address

phone number

and a sponsor's email address." This directly supports the "register and create their own credentials" requirement.

3. FortiAuthenticator 6.4 Administration Guide

Page 21

"Kerberos authentication": "Kerberos authentication enables transparent authentication for domain-joined clients." This confirms it is not for unidentified

non-domain devices.

For an active-passive High Availability (HA) deployment, Fortinet strongly recommends a direct, back-to-back cable connection between the designated HA heartbeat interfaces of the two FortiADC units. This dedicated link is crucial for both heartbeat messages and data synchronization. Using a direct connection minimizes latency and eliminates intermediate network devices, such as switches, which could become single points of failure. This configuration provides the most reliable and fastest communication path, preventing false failovers and ensuring seamless state synchronization between the primary and secondary appliances.

A. Dedicated fiber channel: This specifies a connection medium. While a direct fiber connection is valid, the core recommendation is the direct topology, not the specific cable type (copper or fiber).

B. Same VLAN: Connecting through a switch on the same VLAN is explicitly discouraged as it introduces a potential point of failure (the switch) and adds unnecessary latency to the critical HA link.

C. Dedicated point-to-point VPN connection: This method is used for geographically dispersed HA (Geo-HA) deployments, not for standard co-located active-passive clusters, as it adds significant overhead and complexity.

1. Fortinet FortiADC Handbook - High Availability v6.2.0

Page 11

Section: "Deployment topologies > Active-Passive". The document states

"For the heartbeat and synchronization link

we recommend you use a crossover cable to directly connect the two appliances." The accompanying diagram (Figure 5) visually depicts this direct connection.

2. Fortinet FortiADC Administration Guide v6.2.0

Page 329

Section: "High Availability > Configuring HA". The guide's configuration steps and diagrams consistently illustrate a direct link for the HA heartbeat

reinforcing this as the standard and recommended practice.

The log message "Authentication failed, user not found" is generated even though the user account exists on the FortiAuthenticator. This specific error indicates that the user lookup process for the RADIUS service failed. This occurs when the user account, while present in the system, does not have the Allow RADIUS authentication option enabled. The FortiAuthenticator's RADIUS service queries for users who are explicitly permitted to use it; if the flag is not set for the user jdoe, the service considers the user "not found" for the purpose of this authentication request.

A. An incorrect source IP from the Network Access Server (NAS) would result in a log message such as "Unknown NAS" or "Invalid client", not a user-related error.

B. A missing client entry for the AP is the same issue as an incorrect NAS IP, which would generate a client-related error, not "user not found".

C. An incorrect RADIUS secret would cause the initial packet decryption to fail, leading to a log message like "Invalid authenticator" or "Bad authenticator", which occurs before the user lookup stage.

1. Fortinet Knowledge Base

Technical Tip: FortiAuthenticator RADIUS debug - 'user not found' (Article ID: FD46111): This article directly addresses the scenario. It states

"This error message can be misleading. It does not necessarily mean that the user does not exist in the FortiAuthenticator database. It can also mean that the user is not allowed to authenticate using RADIUS. To solve this issue

edit the user under Authentication > User Management > Local Users and ensure that 'Allow RADIUS authentication' is enabled."

2. FortiAuthenticator 6.4.0 Administration Guide

Page 161 (Troubleshooting Section): In the troubleshooting guide for RADIUS authentication

it explicitly notes: "If the log message reads 'user not found' but you know the user exists

check that RADIUS authentication is enabled for that user (Authentication > User Management > Local Users)."

3. FortiAuthenticator 6.5.0 Administration Guide

Page 61 (Local Users Section): When creating or editing a local user under Authentication > User Management > Local Users

the "Allow RADIUS authentication" toggle is a required setting for the user to be able to authenticate via the RADIUS service. If disabled

the user is ineligible for RADIUS authentication.