Description
This article describes how FortiToken Push feature works with FortiAuthenticator and Apple/Android based devices, the configuration requirements and the workflow on FortiAuthenticator when a user authenticates.
Useful links:
FortiAuthenticator Documentation – https://docs.fortinet.com/product/fortiauthenticator/6.4
Solution
In cases where PUSH token notifications are desired, a setup needs to be done on FortiGate (or a 3rd party device capable of RADIUS Access-Challenge), pointing to FortiAuthenticator as RADIUS server.
In FortiOS, this would include a user group with the RADIUS server object as member and the FortiAuthenticator configured as a RADIUS server entry.
Any 3rd party RADIUS client needs the same settings enabled on FortiAuthenticator.
The following needs to be configured on FortiAuthenticator (Setup):
1) Enable push notification in RADIUS settings
In older versions: 'Authentication -> Radius Service -> Clients'
The profile for client system has to have 'Enable FortiToken Mobile push notification authentication' activated. Otherwise FortiAuthenticator will not send push notification to Apple/Android servers.
In newer versions: 'Authentication -> Radius Service -> Policy'
The RADIUS policy needs to have push notification enabled in the tab 'Authentication factors' under 'Advanced Settings' (this should be the case by default).
2) 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 the case where the FortiAuthenticator is behind NAT device, this setting makes FortiAuthenticator aware of the public IP and port used by NAT device to translate into 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: NAT device has VIP/port-forwarding, or 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 above mentioned 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.
3) Enable push notification on the interface
The destination interface on FortiAuthenticator where the traffic arrives at (as port1 with 192.168.1.99 in 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 notification.
It is now up to the client to initiate push notification.
The process is as follows:
1) RADIUS client initiates RADIUS authentication with a user that has a FortiToken Mobile assigned
2) FortiAuthenticator checks the authentication via RADIUS policy and discovers the token
3) FortiAuthenticator sends back a RADIUS Access-Challenge and includes this message:
"+Please enter the token code. You can also submit a blank response to initiate a push notification to your FortiToken Mobile app."
4a) If the RADIUS client is a FortiGate/FortiManager/FortiAnalzyer:
FortiGate/FortiManager/FortiAnalyzer parses the message and observes the leading '+' sign; this indicates push notification being offered in this context. The client replies automatically to initiate 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.
4b) 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.
5) 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 triggered push notification by sending an empty code or typing in 'push'.
Once FortiAuthenticator is prompted for push notification, then this is a work-flow of the notification being sent:
1) FortiAuthenticator looks up the actual IP address (A) of the notification server push.fortinet.com
2) FortiAuthenticator then contacts the returned IP and starts TLS handshake with selected server. An encrypted communication, signed by certificates, is then established between FortiAuthenticator and the push server.
3) Notification data is sent Fortinet push server, containing details about 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.
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 Fortinet push server, which in turn forwards the notification to Apple/Android notification service (whichever is appropriate), which then send the notification message to the specified mobile device.
4) FortiToken Mobile app is then used to process notification and shows pop-up with logon details.
Once Approved or Denied, FortiToken Mobile app establishes TLS encrypted 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.
Once the connection is established, the app sends either the OTP token, or a deny response, to FortiAuthenticator automatically.
5) When response from 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 Authenitcation' enabled; this setting is disabled by default).
Example Access-Accept:
> exec tcpdump -n port 1812 -vv
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
