FCSS_LED_AR-7.6 Fortinet NSE 6 - LAN Edge 7.6 Architect Questions and Answers

From the exhibits and text:

FortiGate →RADIUS→ FortiAuthenticator

FortiAuthenticator →LDAP→ Windows AD

diagnose test authserver radius ... papsucceeds

diagnose test authserver radius ... mschap2fails

This behavior matches a classic limitation documented in FortiOS:

When usingLDAPas the back-end, the RADIUS server must usePAP. CHAP/MS-CHAPv2 arenot supportedwith plain LDAP because the server cannot validate the challenge–response without access to password hashes.

In the Remote LDAP server config on FortiAuthenticator, the option“Windows Active Directory Domain Authentication” is disabled.When this feature isenabled, FortiAuthenticator can talk to AD usingKerberos/NTLMinstead of a simple LDAP bind, whichdoes support MS-CHAPv2for incoming RADIUS authentications.

So to allow MS-CHAPv2 all the way from FortiGate to AD, you must:

Keep FortiGate using RADIUS with MS-CHAPv2 → FortiAuthenticator

EnableWindows Active Directory Domain Authenticationso FortiAuthenticator can properly validate MS-CHAPv2 against AD.

Why the other options are wrong:

A. Change to CHAP– CHAP still cannot be validated over LDAP; docs say LDAP back-ends must usePAP.

C. Manually add users to local DB– That would allow local-DB auth but does not fix MS-CHAPv2 against AD.

D. Use RADIUS attributes on FortiGate– Attributes do not influence the EAP inner method; they don’t fix MS-CHAPv2 failures.

Therefore the configuration change that can realistically fix the MS-CHAPv2 problem isenabling Windows Active Directory Domain Authentication on FortiAuthenticator (B).

The FortiOS documentation explicitly states that a CSR used for certificate signing must contain accurate and valid fields, especially:

Common Name (CN)

Organization (O)

Country (C)

Public key parameters

According to the FortiGate certificate section:

Incorrect CSR field information can cause the CA to reject the request.

Reasons include:

The CA validates identity and organizational information.

Missing or malformed data invalidates PKI requirements.

The CSR is not corrected automatically by the CA.

Therefore:

✔A is correct.

Options B–D contradict PKI principles:

B is false: CAs do not issue certificates with mismatched identity fields for public trust.

C is false: CSR fields are not only for internal use; they define certificate identity.

D is false: CAs do not auto-correct CSR fields.

The correct answer is D.

The LAN Edge 7.6 Architect study guide explains that when using an external captive portal, configuring the portal URL and exempt destinations on the SSID is not enough by itself. FortiGate must also have a matching firewall policy that allows the unauthenticated client traffic path to the external portal.

The guide states: “If you are using an external captive portal server, you must configure a firewall policy and exempt web traffic to the external captive portal IP address.”

It also states: “Just selecting and applying the address object and selecting the services is not enough to allow the traffic to pass through FortiGate. You must also have a corresponding firewall policy in place that allows the pinhole traffic to pass through FortiGate.”

In the exhibit, the SSID already includes FortiAuthenticator and WindowsAD as exempt destinations/services, so option C is already configured. However, the wireless clients are connecting through the AP on port4, and the visible firewall policy shown is from the guest SSID interface to port1 for internet access. There is no policy shown that permits the required pre-authentication traffic path from the wireless side toward the external portal resources through the relevant source path. Therefore, the missing fix is the firewall policy using port4 as source.

Why the other options are incorrect:

A. Incorrect. External captive portal authentication is designed to work with an open SSID plus captive portal. WPA2-Enterprise is a different authentication model and is not required here

B. Incorrect. The study guide does not identify NAT on that policy as the reason users cannot reach the external captive portal login page. The key requirement is the exempt/pinhole firewall policy, not NAT behavior

C. Incorrect. Those address objects are already present in the SSID configuration under exempt destinations/services, so this is not the missing change.

Final verified conclusion:

Because the exempt destinations are already configured, the missing requirement is the corresponding firewall policy permitting the captive portal pinhole traffic from the wireless source path.

So the correct answer is D.

The correct answer is C.

The key clue is in the port3 interface exhibit: the RADIUSAccounting administrative access option is not enabled.

The LAN Edge 7.6 Architect study guide states:

“First, you must enable RADIUS Accounting in the Administrative Access section on the FortiGate interface where you expect to receive RSSO messages.”

The FortiOS Administration Guide says the same thing more explicitly:

“In the Administrative Access section select the RADIUS Accounting checkbox. This will open listening for port 1813 on this interface. The FortiGate will then be ready to receive RADIUS accounting messages.”

The study guide also explains what those accounting messages contain:

