Fortinet FCSS_LED_AR-7.6 Fortinet NSE 6 - LAN Edge 7.6 Architect Exam Practice Test

From the exhibits:

SSID “Guest”

Security mode:Open

Captive Portal: Enabled, portal typeAuthentication → External

External portal URL: (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.

From the exhibit, LDAP on FortiGate is correctly configured and tested:

diagnose test authserver ldap FAC-LDAP wifi101 password

authenticate 'wifi101' against 'FAC-LDAP' succeeded!

Group membership(s) - CN=Domain Users,...

So:

LDAP connectivity works

Bind DN, DN, CNID, and credentials are correct(so optionCis eliminated).

Firewall policies do not affect the802.1X / Wi-Fi authentication stepitself, soAis not the root cause.

Nothing in the scenario indicates that AD is enforcing LDAPS-only; the LDAP test already succeeds using the configured parameters, soBis also excluded.

The Wi-Fi supplicant is configured forPEAP with inner authentication = MSCHAPv2.

MSCHAPv2 is achallenge–response mechanism designed for RADIUS, not for LDAP simple bind. FortiGate’s LDAP implementation uses asimple bind (username/password) over LDAP or LDAPS, and it doesnotimplement MSCHAPv2 against LDAP backends.

In Fortinet’s design, if you needPEAP-MSCHAPv2 with Active Directory, you must use:

ARADIUS server(such as Windows NPS or FortiAuthenticator), and

Have FortiGate use RADIUS,notLDAP, as the authentication backend for 802.1X / Wi-Fi users.

Because FortiGate cannot process MSCHAPv2 exchanges directly against an LDAP server, authentication fails when the inner method is MSCHAPv2, even though LDAP works when tested with a simple bind from the CLI.

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).

WithAD machine authenticationvia FortiAuthenticator:

When a machine successfully authenticates, FortiAuthenticator records:

Machine account / identity

MAC addressof the device

Associated IP and session info

To handle sleep/hibernation:

FortiAuthenticator keeps acache of authenticated MAC addressesfor a configured timeout.

When the device wakes up and sends traffic again, FortiAuthenticator/FSSO can still treat it as authenticated as long as its MAC is in cache, so access is maintained without forcing a full machine re-auth immediately.

This matches optionD.

A(guest VLAN) is not the standard behavior here.

B(WoL) is unrelated.

C(IP-based) would break as IPs can change; MAC-based caching is what’s used.

From theWTP profile:

set handoff-rssi 30

set handoff-sta-thresh 30

config radio-1

set band 802.11n-2G

set vaps "Student01"

config radio-2

set band 802.11ac-5G

set darrp enable

set arrp-profile "arrp-default"

set vaps "Student01"

Key points:

Same SSID (Student01)is broadcast onboth APsand onboth bands(2.4 and 5 GHz).

handoff-sta-thresh 30 enablesclient load-balancingbetween APs:

When an AP radio hasmore than 30 associated clients, it starts rejecting new associations so that clients connect to a neighboring AP instead (as long as RSSI is still acceptable).

Current client counts:

AP1:32 clients on 5 GHz, 22 on 2.4 GHz

AP2:12 clients on 5 GHz, 20 on 2.4 GHz

So on 5 GHz:

AP1’s 5-GHz radioexceedsthe 30-client threshold (32 > 30) → it will try topush new clients away.

AP2’s 5-GHz radio iswell belowthe threshold (12 clients) and will happily accept new clients.

The new dual-band client is seen at:

–33 dBmby AP1

–43 dBmby AP2

Even though AP1 has the stronger signal, its 5-GHz radio is already overloaded according to the configured threshold, so AP1 will refuse association attempts from that client. The client will then associate toAP2’s 5-GHz radio, which:

Hasfewer clients(better airtime per device), and

Still has an acceptable signal (–43 dBm is easily usable on 5 GHz).

That matches optionCexactly.

Other options are incorrect because they ignore the configuredclient-load-balancing thresholdsand assume association based purely on RSSI or prefer 2.4 GHz, which is not what this profile is tuned to do.

Context: You’re troubleshootingSyslog-based SSOonFortiAuthenticator:

Devices (typically firewalls, WLAN controllers, VPN gateways) sendsyslog messagescontaining usernames, IPs, login/logout events.

FortiAuthenticator parses those logs usingSyslog SSO rulesand injects logon sessions intoFSSOfor FortiGate.

When users are not mapping correctly, you need to see:

Did the syslog message arrive?

Which matching rule (if any) caught it?

What username and IP were extracted?

Why was a message ignored or rejected?

FortiAuthenticator has a dedicated debug area for this:

Debug logs → Single Sign-On → Syslog SSO

This view shows:

Raw syslog lines received

Thematching ruleapplied (or “no match”)

Parsed fields (username, IP, group)

Any parsing errors

This is exactly the tool designed totroubleshoot and diagnose Syslog SSO issues.

Why the other options are not the best for this issue

A. Debug logs > Remote Servers > Syslog Viewer

Lets you see syslog traffic in general, but doesnotshow how SSO rules are applied or why they fail. Good for connectivity checks, not SSO logic.

B. Parsing Test Tool

Useful totestpatterns and rules manually by pasting sample log lines, but it doesn’t show live traffic or running SSO sessions.

C. Debug logs > SSO Sessions page

Shows existing SSO sessions (who is logged in), but notwhya particular syslog message did not create a session.

When a FortiGate is deployed usingZero Touch Provisioning (ZTP)or auto-discovery:

FortiGate retrieves theFortiManager IP address(from DHCP Option 240, FortiCloud/ZTNA provisioning, or manual set).

The next step isnot UI authorizationor DHCP changes—it immediately attempts to form aFGFM (FortiGate–FortiManager) tunnel.

