I created some Python scripts for ClearPass. The scripts can be found on Github. There are several directories:
- config: contains the parameters to authenticate against ClearPass and acquire an access token;
- general_scripts: some general configuration scripts, like a Password Generator script or Date/Time script;
- guests: scripts for adding or deleting guest accounts. I created a script to add guest accounts via a CSV file and print the most important information to a Guest Pass in Word format;
- localusers: scripts for adding or deleting local user accounts;
First of all, I would like to thank Tim Cappalli for the ClearPass Authentication scripts!!
A special thanks to Tim Cappalli for the ClearPass Authentication scripts!!
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.