“These messages are sent by RADIUS clients to report user session details such as start time, stop time, interim updates, and other relevant session information.”

So if port3 is the interface used for this communication, but RADIUSAccounting is not enabled on that interface, the accounting records carrying session and usage details are not handled correctly on that interface. That makes C the best answer.

Why the other options are incorrect:

A. Incorrect. If the RADIUS shared password were wrong, RSSO authentication would not be functioning correctly. The study guide says the shared secret must match the one on the RADIUS accounting server

B. Incorrect. set rsso-radius-response enable is recommended so FortiGate sends responses to the accounting sender. Fortinet documentation says this should be enabled because otherwise some RADIUS servers may resend the same accounting message repeatedly, but it does not describe this as the main cause of missing session-detail visibility

D. Incorrect. A mismatch between sso-attribute and the RSSO group’s RADIUS Attribute Value would affect user-to-group matching on FortiGate. But the question says authentication and RSSO activity are already functioning as expected, so this is not the most likely cause

Final verified conclusion:

Because port3 is the interface carrying the RSSO communication and the exhibit shows RADIUSAccounting is not enabled there, the most likely issue is:

C. Misconfigured interface port3

From the exhibits:

SSID “Guest”

Security mode:Open

Captive Portal: Enabled, portal typeAuthentication → External

External portal URL: https://fac.trainingad.training.lab/guest (FortiAuthenticator)

Exempt destinations/services:FortiAuthenticator and WindowsAD

Firewall policy

From theGuest interface/zonetoport1 (Internet)

Source user group:guest.portal(authenticated users)

The flow for anexternal captive portalis:

Client associates to theopen Guest SSID.

Client makes an HTTP(S) request.

FortiGate intercepts and redirects the client to theexternal portal.

Client must be able toreach FortiAuthenticator’s IP(and AD if the portal needs it)before authentication.

In this setup:

Theexempt destinationsetting tells the captive portal logicnot to require authenticationfor traffic going to FortiAuthenticator and WindowsAD.

However, there still must be a firewall policy that allows traffic from the Guest SSID subnet to those exempt destinations.

The existing firewall policy uses theguest.portal user groupas a source condition, which only matchesaftersuccessful portal authentication. Before login, the client has no user identity, so:

Traffic from the unauthenticated Guest client → FortiAuthenticator isnot matchedby that policy.

It hits theimplicit deny, so the browser never reaches the login page.

To fix this, the administrator must:

Create or modify a firewall policy thatallows traffic from the Guest SSID subnet/interface to FortiAuthenticator and WindowsAD without requiring user authentication.

That is exactly what optionDdescribes.

Why the others are wrong:

A. Change SSID security mode to WPA2-Enterprise– External captive portals are normally used withopenSSIDs; WPA2-Enterprise uses 802.1X, not captive portal.

B. Disable HTTPS redirection– Redirection is required so users are sent to the portal; disabling it doesn’t solve reachability.

C. Exclude FortiAuthenticator and Windows AD from filtering– They’re already listed asexempt destinationsin the SSID configuration; the missing piece is thefirewall policy, not the exemption.

When a device’sMAC address is quarantinedon a FortiSwitch (via FortiLink NAC, fabric automation, or manual quarantine), FortiSwitch enforces quarantine using thequarantine VLAN, also called theaccess VLANinside FortiSwitch NAC operations.

FortiSwitch behavior is defined in LAN Edge documentation:

Quarantined devices are moved into an " access VLAN " reserved for isolation.

This VLAN isstatically defined on the FortiGate NAC policy, and switch ports dynamically reassign the quarantined MAC into that VLAN.

All egress traffic from the quarantined MAC is forced into this VLAN, preventing access to the production network.

Thus, the correct description is:

✔Traffic is sent to an access VLAN.

Options B, C, and D are incorrect because:

Quarantine doesnotreassign to native VLAN.

It doesnotsend untagged traffic arbitrarily.

It doesnotforward traffic to allowed VLANs

When FortiAuthenticator is used as anFSSO agentbased onsyslog, it must:

Parse incoming syslog messagesfrom devices (firewalls, WLAN controllers, VPN concentrators, etc.).

Extract identity fieldssuch as:

Username

IP address

Login/logout event indicators

Syslogmatching ruleson FortiAuthenticator define:

Which syslog messages are relevant (by facility, message pattern, or regex).

How to capture specific fields (username, IP, group, event type).

FortiAuthenticator then uses this parsed data toinject logon sessions into FSSO, so FortiGate can apply identity-based policies.

Thus, the role of syslog matching rules is exactly as described inC.

A: Group mapping is handled separately via directory groups / FSSO config, not directly by matching rules.

B: Enforcement of authentication policies is done on FortiGate, not directly by the matching rules.

