A field technician, working temporarily from a hotel network while traveling, tries to log in to the FortiGate using their personal administrator account and the correct password, but the login is rejected. The account's trusted hosts are configured to only the NOC management subnet. What is the most likely reason the login failed?
Select an answer to reveal the explanation.
Short Explanation
Trusted hosts don't care how correct your password is — they check where the login is coming from first. That hotel network's IP address sits outside the NOC subnet the account is locked to, so the FortiGate rejects the attempt before your password even matters.
Full Explanation
Trusted hosts enforce a source-address restriction directly on the administrator account, rejecting any authentication attempt from outside the configured range regardless of whether the password is correct. Since the account is scoped only to the NOC management subnet and the technician is connecting from a hotel network with a different source IP, the trusted-hosts check fails first, and the login is refused before password validation would even matter. A password-expiration failure would typically present as an explicit prompt about the credential itself, not a rejection tied to location, and nothing in the scenario suggests expiration is the trigger. An access profile with no permissions would still let the account authenticate successfully — permissions govern what a logged-in account can do, not whether the login is accepted — so it wouldn't explain a rejected login with a correct password. Two-factor authentication, if enabled, occurs only after primary authentication succeeds; since trusted hosts block the connection before that stage, an unfinished second factor isn't what's blocking this login. To resolve it, add the hotel network's address range to the account's trusted hosts temporarily, or have the technician connect through the utility's VPN so their effective source address falls within the NOC subnet.