FCP_FAC_AD-6-5 Practice Questions

The exhibit illustrates a hierarchical deployment model where a central, primary FortiAuthenticator acts as the main RADIUS server, and two secondary FortiAuthenticator devices function as RADIUS proxies. The secondary units receive authentication requests from clients (like FortiGate) and forward them to the primary unit for processing. This specific primary-secondary configuration, designed for scalability and centralized management across different locations or network segments, is officially defined by Fortinet as a tiered architecture. The primary server maintains the master user database, while the secondary servers handle local authentication traffic.

B. RADIUS proxy: This describes the function of the secondary devices but fails to define the entire architectural relationship between all the components shown.

C. Active-active HA: An active-active HA cluster consists of peer nodes actively processing traffic simultaneously for redundancy, which is different from the primary-secondary hierarchy depicted.

D. Authentication load balancing nodes: While this setup can distribute load, its defining characteristic is the hierarchical structure, not a simple peer-based load-balancing cluster.

1. FortiAuthenticator 6.5 Deployment Guide

Page 10

Section: "Deployment scenarios > Tiered FortiAuthenticator deployment".

The guide explicitly describes this model: "In a tiered FortiAuthenticator deployment

one FortiAuthenticator unit is the primary server

and one or more FortiAuthenticator units are secondary servers. The primary server holds the master user database. The secondary servers act as RADIUS proxies

forwarding authentication requests to the primary server." The accompanying diagram in the guide is conceptually identical to the one in the question.

2. FortiAuthenticator 6.5 Administration Guide

Page 138

Section: "System > Administration > FortiAuthenticator Sync".

This section details the configuration for the primary-secondary relationship

stating: "The primary server holds the master user database. The secondary servers act as RADIUS proxies

forwarding authentication requests to the primary server." This confirms the terminology and function of the tiered model.

To effectively monitor a FortiAuthenticator and receive traps via SNMP, two key configurations are required after enabling the service on an interface. First, on the FortiAuthenticator itself, you must define the conditions that will trigger a trap message. This is done by setting system thresholds for metrics like CPU, memory, and disk usage. Second, on the SNMP management server, you must upload the FortiAuthenticator's Management Information Base (MIB) files. The MIBs act as a dictionary, enabling the SNMP server to decode the numeric Object Identifiers (OIDs) and trap information sent by the FortiAuthenticator into human-readable text.

A. Enable logging services.

This configures syslog, which is a separate monitoring protocol. Enabling logging services is not a requirement for SNMP traps to function.

C. Associate an ASN.1 mapping rule to the receiving host.

This is not a standard configuration step. The SNMP server uses the MIB files to interpret the data, not a manually configured ASN.1 mapping rule.

1. FortiAuthenticator 6.4 Administration Guide

Page 111

"SNMP" section.

Reference for B: Under the "SNMP Traps" subsection

it states: "The FortiAuthenticator SNMP agent can send traps to an SNMP manager when certain events occur

such as high CPU usage... Use the sliders to set the thresholds for CPU

memory

and log disk usage." This directly supports configuring thresholds to trigger traps.

Reference for D: Under the "Management Information Base (MIB) files" subsection

it states: "To view SNMP data from your FortiAuthenticator unit

you must compile these MIBs into your SNMP manager." This confirms the necessity of loading MIBs onto the SNMP server.

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.

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.

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.

The "Enable NTLM" option within the FortiClient SSO Mobility Agent configuration on FortiAuthenticator is a security feature. When enabled, FortiAuthenticator challenges the FortiClient agent for NTLM authentication. This forces the authentication to be validated against the legitimate Active Directory (AD) server configured on FortiAuthenticator. This mechanism ensures that the user logon information received from FortiClient is authentic and prevents a scenario where a user might authenticate to a rogue or unauthorized AD server and still gain network access via SSO.

A. Messaging end users is not a function of the NTLM authentication challenge; it relates to user interaction features, not credential validation.

B. NTLM is a password-based, single-factor authentication protocol. Enabling it does not enforce two-factor authentication, which is a separate configuration.

D. While authentications are logged, this option's primary purpose is to perform an active security check, not simply to enable logging or tracking.

1. FortiAuthenticator 6.5 Administration Guide

Page 111

