Today’s customer is having a problem with OnDemand tokens on a FortiGate firewall. The FortiGate firewall uses RADIUS authentication for SSL VPN user authentication. FortiAuthenticator is used as RADIUS server. To strengthen the security levels, FortiAuthenticator is configured to demand two-factor authentication (2FA) for successful authentication. FortiAuthenticator has multiple options to demand 2FA from a user, like hardware FortiTokens, FortiToken Mobile or mail or SMS services.
Problem with the latter two could be timeouts. By default, FortiAuthenticator expects the token code after 60 seconds. This value is customizable.
However, only changing the timeout in FortiAuthenticator isn’t enough, because FortiGate has its own timeout value too. So you need to change this value if you would like to increase the time between entering username/password and token code. The timers are configurable via the CLI in “system global”
two-factor-email-expiry: Email-based two-factor authentication session timeout (30 – 300 seconds (5 minutes), default = 60).
two-factor-fac-expiry: FortiAuthenticator token authentication session timeout (10 – 3600 seconds (1 hour), default = 60).
two-factor-ftk-expiry: FortiToken authentication session timeout (60 – 600 sec (10 minutes), default = 60).
two-factor-ftm-expiry: FortiToken Mobile session timeout (1 – 168 hours (7 days), default = 72).
two-factor-sms-expiry: SMS-based two-factor authentication session timeout (30 – 300 sec, default = 60).
In this particular case, I changed the two-factor-fac-expiry setting to match the setting on FortiAuthenticator.
The script is used to execute a CLI command on one or multiple switches. The script use switches.txt as input file to login to one or multiple switches. When the scripts is executed the script asks for username and password and which command to execute. The status codes of the different sections is displayed and the output from the CLI command is send to file. The file name syntax will be SW<IP>_<sw hostname>_<cli command>.txt
- create switches.txt and add the switch IP address – one IP address per line
- execute the Python script
- the script is test with:
- python 3.6
- Aruba JL258A 2930F-8G-PoE+-2SFP+ Switch
- Software revision WC.16.05.0004
One of the features I would like to see in a FortiGate is the ability to automatically create backups and copy them to offline storage. Of course, this can be accomplished by adding FortiManager to the solution, but why would I need FortiManager if I only have one FortiGate (cluster). Another option would be using scripts, like Python or PowerShell, with scheduled tasks on servers to pull a backup from the FortiGate firewalls.
A very basic option would be the usage of system auto-script in FortiOS 5.4 and higher. Use this command to create CLI command scripts that can be saved and run. This gives you the possibility to auto-script the execute backup full-config commando. A disadvantage of this command is that you only have the option to use (T)FTP. There is no option to use a secure protocol like SFTP.
An example of an auto-script:
The example executes the backup command and sends the backup via TFTP to the TFTP server. The script runs every 24 hours (86400 seconds). It repeats infinite and starts automatically.
The script can also be configured via the GUI (Global >> System >> Advanced >> Configuration Scripts). More information about the feature can be found here.
Something completely different: changing the SSL certificate on MobileIron Core and Sentry. In total, I had to replace 5 certificates. 4 certificates are replaced via the Core web interface and 1 certificate needs to be replaced via the Sentry web interface.
Within the Core web interface you have to change the certificated in two separate interfaces.
1. Login to the Core web interface and choose Services >> Sentry
2. Choose the icon (person’s head) in the upper right corner >> System Manager. Log in to the System Manager website and choose Security >> Certificate Mgmt
Log in to the Sentry web interface and choose Security >> Certificate Mgmt
The process of replacing the certificate is the same for all 5 certificates. You only need to be careful to upload the correct certificates. In my situation, users are connecting to two different FQDNs. One FQDN is pointing to the Core and is used to sign in to MobileIron and register a device. The second FQDN points to Sentry and is used for client connections from the mobile device, like Outlook Sync or Web@Work. I upload the certificate with the Sentry FQDN to the Sentry option on the Core web interface and within the Sentry web interface and I upload the Core certificate within the Core System Manager web interface.
I am using a certificate based on a full FQDN, so no wildcard certificate. The certificate’s certificate path contains two intermediate certificates and one root certificate. In total I have 5 different files:
- a signed certificate from the CA
- the private key
- the first intermediate certificate
- the second intermediate certificate
- the root certificate
I upload all certificates separately when choosing Manage Certificate like shown in the image.
Hit Upload Certificate when you choose all the necessary files. MobileIron starts uploading the certificates, is “smart” enough to combine all certificates, replaces the certificate for the specific service and restarts the service. This could result in a short interruption of production. After this, the SSL certificate is successfully replaced.
I had to provision some AP324 APs on a standalone Aruba Mobility Controller. The controller runs AOS 220.127.116.11 code and functions as standalone controller. So what could be a problem when provisioning an AP324 via the GUI??? Well during the provisioning I couldn’t choose the desired custom AP group. I can only choose from both default AP groups: default and NoAuthApGroup.
Hhhhmmm, what could be the problem? I created a new AP group with default settings and even changed the settings from my custom AP group to match the settings from the default AP group, but still no option. So I guess this is some kind of bug in the 18.104.22.168 code……..
Eventually I configured the AP via the CLI to get it provisioned in the correct AP group with the correct parameters and that is working fine. Remember: the AP324 is an AP with external antennas so you need to configure the antenna gain during the provisioning. The exact value of the antenna gain can be found in the data sheet. I used the CLI configuration below to provision the AP.
# clear previous provisioning ap list
# enter config mode and configure parameters
provision-ap read-bootinfo ap-name a8:bd:27:cc:50:8e
provision-ap installation indoor
provision-ap a-ant-gain 5.8
provision-ap g-ant-gain 3.8
provision-ap ap-group my-ap-group
provision-ap no syslocation
provision-ap no remote-ap
# view the configured parameters
# provision the AP
provision-ap reprovision ap-name a8:bd:27:cc:50:8e
# clear provision list and parameters
The AP is configured with the correct parameters, which can also be verified from the GUI….