Description
This article describes how the FortiToken Push feature works with FortiAuthenticator and Apple/Android-based devices, the configuration requirements, and the workflow on FortiAuthenticator when a user authenticates.
Useful link: FortiAuthenticator Admin Guide.
Scope
The following products and versions does support PUSH notifications for FortiToken Mobile tokens:
- FortiAuthenticator since version 4.2.0 and above.
- FortiToken Mobile app since version 4 and above.
- FortiGate / FortiOS since version 5.6.0 and above.
Solution
In cases where PUSH token notifications are desired as less complicated way to use two-factor authentication via FortiToken Mobile tokens, a setup needs to be done on FortiGate (or a 3rd party device capable of RADIUS Access-Challenge), pointing to FortiAuthenticator as the RADIUS server.
This article describes and focus on FortiAuthenticator as the token handler and so push notification originator, however note that FortiGate is also able to handle push notifications (even without FortiAuthenticator) for users provided with FortiToken Mobile token if set properly.
In the process of activating a token, note that also the phone must be capable of push notifications.
Even any 3rd party devices, if able to handle RADIUS Access-Challenge, can utilize FortiAuthenticator and via that FortiAuthenticator became "capable" to handle two-factor authentication with PUSH notifications as a bonus.
FortiAuthenticator (or FortiGate) do not send a push message directly to the phone causing the popup, but they will contact a Fortinet service as proxy, called 'push.fortinet.com', which interfaces and interacts with the Apple and Google Notification Services.
FortiAuthenticator (or FortiGate) will send a message to a unique device identifier 'registration ID' that is known on the Apple or Google services. With this, the vendors can send a push message through the existing connection that is already present and initiate the push popup displayed on specific mobile device.
That implies that the phones are capable of registering at these services on activation of the token. iPhones would be less affected by it, but Android phones might have implementations where the phone isn't shipped with Google Play Services Framework (GSF), or nowadays also known as Firebase. In these cases, push notifications will not work for those phones.
In FortiOS, use a user group with the RADIUS server object as a member and the FortiAuthenticator configured as a RADIUS server entry.
In this scenario, users are handled and exist on FortiAuthenticator, which also handles all the tokens. And FortiGate is simple NAS, a RADIUS client, sending authentication requests to FortiAuthenticator.
Any 3rd party RADIUS client (NAS) needs the same settings enabled on FortiAuthenticator.
And again, FortiAuthenticator is the centralized authentication point handling all the users and tokens here.
The following needs to be configured on FortiAuthenticator (Setup):
- Enable push notification in RADIUS settings.
In older versions: 'Authentication -> Radius Service -> Clients'.
The profile for the client system must have the 'Enable FortiToken Mobile push notification authentication' activated. Otherwise, FortiAuthenticator will not send push notifications to Apple/Android servers.
In newer versions: 'Authentication -> Radius Service -> Policy'.
The RADIUS policy needs to have push notifications enabled in the tab 'Authentication factors' under 'Advanced Settings' (this should be the case by default).
- Ensure push reply can reach FortiAuthenticator.
'System -> Administration -> System Access'.
Here, the 'Public IP/FQDN for FortiToken Mobile' can be set to a public IP and port.
This is NOT the IP and port combination set on FortiAuthenticator itself; this is the public IP/FQDN to which the push reply should be sent.
In cases where the FortiAuthenticator is behind the NAT device, this setting makes the FortiAuthenticator aware of the public IP and port used by the NAT device to translate into the FortiAuthenticator IP and port.
FortiAuthenticator will include this setting as a reply-to address in the push notification, so the FortiToken mobile app knows where to send the reply.
For example: a NAT device has VIP/port-forwarding, or a similar feature, configured with public IP 3.3.3.3 and port 34443. FortiAuthenticator’s actual interface port1 has 192.168.1.99:443. Set this Public IP and port to 3.3.3.3:34443 to ensure proper communication according to the aforementioned translation.
Note:
If FortiAuthenticator is connected directly to the Internet, this setting is not necessary as FortiAuthenticator is reachable itself and there is no NAT translation in the middle: the reply will be sent to the FortiAuthenticator's outgoing interface IP.
- Enable push notifications on the interface.
The destination interface on FortiAuthenticator where the traffic arrives (as port1 with 192.168.1.99 in the above example),
has to have 'FortiToken Mobile API (/api/v1/pushauthresp, /api/v1/transfertoken)' enabled.
This can be set under 'System -> Network -> Interfaces' select and edit the appropriate interface.
With this configuration, FortiAuthenticator is primed for push notifications.
It is now up to the client to initiate push notifications.
The process is as follows:
- RADIUS client (NAS, FortiGate in our case) initiates RADIUS authentication with a user that has a FortiToken Mobile assigned on FortiAuthenticator.
- FortiAuthenticator checks the authentication via the RADIUS policy and discovers the token.
- FortiAuthenticator sends back a RADIUS Access-Challenge and includes this message:
'+Please enter the token code. It is also possible to submit a blank response to initiate a push notification to the FortiToken Mobile app.'- If the RADIUS client is a FortiGate/FortiManager/FortiAnalyzer:
FortiGate/FortiManager/FortiAnalyzer parses the message and observes the leading '+' sign; this indicates push notification is being offered in this context. The client replies automatically to initiate a push, with no user input required. However, FortiGate (FortiClient in tunnel-based VPN), FortiManager, or FortiAnalyzer also offer an input field for the actual token code. - If the RADIUS client is a different Fortinet product or third-party product:
The user will need to submit an empty code or type 'push' in the token field and submit this, to have FortiAuthenticator trigger a push notification.
- If the RADIUS client is a FortiGate/FortiManager/FortiAnalyzer:
- Optionally: The user can, instead of accepting the push notification, also simply enter the token code. FortiAuthenticator should receive this as another Access-Request, and accept the token code even if push notification has been initiated. This option might not be available if a user actively triggers a push notification by sending an empty code or typing in 'push'.
Once FortiAuthenticator is prompted for push notification, the following represents a workflow of the notification being sent:
- FortiAuthenticator looks up the actual IP address (A) of the notification server push.fortinet.com
- FortiAuthenticator then contacts the returned IP and starts a TLS handshake with the selected server. An encrypted communication, signed by certificates, is then established between FortiAuthenticator and the push server.
- Notification data is sent Fortinet push server, containing details about the recipient (particular mobile device), timestamp, session_id, etc.
This is trackable in FortiAuthenticator /debug/push-service-worker/ debug output.
Example:
2019-07-30 14:59:10,212 - Worker[Thread-72][140166871250688] - debug - {'username': u'testoken', 'account': u'', 'realm': u'local', 'timestamp': '2019-07-30 14:59:05', 'use_sandbox': False, 'session_id': '12397af3dff3409f81da668b2b158a18', 'user_ip': u'', 'user_agent': u'RADIUS_CLIENT', 'push_server': u'', 'log_message': u''}
2019-07-30 14:59:11,890 - Worker[Thread-72][140166871250688] - information - Pushed 12397af3dff3409f81da668b2b158a18-testoken to remote server.
The highlighted session_id can be also tracked in /debug/radius/ on FortiAuthenticator:
2019-07-30T16:59:15.172624+02:00 C4 radiusd[26836]: ===>Username:testoken
2019-07-30T16:59:15.172633+02:00 C4 radiusd[26836]: ===>Timestamp:1564498755.172182, age:0ms
2019-07-30T16:59:15.172641+02:00 C4 radiusd[26836]: Setting 'Auth-Type := FACAUTH'
2019-07-30T16:59:15.172649+02:00 C4 radiusd[26836]: [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.
2019-07-30T16:59:15.172657+02:00 C4 radiusd[26836]: # Executing group from file /usr/etc/raddb/sites-enabled/default
2019-07-30T16:59:15.172665+02:00 C4 radiusd[26836]: This is a response to Access-Challenge
2019-07-30T16:59:15.172673+02:00 C4 radiusd[26836]: Trying to find FTM push auth user: testoken session_id: 12397af3dff3409f81da668b2b158a18
2019-07-30T16:59:15.172681+02:00 C4 radiusd[26836]: Partial auth user found
2019-07-30T16:59:15.172688+02:00 C4 radiusd[26836]: Successfully found partially authenticated user instance.
2019-07-30T16:59:15.173492+02:00 C4 radiusd[26836]: Switch to the original request from 10.109.19.9 id=90 to continue FTM push auth
2019-07-30T16:59:15.176191+02:00 C4 radiusd[26836]: Update lastgood/drift successful
2019-07-30T16:59:15.176211+02:00 C4 radiusd[26836]: Authentication OK
2019-07-30T16:59:15.176633+02:00 C4 radiusd[26836]: Setting 'Post-Auth-Type := FACAUTH'
2019-07-30T16:59:15.180537+02:00 C4 radiusd[26836]: Add Radius attribute: 809762817, LOCALS
2019-07-30T16:59:15.185150+02:00 C4 radiusd[26836]: Updated auth log 'testoken': Local user authentication with FortiToken successful (chosen FTM push notification)
2019-07-30T16:59:15.185161+02:00 C4 radiusd[26836]: facauth: sending Access-Accept packet for FTM push auth to 10.109.19.9 port 1173, id=90, code=2, length=34
2019-07-30T16:59:15.185173+02:00 C4 radiusd[26836]: # Executing section post-auth from file /usr/etc/raddb/sites-enabled/default
As mentioned, this data is TLS encrypted, signed, and sent to the Fortinet push server, which in turn forwards the notification to the Apple/Android notification service (whichever is appropriate), which then sends the notification message to the specified mobile device.
- The FortiToken Mobile app is then used to process notifications and shows a pop-up with logon details.
Once Approved or Denied, the FortiToken Mobile app establishes TLS encryption and signed communication directly with FortiAuthenticator, based on the FortiAuthenticator's interface IP OR the 'Public IP/FQDN for FortiToken Mobile' setting.
The mobile app receives this information (where to send the reply) as part of the notification. A DNS query may be made, and a TCP handshake will follow with a TLS handshake. TLS 1.3 is supported.
Once the connection is established, the app sends either the OTP token with the 'Accept' button or a deny response to FortiAuthenticator.
-
When a response from the FortiToken Mobile app is received, RADIUS Access-Accept (Approve) or Access-Reject (Deny) is sent from FortiAuthenticator to the RADIUS client.
If the user has any AVP directly set or inherited from group membership, then those are sent as well (Note: that does not apply to users whose 'User Role' on FortiAuthenticator is Administrator or Sponsor. There are no AVPs sent for such users, even if they have 'Allow RADIUS Authentication' enabled; this setting is disabled by default).Example Access-Accept:
exec tcpdump -nnvvi any port 1812
16:21:16.259382 IP (tos 0x0, ttl 64, id 45802, offset 0, flags [none], proto UDP (17), length 62)
10.109.19.68.1812 > 10.109.19.9.2349: [bad udp cksum 0x3b62 -> 0xcb03!] RADIUS, length: 34
Access-Accept (2), id: 0x50, Authenticator: 10b02f9d9cca6c858761002d77a976a9
Vendor-Specific Attribute (26), length: 14, Value: Vendor: Fortinet (12356)
Vendor Attribute: 1, Length: 6, Value: LOCALS
0x0000: 0000 3044 0108 4c4f 4341 4c53
- Troubleshooting mobile push notification timeouts: The FortiGate has a short global authentication timeout (5 seconds). When larger than the RADIUS server timeout, it allows for one or more retries before the FortiGate gives up. This timeout must be at least as long as the RADIUS server timeout.
Both settings can only be configured using the CLI.
To configure the RADIUS server timeout:
config user radius
edit <RADIUS server name>
set timeout <value, e.g. 30>
end
To configure the global authentication timeout:
config system global
set remoteauthtimeout <value, e.g. 60>
end
Related articles:
