Fortinet FCP_FGT_AD-7.4 Practice Questions

Summary
The Reverse Path Forwarding (RPF) check is a security feature used to mitigate IP spoofing attacks. It works by verifying that the source IP address of an incoming packet is reachable through the same interface on which the packet was received. This check is performed at the very beginning of a session to determine if the traffic is legitimate before establishing a session entry.

Correct Option

A. The RPF check is run on the first sent packet of any new session.:
This is correct. The RPF check is triggered by the very first packet that initiates a new session (the "sent" packet from the perspective of the originator). The FortiGate uses this packet to verify the validity of the source IP before creating a session in the session table.

D. The RPF check is a mechanism that protects FortiGate and the network from IP spoofing attacks.:
This is correct. This is the primary purpose of the RPF check. By ensuring that a packet arrives on the interface that would be used to route traffic back to its source, it prevents an attacker from forging (spoofing) a source IP address, which is a common technique in reflection and amplification attacks.

Incorrect Option

B. The RPF check is run on the first reply packet of any new session.:
This is incorrect. The RPF check is performed on the initial packet that starts the session. Once a session is established in the session table, subsequent packets, including reply packets, are matched to the existing session and do not undergo a new RPF check.

C. The RPF check is run on the first sent and reply packet of any new session.:
This is incorrect. The check is a one-time operation performed only on the initial packet of a session to validate the source. The reply packet is part of the established session and is not subject to a second RPF verification.

Reference
Fortinet Documentation Library: Reverse path forwarding

Summary
During SSL/SSH full inspection on FortiGate, if an invalid certificate is detected (e.g., expired, untrusted, or mismatched), administrators can configure specific actions in the SSL/SSH inspection profile. Valid responses include blocking the connection outright, allowing it silently, or combining block/allow with a warning page to inform users, balancing security and usability.

Correct Option

A. Allow & Warning
FortiGate permits the SSL/SSH session to proceed despite the invalid certificate but injects a warning page (for HTTPS) or notification to alert the user. This allows controlled access while maintaining visibility into potential risks.

D. Block & Warning
FortiGate blocks the connection and displays a warning page explaining the certificate issue (e.g., expired or untrusted). This enforces strict security while educating users, commonly used in high-security environments.

E. Block
FortiGate immediately drops the SSL/SSH session without any user notification when an invalid certificate is detected. This silent enforcement ensures no risky connections proceed, ideal for automated or strict policy compliance.

Incorrect Option

B. Trust & Allow
There is no "Trust & Allow" action in FortiGate SSL/SSH inspection profiles. Certificates are either validated against trusted CAs or marked invalid; FortiGate cannot dynamically "trust" an invalid certificate without manual CA import.

C. Allow
While allowing invalid certificates may seem plausible, FortiGate does not offer a standalone "Allow" action without warning in full inspection mode. Silent allowance contradicts deep inspection security principles and is not a configurable option.

Reference
https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/432567/ssl-inspection#deep-inspection

Summary
SD-WAN rules use strategies to determine how traffic is distributed across member interfaces. These strategies are based on performance measurements (SLA) and can be configured to either use a single best-performing member or to load-balance across multiple members that meet the performance criteria.

Correct Option

A. Manual with load balancing:
This is a valid strategy. It ignores SLA targets and distributes traffic according to a manually configured weight (ratio) assigned to each SD-WAN member interface. This is useful for basic, non-performance-based distribution of traffic.

B. Lowest Cost (SLA) with load balancing:
This is a valid strategy. It identifies all member interfaces that meet the configured SLA targets and then performs load balancing across them. The "Lowest Cost" refers to the interface priority/weight, where traffic is preferably sent over higher-priority (lower cost) members.

C. Best Quality with load balancing:
This is a valid strategy. It identifies all member interfaces that meet the SLA targets and then load-balances sessions across them. This strategy is focused on maintaining quality by only using members that pass the SLA health checks.

Incorrect Option

D. Lowest Quality (SLA) with load balancing:
This is not a valid strategy. There is no defined strategy that intentionally selects the lowest quality members. The purpose of SD-WAN is to enhance performance and reliability by using the best-available paths, not the worst.

E. Lowest Cost (SLA) without load balancing:
This is a distractor and not a direct strategy name. The standard "Lowest Cost" strategy without the load-balancing option simply selects the single highest-priority (lowest cost) member that meets the SLA targets. It does not actively load balance across multiple members.

Reference
Fortinet Documentation Library: SD-WAN rule strategy (Documents the Manual, Lowest Cost, and Best Quality strategies and the load-balance option).

Summary
This scenario describes a site-to-site connection using SSL VPN between two FortiGate devices, where one acts as the client (initiator) and the other as the server (listener). For this to work, the client must be configured with the correct tunnel interface type to establish the connection, and both parties must use certificates for authentication, with the server trusting the CA that issued the client's certificate.

Correct Option

A. The client FortiGate requires the SSL VPN tunnel interface type to connect SSL VPN:
This is correct. On the client FortiGate, the SSL VPN is configured under a tunnel interface (usually of type ssl-vpn). This interface is the endpoint for the tunnel and is used in firewall policies and routing, just like an IPsec tunnel interface. This configuration is mandatory for the client to initiate the connection.

C. The client FortiGate requires a client certificate signed by the CA on the server FortiGate.:
This is correct. For certificate-based authentication, the client FortiGate must have a certificate (a "client certificate") that is signed by a Certificate Authority (CA) which the server FortiGate trusts. The server uses its CA certificate to verify the signature on the client's certificate, establishing trust.

Incorrect Option

B. The server FortiGate requires a CA certificate to verify the client FortiGate certificate.:
This is partially true but not strictly "required" in all cases. While certificate authentication is highly recommended and more secure, the server FortiGate can also be configured to use pre-shared keys (PSK) for authentication. Therefore, a CA certificate is not an absolute requirement for the SSL VPN to function.

D. The client FortiGate requires a manually added route to remote subnets.:
This is not a requirement for the SSL VPN to function (establish). While a static route is necessary for the client FortiGate to know to send traffic for the remote network over the SSL VPN tunnel, the tunnel interface can be established without it. The route is needed for traffic to flow through the tunnel after it is up, but it is not a prerequisite for the tunnel itself to come online.

Reference
Fortinet Documentation Library: SSL VPN for FortiGate (This guide covers the configuration of both the server and client FortiGate, including interface and certificate settings).

Summary
A high-latency connection causes significant delays in packet delivery. The SSL VPN negotiation process has built-in timers that expect a response within a specific window. If the round-trip time exceeds this window due to latency, the negotiation will fail. Adjusting the timer for the initial handshake phase can resolve this.

Correct Option

C. SSL VPN dtls-hello-timeout:
This is the correct setting. DTLS (Datagram Transport Layer Security) is the protocol often used to accelerate SSL VPN performance by running over UDP. The dtls-hello-timeout defines how long the FortiGate will wait for a response to its initial DTLS "ClientHello" message. On a high-latency link, increasing this value gives the remote client more time to respond, preventing the FortiGate from prematurely terminating the negotiation.

Incorrect Option

A. SSL VPN idle-timeout:
This setting determines how long an established SSL VPN tunnel can remain idle before it is automatically disconnected. It does not affect the initial connection negotiation phase and will not help with a negotiation failure.

B. SSL VPN login-timeout:
This setting defines how long a user has to enter their credentials on the SSL VPN web portal after the HTTP connection is established. It is unrelated to the underlying DTLS/TLS handshake that happens during the tunnel negotiation.

D. SSL VPN session-ttl:
This setting defines the maximum total lifetime of an SSL VPN session, after which the user must reconnect. It is a limit for active sessions and does not impact the initial setup handshake on a slow link.

Reference
Fortinet Documentation Library: config vpn ssl web portal (The set dtls-hello-timeout command is available within this context to adjust the wait time).

Summary
The FortiGate Collector Agent (CA) for Fortinet Single Sign-On (FSSO) uses AD polling to gather user logon information when event log-based methods are unavailable. It supports three polling methods: WMI for remote logon session queries, NetAPI for browser-based domain enumeration, and WinSecLog for Windows Security Event Log polling, enabling reliable identity mapping in diverse environments.

Correct Option

B. WMI
The Collector Agent uses Windows Management Instrumentation (WMI) to remotely query domain controllers for active logon sessions. It polls every 10 seconds by default, retrieving username, IP, and workstation details without requiring event logs, ideal for environments with restricted DC access.

C. NetAPI
NetAPI (Network API) allows the CA to query domain controllers via NetSessionEnum and NetWkstaUserEnum calls. This method enumerates logged-on users per server, supporting legacy systems and providing fallback when WMI is blocked or unavailable.

A. WinSecLog
WinSecLog polls Windows Security Event Logs (specifically event IDs 4624/4768) on domain controllers at configurable intervals. It captures logon events in real-time if polling is frequent, serving as an alternative to DC agent push methods.

Incorrect Option

D. FSSO REST API
The FSSO REST API is used for communication between FortiGate and Collector Agent or for third-party integrations, not as a polling method. The CA does not poll AD via REST; it relies on native Windows protocols like WMI/NetAPI.

E. FortiGate polling
FortiGate itself does not poll AD for FSSO; it receives user-to-IP mappings from the Collector Agent or DC Agent. Direct FortiGate polling of AD is limited to LDAP group filters, not logon session discovery.

Reference
https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/975464/collector-agent-based-polling

Explanation:

To retrieve AD user group information in agentless polling mode, the administrator must add an LDAP server to the FortiGate device.