The FGFM protocol usesTCP port 541to establish a secure management channel.

FortiManager will still require manual authorization of the deviceinside FortiManager, but this occursafterthe tunnel is established.

Therefore, the first automatic action after retrieving the FMG address iscreating the secure FGFM tunnel on TCP/541.

On FortiLink, FortiGate’s built-in DHCP server is what gives FortiSwitch its IP so it can come under management. For automatic FortiSwitch onboarding, the DHCP server is usually set with:

set vci-match enable

set vci-string "FortiSwitch" "FortiExtender"

In the exhibit, the DHCP server for fortilink has:

set vci-match enable

set vci-string "FortiExtender"

Because theVCI string doesn’t include “FortiSwitch”, DHCP offers are only sent to clients whose Vendor Class Identifier matchesFortiExtender. The FortiSwitch never receives an IP, so it staysOffline.

OptionBis wrong: member "port4" matches the physical cabling in the topology.

OptionCis fine: FortiLink can be anaggregateinterface, not only physical.

OptionA(ip-managed-by-fortiipam) is unrelated; FortiIPAM isn’t required here.

FortiLink device detection relies on FortiGate'sDevice IdentificationandIoT Detectioncapabilities to classify devices connected to FortiSwitch ports.

To enabledevice identificationandvulnerability detectionfor IoT/endpoint devices in LAN Edge deployments, FortiGate must subscribe to the correct FortiGuard services.

1. Required FortiGuard License for Device Identification (IoT Detection)

The FortiOS documentation clearly states:

“IoT detection service… requires anAttack Surface Security Rating service licenseto download the IoT signature package.”

Additionally:

“The following settings are required for IoT device detection:

A validAttack Surface Security Rating service licenseto download the IoT signature package.”

This service provides:

IoT signature package

IoT device classification

Device behavior profiling

This makesAttack Surface Securitymandatory for FortiLink device detection.

2. Required FortiGuard License for Device Vulnerability Detection

FortiOS further clarifies that IoT vulnerabilities require theIoT Detection license, which is included under the same Attack Surface service entitlement:

“To detect IoT vulnerabilities the FortiGate must have a validIoT Definitions license…”

The IoT Definitions license comeswith the Attack Surface Security Rating serviceand is used for:

Scanning connected devices

Identifying IoT/endpoint vulnerabilities

Reporting vulnerability severity

Enabling NAC-based remediation (VLAN steering, port isolation)

In LAN Edge Architect, this license combination is emphasized as a foundational requirement for:

FortiSwitch NAC

FortiLink device profiling

Automated quarantine actions

IoT device classification

Vulnerability-based segmentation

3. Why the Correct Answer Is Option D

OptionDlists:

✔FortiGuard Attack Surface Security

✔FortiGuard IoT Detection

These are exactly the services required per FortiOS 7.4.1:

Attack Surface Security Rating→ provides IoT signature package + vulnerability data

IoT Detection (Definitions)→ enables actual device-type and vulnerability identification

Together they powerFortiLink Device DetectionandIoT Vulnerability Detection, which are essential LAN Edge security functions.

4. Why Other Options Are Incorrect

A. Vulnerability Management + Endpoint Protection

Not used for FortiLink device detection; Endpoint detection relies on IoT service, not FortiClient.

B. Threat Intelligence + IoT Detection

Threat Intelligence (ThreatIntel DB) is used for FAZ IOC, not LAN Edge device detection.

C. Threat Intelligence + Endpoint Protection

Same issue—does not provide IoT device classification or vulnerability scanning.

LAN Edge 7.6 Architect Context Summary

In LAN Edge designs:

FortiGate acts as the controller for FortiSwitch via FortiLink.

Device detection is done at the FortiGate level using NAC/IoT signature capabilities.

Vulnerability detection enables dynamic segmentation decisions (e.g., move device to quarantine VLAN).

To support this, two licenses aremandatory:

Attack Surface Security(includes Security Rating + IoT Detection DB)

IoT Detection(part of the same entitlement, but explicitly required for vulnerability detection)

Thus the verified answer aligns perfectly with LAN Edge operational requirements and Fortinet documentation.

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 problem states:

FortiGate receivesRADIUS accounting messagesonport3.

User-Nameattribute contains the username.

Classattribute contains the group membership.

Goal: authenticate users through RSSO and map them to the correct user groups.

To achieve this, three critical components must be configured:

✔A. RADIUS Attribute Value in the RSSO group must match the Class attribute

This is mandatory because:

RSSO user groups on FortiGate match users based onthe value inside the RADIUS attribute(usually Class).

For group assignment to work, FortiGate must compare:

RSSO User Group → RADIUS Class Attribute Value

This isexactly how FortiGate maps RSSO users to groups.

✔D. RSSO agent’s sso-attribute must be set to Class

Thesso-attributedefineswhich RADIUS attribute contains the group information.

Because group membership is carried in:

➡Class attribute

You must configure:

config user radius

set sso-attribute Class

end

This tells FortiGate:

"Use the Class attribute to derive user group membership."

✔E. rsso-endpoint-attribute must be set to User-Name

This identifieswhich RADIUS attributecarries the actualusername.

In this scenario:

RADIUS accounting messages contain the username inUser-Name.

So the correct setting is:

config user radius

set rsso-endpoint-attribute User-Name

end

This ensures the RSSO user object uses the correct username.

❌Incorrect Options Explained

B. Assign RSSO user groups to all firewall policies

Not required.

You only assign them to policies where RSSO authentication is used.

C. Device detection and Security Fabric Connection should be enabled on port3

Totally irrelevant to RSSO.

RSSO only needs RADIUS accounting, not device detection or Fabric services.