D: While irrelevant logs can be ignored via rules, the primary purpose isparsing and extraction, not generic filtering.

FortiAnalyzer requires a specific license to evaluateIndicators of Compromise (IOC).

From theFortiAnalyzer 7.4.1 Administration Guide:

IOC identification requires theThreat Detection Servicelicense on FortiAnalyzer.

This license enables:

IOC database updates

Compromised host detection

Event correlation based on FortiGuard threat intelligence

Fabric-wide IOC automation triggers

Why the other answers are incorrect:

A: IoT Security add-on is unrelated to IOC rules.

B: There isnoIOC subscription license type for FortiAnalyzer.

C: FAZ-Basic license doesNOTinclude IOC detection.

In this design, FortiAuthenticator receivesRADIUS accounting (RSSO) messages, looks up the user in LDAP to get group information, theninjects FSSO logon eventstoward all FortiGate devices.

From the exhibits we know:

FortiAuthenticatoris receiving RADIUS accountingfrom the RADIUS server.

LDAP queries are successful and return group membership.

But FortiGatedoes not receive FSSO logons, so identity-based policies are not applied.

For FortiAuthenticator to create an FSSO logon, the RADIUS accounting record must be correctlyparsed into at least:

Username

Client IP address

These are mapped from the RADIUS attributes in theRADIUS Accounting SSO clientconfiguration (for example, User-Name and Framed-IP-Address). If these are not defined or mapped incorrectly, FortiAuthenticator can see the accounting packet butcannot build a valid FSSO session, so no update is sent to FortiGate.

Thus the most likely root cause is:

✔The RADIUS Username and Client IPv4 attributes are not correctly definedfor that RADIUS Accounting SSO client (optionA).

Other options conflict with the scenario:

B– LDAP is already successfully returning groups.

C– FSSO user group attribute is separate; even without it, FSSO logons would still be created (just without group mapping).

D– The interfaceisreceiving RADIUS accounting, so it is clearly enabled.

In a LAN Edge deployment:

FortiSwitch is managedthrough FortiGate via FortiLink.

FortiAIOps integrates withFortiGateas the single managed device; from there it gains visibility intoall Fabric and LAN-edge devices(FortiSwitch, FortiAP) that are registered to that FortiGate.

Once the FortiGate is successfully added to FortiAIOps (as shown in the exhibit, statusOnline / Successfully Discovered), all FortiSwitches managed by that FortiGate are:

Discovered automatically through the FortiGate–FortiAIOps connection

Shown under the appropriate inventory / switch views withno separate onboarding stepfor each switch.

This is why no extra IP, serial number, or credential entry is required for FortiSwitch.

So:

AandBsuggest manual per-switch onboarding, which is not how FortiAIOps works with LAN Edge.

Dsimilarly assumes direct FortiSwitch management, but FortiAIOps talks toFortiGate, not the switch.

Therefore the correct behavior is that theFortiSwitch is added automatically (C)once its managing FortiGate is connected to FortiAIOps.

The correct answer is A.

The LAN Edge 7.6 Architect study guide explicitly explains the difference between the two quarantine actions:

“IP ban: Traffic from the compromised device IP address is blocked on FortiGate, but intra-VLAN traffic is still allowed.”

It also states:

“Access-layer quarantine: Inter-VLAN and intra-VLAN traffic from the compromised device MAC address is blocked using FortiGate and FortiSwitch.”

That exactly matches the symptom in the question. The device has lost internet and inter-VLAN access, but it can still communicate with devices in the same VLAN. That behavior is the expected result of an IP Ban action, not full access-layer quarantine.

The study guide further explains MAC-based quarantine behavior:

“Isolation means that a quarantined device can communicate only with FortiGate. If the device tries to communicate with any other host on the network, the communication is blocked.”

And it adds:

“In both modes: Intra-VLAN traffic is blocked automatically by FortiGate.”

So to block same-VLAN communication as well, the automation action must use Access Layer Quarantine instead of IP Ban.

Why the other options are incorrect:

B. Incorrect. There is no separate “IP Ban settings to the Quarantine action” correction described in the study guide. The fix is to use the correct automation action type, which is Access Layer Quarantine

C. Incorrect. The IOC has already worked well enough to trigger the stitch. The issue is not IOC detection, but the wrong quarantine action being used, as shown by the behavior and the log/widget evidence.

D. Incorrect. The study guide does not describe a separate setting to “enable intra-VLAN traffic blocking” for Security Fabric quarantine. Instead, intra-VLAN blocking is achieved by using Access Layer Quarantine, not IP Ban

Final verified conclusion:

Because the current behavior matches IP Ban, and same-VLAN traffic is still allowed, the required fix is to replace the IP Ban action with Access Layer Quarantine.

So the correct answer is A.