Connecting the world…


FortiGate – OnDemand Token Timeout

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.

ClearPass & MobileIron – Error: not well-formed (invalid token)

This post isn’t going to describe what HPE Aruba ClearPass or MobileIron is. And neither will it describe the configuration steps necessary to add MobileIron to ClearPass, but I will give a short summary:

  1. Add the MobileIron VSP to ClearPass as Endpoint Context Server (CPPM – Administration – External Servers);
  2. The account on MobileIron needs API rights to enable ClearPass to retrieve information from MobileIron;

This post tells a bit more about an error message I suddenly started to receive in the CPPM Eventy Viewer.

CPPM - MDM - invalid token

Error: not well-formed (invalid token)

I checked the internet, but I couldn’t find any useful information. I opened a TAC case to look into this error. The TAC engineer told me he had seen this error before, where MobileIron sends invalid token characters to ClearPass. He told me that CPPM does batch processing of the devices and the entire batch fails when CPPM doesn’t understand special characters. He also told me how to see which device is causing the problem.

You have to collect the CPPM logs (CPPM – Administration – Server Manager – Server Configuration – Collect Logs). After you untar the tar.gz file, you should look at the directory “strange string”\PolicyManagerLogs\mdm\MI\mdm-server and you should open the file 0.xml.bak.

Scroll down to the line mentioned in the error message and you will see something like below. I always use Notepad++ to open the file.


CPPM doesn’t understand these special characters in the key. When you start scrolling up, you can determine which device in MobileIron triggers the error message in CPPM.

After I found the device in MobileIron I checked every setting on the device to find the special character, but I couldn’t find one. In the end there was only one solution for me: retire the device. This basically means remove the device from MobileIron and the user needs to reprovision the device in MobileIron. The sync between CPPM en MobileIron was successful again after I retired the device.

Tip of the week: I guess you aren’t always looking at the Event Viewer for errors, so maybe it is useful to configure ClearPass Insight to send a notification if a System Error Event occurs!!!

RSA AM 7.1SP3 Token Delivery

Using two-factor authentication is common when publishing remote services to the internet with components like Citrix NetScaler or Juniper SA appliances. RSA is a well-known provider of two-factor authentication mechanism.

Beginning with RSA Authentication Manager 7.1 people have the ability to use the On-Demand feature. This feature enables the delivery of token codes via SMS or e-mail. When using this feature you had to publish the RSA Self-Service website to the internet, so users can request a token code. The RSA Self-Service website is displayed below.


The procedure for opening a extra website to request an On-Demand token is difficult to understand for many people and increases the risk of problems and errors during the authentication process.

This behavior is changed in RSA AM 7.1SP3. With SP3 the Authentication Agent has possibility to generate the On-Demand token request on behalf of the user. The procedure to login to the Authenticaton Agent is:

  1. 1. Browse to the portal website
  2. 2. Enter your user credentials (username + password)
  3. 3. Enter only the token PIN code
  4. 4. The Authentication Agent generates the On-Demand token request and redirects the user to a website to enter the On-Demand token code
  5. 5. The user waits for the delivery of the token via SMS or e-mail
  6. 6. The user enters the On-Demand token code on the Authentication Agents website
  7. 7. The Authentication Agent validates the token code and displays the web portal

This way the delivery of token codes is less prone to problems and errors during the authentication process. I personally like this new feature.

RSA 7.1 with On-Demand

RSA token security provides a way to strengthen the security on public services. Token authentication is most often implemented with hardware tokens. RSA 7.1 has additional methods of token authentication besides the hardware tokens:

  • Token delivery by SMS;
  • Token delivery by e-mail;

To enable the above features you have to install at least RSA 7.1 and obtain a On-Demand license, like shown below:


Next I will show you how to configure token authentication for the delivery of tokens through SMS and e-mail. My test environment contains a RSA Authentication Manager 7.1 with RADIUS server installed on a Windows 2003 R2 server under VMware. The RSA server has a LDAP mapping to Active Directory for authenticating users.


