Technical Tip: How Trusted Hosts work with SSO Admin accounts on the FortiGate

[pjang]

Description	This article describes the behavior of the Trusted Hosts feature and how it interacts with Single Sign-On (SSO) Administrators on the FortiGate.
Scope	FortiGate, SAML.
Solution	First, a primer regarding key behaviors of Trusted Hosts and how they enhance security: Trusted Hosts can only be configured for Local Administrator accounts and REST API Administrator accounts. If Trusted Hosts are configured on an admin account then it is only possible to login to that specific account when coming from a Trusted Host source subnet. If all Local/REST API Administrator accounts have Trusted Hosts configured then the FortiGate will only allow login connection attempts from the source subnets included across all Trusted Hosts. In other words, if someone attempts to log in to the FortiGate from a source address that is not on the Trusted Hosts list for any of the admin accounts then the connection will fail to establish and will not display any login prompts/pages. Next, consider the following behaviors observed with Single Sign-On (SSO) Administrator accounts on the FortiGate: It is not possible to configure Trusted Hosts on SSO Admin accounts directly. The option does not exist in the FortiGate GUI, nor is it available in the CLI for any kind of SSO Administrator account (SAML-based SSO, FortiCloud SSO, FortiGate Cloud SSO, etc.). However, users must have access to the FortiGate Web GUI if desired to login using a SAML-based SSO Administrator account. If it is impossible to reach the Web GUI then it is impossible to login. The key takeaway from the above information is that SSO Admins cannot have Trusted Hosts configured directly, yet affected by Trusted Hosts (especially when Trusted Hosts are configured on all Local/REST API Admins). This can be problematic if the SSO Admin accounts are meant to log in from different source subnets than the Local/REST API Admins. Consider the following example scenario: An MSP has configured several Local Admin accounts used to manage a user's FortiGate. These Local Admins all have Trusted Hosts applied that allow the MSP to manage the FortiGate using their management subnet accessible via an IPsec tunnel. Any attempts to log in to the FortiGate from a source outside of this management subnet will be dropped. The user then requests that SAML-based SSO be added to the FortiGate so that it is possible to have read-access from the corporate LAN. Since the SSO Admin accounts cannot have Trusted Hosts configured (and since the MSP does not allow the Local Admin accounts to be accessed outside of the management subnet), the user is unable to receive the login prompt in the Web GUI and it is not possible to sign into the SSO Admin account. Recommendation: If Trusted Hosts needs to include a source subnet for SSO Admins that are not needed/wanted for other Local/REST API Admins, then the solution is to create an additional Local Administrator account that has Trusted Hosts configured but no actual administrative access to anything (i.e. a 'dummy' account). The general steps to do this are as follows: Create an Admin Profile (System -> Admin Profile) with all Permissions set to None. A name like 'no-access' can be appropriate here. If VDOMs are being used then set the Scope to either Global (profile applies to all VDOMs) or Virtual Domain (Admin account must specify which VDOMs it can access). Create a 'dummy' Local Administrator account (System -> Administrators) and assign the 'no-access' Administrator Profile here. The password and username are not important here since the account has no access to anything on the FortiGate. Nevertheless, setting a long, random password here is a good idea. Configure Trusted Hosts (enable Restrict login to trusted hosts) and add the source subnets/addresses that the SSO Admin will access the FortiGate from. With this arrangement, the 'real' Local Admin accounts can only be logged into when coming from the specified Trusted Hosts, but SSO Admins are still able to reach the Web GUI to initiate a SAML-based login attempt.