Administration
Configure administrative settings for the FortiAuthenticator device. This section includes: l GUI access
- High availability l Firmware l Automatic backup
- SNMP
- Licensing l FortiGuard l FTP servers
- Administrator profiles
GUI access
To adjust GUI access settings, go to System > Administration > GUI Access. The Edit GUI Access Settings page will open.
The following settings are available:
Idle timeout | Enter the amount of time before the GUI times out due to inactivity, from 1 to 480 minutes. |
HTTPS Certificate | Select an HTTPS certificate from the drop-down list. |
Certificate authority type | Select the selected certificate’s authority type, either Local CA or Trusted CA. |
CA certificate that issued the server certificate | Select the issuing server certificate from the drop-down list. |
Additional allowed hosts/domain names | Specify any additional hosts that this site can serve, separated by commas or line breaks. |
Select OK to apply any changes. See Certificate Management on page 132 for more information about certificates.
High availability
Multiple FortiAuthenticator units can operate as a cluster to provide even higher reliability, called HA.
There are three HA roles:
- Cluster member l Standalone master l Load-balancing slave
The FortiAuthenticator can operate in two separate HA modes:
- Cluster : Active-passive clustered fail-over mode where all of the configuration is synchronized between the devices. l Load-balancing: Active-active HA method in which one device acts as a standalone master with up to two additional, geographically separated load-balancing slaves. The load can be distributed across the devices using round-robin DNS, Auth/NAS client load distribution, or external load balancing devices. Load-balancing mode is intended for two-factor authentication deployments, as only a subset of the configuration is synchronized between the devices.
Both HA modes can be combined with a HA cluster acting as a standalone master for geographically distributed load-balancing slaves.
If a HA cluster is configured on an interface (such as port 2) and then disabled, it will not be possible to re-enable HA.
This is because, when disabled, the interface’s IP address is reconfigured to the interface to allow the administrator to access the newly standalone device. To allow the port to be available for use again in a HA cluster, the IP address must be manually removed.
Cluster member role
In the cluster member role, one unit is active and the other is on standby. If the active unit fails, the standby unit becomes active. The cluster is configured as a single authentication server on your FortiGate units.
Authentication requests made during a failover from one unit to another are lost, but subsequent requests complete normally. The failover process takes about 30 seconds.
Cluster mode uses Ethernet broadcasts through TCP port 720 as part of its master/slave election mechanism and for ongoing communication. Layer 2 connectivity is required between the two devices in a HA cluster, preferably via a crossover cable, as some network devices might block such Ethernet broadcasts.
To configure FortiAuthenticator HA
- On each unit, go to System > Administration > High Availability
- Enter the following information:
Enable HA | Enable HA. |
Role | Select Clustermember. |
Interface | Select a network interface to use for communication between the two cluster members. This interface must not already have a IP address assigned and it cannot be used for authentication services. Both units must use the same interface for HA communication. |
Cluster member IP address | Enter the IP address this unit uses for HA-related communication with the other FortiAuthenticator unit. The two units must have different addresses.
Usually, you should assign addresses on the same private subnet. |
Admin access | Select the types of administrative access to allow from: Telnet, SSH, HTTPS, HTTP, and SNMP. |
Priority | Set to Low on one unit and High on the other. Normally, the unit with High priority is the master unit. |
Password | Enter a string to be used as a shared key for IPsec encryption. This must be the same on both units. |
- Select OK to apply the settings.
When one unit has become the master, reconnect to the GUI and complete your configuration. The configuration will automatically be copied to the slave unit.
Standalone master and Load-balancing slave roles
The load-balancing HA method enables active-active HA across geographically separated locations and layer 3 networks. Only the following authentication related features can be synchronized:
l Token and seeds l Local user database l Remote user database l Group mappings l Token and user mappings
Other features, such as FSSO and certificates, cannot be synchronized between devices.
The standalone master is the primary system where users, groups, and tokens are configured. The loadbalancing slave is synchronized to the master.
To improve the resilience of the master system, an active-passive master cluster with up to two load-balancing slave devices can be configured.
To configure load-balancing HA
- On each unit, go to System > Administration > High Availability
- Enter the following information:
Enable HA | Enable HA. |
Role | Select Standalone master on the master device, and Load-balancing slave on the slave device or devices. |
Password | Enter a string to be used as a shared key for IPsec encryption. This must be the same on both units. |
Load-balancing slaves | On the master, enter IP address or IP addresses of the load-balancing slave devices. Up to two can be added. |
- Select OK to apply the settings.
Administrative access to the HA cluster
Administrative access is available through any of the network interfaces using their assigned IP addresses or through the HA interface using the ClustermemberIP address, assigned on the System > Administration > High Availability page. In all cases, administrative access is available only if it is enabled on the interface.
Administrative access through any of the network interface IP addresses connects only to the master unit. The only administrative access to the slave unit is through the HA interface using the slave unit’s ClustermemberIP address.
Configuration changes made on the master unit are automatically pushed to the slave unit. The slave unit does not permit configuration changes, but you might want to access the unit to change HA settings, or for firmware upgrades, shutdown, reboot, or troubleshooting.
FortiAuthenticator VMs used in a HA cluster each require a license. Each license is tied to a specific IP address. In a HA cluster, all interface IP addresses are the same on the two units, except for the HA interface. Request each license based on either the unique IP address of the unit’s HA interface or the IP address of a non-HA interface which will be the same on both units.
If you disable and then re-enable HA operation, the interface that was assigned to HA communication will not be available for HA use. You must first go to System > Network > Interfaces and delete the IP address from that interface.
Restoring the configuration
When restoring a configuration to a HA cluster master device, the master will reboot and in the interim the slave device will be promoted to master. When the previous master returns to service, it will become a slave and the existing master will overwrite its configuration, defeating the configuration restore. To avoid this, use the following process when restoring a configuration:
- Shutdown the slave unit.
- Restore the configuration on the master unit.
- Wait until the master unit is back online.
- Turn on slave unit — it will synchronize to the restored configuration after booting up.
Have you seen FortiAthenticator or Fortigate, for that matter, configured to utilize a third-party sms authentication (i.e. SMSGlobal) for on-boarding a guest wireless user?
Our Wireless is third-party as well and not managed by Fortigate.
We want to required the guest wireless user to enter their phone #, then in turn, receive a sms message with a passcode that they would enter to complete the on-board process.
Lots of companies facilitate the SMS piece, however, If it integrates with either the Fortigate or FortiAuthenticator, then I am missing something.
Thanks!!
We have configured FortiGates to utilize other SMS providers (mostly verizon) for 2FA / authentication means.
Are you referring to 2FA onto the Fortigate itself?
This particular article is discussing the FortiAuthenticator which is a separate Appliance / VM for authentication needs
we have two fortiauth VMs, we tried to create HA with primary-slave configuration. the issue we were facing that primary fac can see the peer device on it with the error message cluster not formed but on slave unit it is not showing any peer device, on cluster status it is showing cluster is formed but in peer device section it is showing it is not.
by help of TAC we could find out that the heart beet can be seen on the primary FAC by the slave FAC but the HA heatbeat cannot be reached to primary FAC from slave.
Primary FAC VM is on ESXi server which is connected to cisco fabric switch > cisco core switch > other side fabric switch > slave FAC VM on other side ESXi server.
we did assign separate vlan for HA connectivity and that vlan is been configured on fabric switch as well as the core and it is L2 only. so nothing is blocking the heartbeat broadcast in between these two FACs and no firewall in between as well. Do you have any idea what would be the cause of this issue?