Technical Tip: Create a 'break glass' admin account on the FortiGate as a backup for remote authentication/MFA (Recommendation)

[pjang]

Description	This article discusses the concept of a 'break glass' administrator account, as well as some reasons for why admins should configure one on the FortiGate. This article also discusses some general risks to keep in mind when using more advanced authentication methods (e.g. remote authentication protocols and multi-factor authentication).
Scope	FortiGate
Solution	By default, the FortiGate comes pre-configured with a single local administrator account configured with the super_admin profile. This is generally used for first-time setup, and for smaller environments, it may remain in active usage along with some other local administrator accounts. However, larger environments often integrate remote authentication protocols like LDAP, RADIUS, and SAML for usage with admin access to the FortiGate. This can be beneficial since it eases credential management and allows organizations to reuse their existing centralized authentication sources (Active Directory, Microsoft Entra, etc.) On top of this, it is very common for organizations to further secure their infrastructure by mandating the usage of multi-factor authentication (MFA) for administrator access. MFA can be delivered in various ways including push notifications, SMS/email tokens, and Time-based One Time Passcode (TOTP) token solutions including FortiToken Mobile. Potential Risks to Consider for Advanced Authentication: While remote authentication and MFA should still be used, they do introduce a new risk where admin logins now require multiple components to function correctly. Here are some potential points of failure to keep in mind for remote authentication and MFA when compared to local authentication on the FortiGate: Remote authentication protocols like LDAP, RADIUS, and TACACS+ require the FortiGate to be able to send local-out traffic to the remote servers. If network access is lost for some reason (for example, an IPsec VPN tunnel back to the main datacenter goes down, or routing issues occur that cause traffic to be dropped or misrouted), then administrator accounts based on these services will not be able to log into the FortiGate. It is possible to configure a backup password for this use case, but only if individual admin accounts are created. rather than wildcard groups (i.e. 'Match a user on a remote server group', not 'Match all users in a remote server group'). SAML is a slightly different case since the client is the one initiating connections to the SAML SP and IdP. In this case, if the client cannot reach the IdP for some reason then authentication will fail. In-general, misconfigurations/changes on the FortiGate configuration related to remote authentication can inadvertently break access to these services and cause similar problems to what has been described above. For TOTP MFA tokens, the main concern is if the device holding the token is lost and there are no backups available (e.g. if FortiToken Mobile is deleted, or if an administrator's smartphone carrying the token is lost). For FortiToken Cloud in particular, there is an additional reliance on network connectivity as the FortiGate must be able to actively communicate with FortiToken Cloud over the Internet; otherwise, the login attempt will fail. Push notifications are generally low-risk since they typically supplement manual token code entry, though this is not always true. The inability to reach the push notification network (typically Google/Apple servers for Android and iOS respectively) to receive/accept the notification would be a potential problem here. For external token services (such as email and SMS) the main concern would be if the services are unavailable for some reason, either due to functional reasons or license-related reasons. For example, FortiToken Cloud offers SMS-based MFA via a usage-based license (i.e. one SMS message consumes X credits). If the pool of credits are fully-consumed then any additional SMS notifications will fail, which means that any authentication that utilizes SMS-based MFA will also fail until the license is topped up (see also: FortiToken Cloud Admin Guide - FAQ). Likewise, any issues with email servers (such as the FortiGate being blocked when attempting to send email tokens to users) will have a similar impact for authentication attempts. As a reminder, older FortiOS versions used to support a feature called the Maintainer administrator account, which could be used to log in to the FortiGate and reset passwords. However, this feature has been removed as of FortiOS 7.2.4, 7.4.0, and all later versions, and so it is no longer a backup method of access for administrators (see also: Technical Tip: Removal of maintainer account feature). 'Break Glass' Admin Account: Given the potential points of failure mentioned above, admins should have a contingency in-place that allows for admin access to the FortiGate even in the absolute worst scenarios (such as a network-down event). This is especially true in scenarios where the cause of the problem lies on the FortiGate (and so admins must be able to log into the FortiGate to take corrective action). To address this, administrators may consider configuring a 'break glass' administrator account, which is a type of highly privileged account that is only ever used in emergencies. This account should generally have the following traits: It should be a Local account on the FortiGate so that there is no reliance on remote authentication services (i.e. it can function even if the FortiGate is fully disconnected from the network). The account must have the super_admin profile applied to it (full administrative privileges are required for many key functions, such as modifying other super_admin accounts or having access to fix any configuration section). It should not have multi-factor authentication associated with it (e.g. no FortiToken Mobile or other MFA solution) since losing access to the MFA will prevent this account from being usable. However, because there is no MFA, a very strong password should be used instead (e.g. a pseudorandom password made of upper/lower-case characters, digits, and special characters). FortiGate administrator passwords may be up to 64 characters long. If a password-policy with password expiry is configured, a password management plan should be maintained to periodically update the credentials for the break-glass account. Alternatively, 'password-expire' can be unset for the account after it is created to exempt it from password expiry. config system admin edit <administrator_account> unset password-expire next end The credentials must be stored safely and securely, either physically (e.g. in a safe) and/or cryptographically (in an encrypted password manager). These credentials should also be generally restricted in terms of which members of the organization have access to them in the first place (i.e. privileged credentials should be restricted to a small handful of staff members). At the same time, it should be made clear to other members of staff (within certain teams) that these credentials do exist; otherwise, access to the FortiGate may be delayed unnecessarily during an emergency (for example, staff members not knowing that this is an option). For additional security, consider applying Trusted Hosts to this break-glass account to restrict the Source networks from which it may be used. A simple option would be to limit access to the RFC1918 IPv4 private subnets (e.g. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). A more restrictive option would be to set either a limited set of individual allowed IP addresses or to solely specify a 'dummy' subnet that cannot feasibly be used as a Source address (such that the account is only usable for serial console-based logins, which require some degree of physical access to the FortiGate). Recovering access when authentication is not available: If administrative access to the firewall is lost and cannot be recovered through other means such as a break-glass account, restoring access requires a factory reset (for smaller devices with a reset button) or TFTP format and firmware load to return the device to factory configuration. See the article Technical Tip: Formatting and loading FortiGate firmware image using TFTP for an example of performing a TFTP firmware load. After restoring factory configuration, an administrator must then apply a known good configuration backup or reconfigure the firewall manually to restore functionality. Something to consider is that a recent configuration backup for the FortiGate may be available, but it might still have the same (unknown) credentials as before. To avoid being locked out of the FortiGate again, one option is to manually modify the configuration and change the passwords for at least one administrator account before it is restored to the FortiGate. To do this, use the following general procedure: Create a copy of the configuration backup, then open the new copy in a text editor and search for the string 'config system admin'. Locate the administrator account entry (for example 'admin'), then locate the 'set password' setting within its configuration block. Select and delete the text from 'ENC' all the way to the end of the line (which will include the original encoded password), then type in a replacement temporary password. Take into consideration other factors that can limit admin access to the FortiGate, such as Trusted Hosts. If necessary, these lines can be deleted; otherwise, ensure that any admin connections to the FortiGate are sourced from an IP address that is within the Trusted Hosts list. Save the changes, then restore the configuration to the FortiGate. It will now be possible to login to the FortiGate using the new password, and that new password will be encrypted in subsequent configuration backups. Make sure to change this password after restoring the configuration and confirming that admin access to the FortiGate is working correctly. Example (before): config system admin edit 'admin' [output redacted] set password ENC <Long_Encrypted_Password> next Example (after): config system admin edit 'admin' [output redacted] set password secretpass123 << note the lack of 'ENC' next Related documents: Local authentication Remote authentication for administrators Hardening