A utility's control-center FortiGate needs firewall-authenticated access for only three short-term contractors doing a one-week substation audit, with no existing directory service reachable from that segment. Which authentication approach best fits this situation?
Select an answer to reveal the explanation.
Short Explanation
When you've only got a handful of people and no server to ask, you don't build infrastructure — you just add the users. Local accounts on the FortiGate itself skip the round trip to a directory server that may not even be reachable from that segment. It's the right tool for a small, short-lived population, not a long-term workforce.
Full Explanation
Local user accounts store the username and password directly in the FortiGate's own configuration, so authentication succeeds without querying any external server — the correct fit when the population is tiny, temporary, and the segment may not even route to a directory service. LDAP and RADIUS both require a reachable external server and ongoing administrative coordination with that server's owner, which is disproportionate overhead for three accounts lasting a week; LDAP additionally implies these contractors already have corporate domain accounts, which the scenario does not state. FSSO is a passive mechanism that infers identity from domain controller security logs for already-authenticated domain users, so it cannot enroll brand-new contractor accounts that were never issued a domain identity in the first place. The operational caveat is that local accounts do not scale well and create password-management sprawl if reused across many engagements, so they should be disabled or deleted promptly once the audit ends. To confirm the setup is correct, check that the three accounts appear under local users on the FortiGate and that the firewall policy references a user group containing exactly those accounts, not a directory-backed group.