"FortiClient SSO Mobility Agent" section. The guide states: "Enable NTLM: Enable to have FortiAuthenticator challenge the FortiClient SSO mobility agent for NTLM authentication. This prevents users from authenticating to an unauthorized AD server."

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 private key of a root Certificate Authority (CA) is the most critical component in a Public Key Infrastructure (PKI). It is used to sign all certificates issued by that CA, establishing a chain of trust. For security reasons, the FortiAuthenticator is designed to never allow the export of the root CA's private key. Exposing this key would compromise the entire PKI, as an attacker could use it to issue fraudulent certificates. Therefore, the design principle is that there should be no legitimate reason to export the private key from the secure appliance where it was generated.

A. A CA, by definition, requires a public/private key pair to function. The private key is essential for signing certificates and Certificate Revocation Lists (CRLs).

B. OCSP is a protocol for checking certificate revocation status, not for key retrieval. The inability to export the key is a security design choice, not a function of OCSP.

D. A public key certificate (X.509) contains the subject's public key, issuer information, and the issuer's digital signature. It never contains the private key.

1. FortiAuthenticator 6.4.0 Administration Guide

Page 138

"Certificate Management > Certificate Authorities > Local CAs":

"The private key is generated on the FortiAuthenticator and cannot be exported. This is for security reasons

as there should never be a need to export the private key." This statement directly confirms that option C is the correct reason.

To enable captive portal services on FortiAuthenticator, two fundamental components must be configured. First, a portal policy (B) is required. This policy acts as the central logic, linking a source (like a RADIUS client), the user-facing portal page, and the authentication rules. Second, at least one portal page, which provides the login interface for users, must be configured. This is what option (A) refers to, albeit with the potentially ambiguous term "pre-login service." In the context of FortiAuthenticator's configuration, the portal page itself is the primary service presented to the user before they are fully authenticated. Without both the portal page and the policy to govern its use, the captive portal service cannot function.

C. Configuring an external authentication portal: This is an alternative, not a minimum, configuration. FortiAuthenticator hosts the portal by default, and using an external one is not a basic requirement.

D. Configuring a RADIUS client: While a RADIUS client (e.g., a FortiGate) is essential for the entire solution to work, it is configured as a client of the portal service, not as a core component of the service itself. The question focuses on enabling the services on FortiAuthenticator.

1. FortiAuthenticator 6.4.0 Administration Guide

Page 101

Chapter "Portal services". This chapter outlines the components that constitute the portal services. It includes dedicated sections for "Portals" (the user-facing login page

aligning with option A) and "Policies" (option B). This structure separates the core service configuration from client configuration.

2. FortiAuthenticator 6.4.0 Administration Guide

Page 104

"Policies". The documentation for creating a portal policy explicitly states that you must select a "Portal" (the login page) and a "Source" (the RADIUS client). This confirms that both a portal and a policy are mandatory configurations to make the service active. The policy is what "enables" the service by tying the components together.

3. FortiAuthenticator 6.2 Study Guide

Page 167

"Captive Portal". The guide lists the main FortiAuthenticator components for a captive portal solution as: "The RADIUS client"

"The portal itself"

and "The portal policy". The question asks for the two components that enable the service

which are most directly the portal itself (A) and the policy (B).

FortiAuthenticator provides flexible authentication methods for guest and captive portals. It supports email-based registration, where a user submits their email address to gain network access. This method is useful for collecting user information and simple onboarding. Additionally, FortiAuthenticator supports Social WiFi login, which integrates with external identity providers. Microsoft Live is explicitly listed in the official documentation as a supported social media site for this purpose, allowing users to authenticate using their existing Microsoft credentials, which simplifies the login process.

B. LinkedIn: While FortiAuthenticator also supports LinkedIn as a social login provider, the question requires selecting only two of the three valid options presented (A, B, and C).

D. WhatsApp: FortiAuthenticator does not list WhatsApp as a supported social login provider for guest or captive portal authentication.

1. FortiAuthenticator 6.4 Administration Guide

Page 130

Section: "Guest Portals > Social WiFi login". This section explicitly lists the supported social media sites: "FortiAuthenticator supports social WiFi login with the following social media sites: Facebook

Google

LinkedIn

Twitter

FourSquare

Instagram

Amazon

and Microsoft Live."

2. FortiAuthenticator 6.4 Administration Guide

Page 129

Section: "Guest Portals > Email address collection". This section details the configuration for allowing guests to register by providing their email address.