The first method explained is configuring RSA to deliver tokens to an e-mail address. The first step is configuring a SMTP server on the RSA server. In this scenario I create a SMTP connection to a Windows Exchange 2003 server. rsa-od-mailIn the Security Console, navigate to Setup – Instances and edit the instance you would like to use for the SMTP connection.

In the SMTP setup you need to configure the Hostname of the SMTP server and a “from” e-mail address. Some SMTP servers require authentication to use them as relay server. If your SMTP server requires authentication you can configure the appropriate user credentials. In my situation I only need to deliver mail to the domain, so I don’t need to configure authentication or assign relay rights to the RSA server on the Exchange server. If you would like to deliver e-mail to domains outside your mail environment, you have to configure authentication or relay access for the RSA server.

rsa-od-ena-mail After configuring the SMTP server you have to enable the ability to deliver token codes by e-mail. Navigate to Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes in the Security Console. Enable the option “Delivery by E-mail” and choose the User Attribute to Provide E-mail Destination. This User Attribute is obtained by default through LDAP. In my scenario I use the e-mail field within Active Directory to obtain the specific e-mail address from a user.

rsa-od-user-mail From now on you can enable the usage of e-mail token delivery to your users. To accomplish this navigate to Identity – Users – Manage Existing and search for a specific user. Go to Security Tokens for the specific user and enable “On-Demand Tokencodes” and the specific settings, like shown in the picture. I configured an initial PIN for the user. The user should be able to obtain a token code through SMS via the Self-Service console. This portal can be reach via the URL: https://<ip address / FQDN RSA server>:7004/console-selfservice.

On-Demand token codes have a PIN code associated to the delivered token code. This PIN code is different from the PIN code of normal hardware tokens. I normally enable the On-Demand feature for a user and specify the first initial PIN code. After the user logs in with this PIN code, the PIN code needs to be changes. There are two ways of doing this:

  1. The user automatically receives a new PIN code, which is generated by the RSA server;
  2. The user has the option to manually specify a new PIN code;

rsa-od-token-policy Most often system engineers let the customers choose there own PIN code. Toggling between both settings is possible by changing the Token Policy. Changing the Token Policy is possible by navigating to Authentication – Policies – Token Policies.


To configure SMS token delivery you need some kind of method to send SMS messages. RSA and Clickatell have partnered to enable delivery of SecurID tokencodes to mobile devices via SMS/text. RSA Authentication 7.1 has a build-in method for delivering SMS messages through Clickatell. Click here to obtain more info about the partnership between RSA and Clickatell and how to register a (trial) Clickatell account.

The first step is to link a User Attribute from the Active Directory to RSA. This User Attribute contains the phone number for delivering the SMS. To such link navigate to Identity – Identity Attribute Definition – Add New.


Within Active Directory you can configure multiple Telephone numbers for a user. Because the SMS is sent to the users mobile phone, I enter the appropriate phone number under the mobile Telephone number of the users.

The picture shows how to configure the the User Attribute mapping. The Attribute Name is a user friendly name to identify the mapping. I choose Personal as Category and the Entry Type is optional. The users mobile phone number is displayed under Personal when editing the user.

The Identity Source Mapping defines the LDAP attribute to use for obtaining the mobile phone number from the user. This value has to be exactly the same as the LDAP value for the mobile phone number in Active Directory. I use Softerra’s LDAP browser to obtain this value from Active Directory. Softerra LDAP browser is a useful tool for browsing LDAP directories.


The configuration of the SMS service provider can be found under Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes.

You need to enable the option “Delivery by SMS”, choose the previously configured User Attribute, select your country code and provide the credentials for your Service Provider.

You can now switch between token code delivery by e-mail and SMS. A user has the option to choose the preferred delivery method via the Self-Service console. Users need access to the Self-Service console to request a token code. The Self-Service portal needs to be securely published to the internet. This can be achieved by using a reverse proxy or some comparable solution. The following PDF contains a quick howto for publishing the RSA environment securely to the internet.