| Solution |
- FortiGate first forwards the user credentials in the Access-Request packet to the FortiAuthenticator server.
- FortiAuthenticator server responds back with Access-Challenge and a Reply-Message = 'Enter token code or no code to send a notification to your FortiToken Mobile'.
- FortiGate responds with an Access-Request, but with an empty password and no token.
Important note:
If the 'NAS' device (Router/Firewall…) does not respond to this Access-Challenge sent by FortiAuthenticator, that indicates that the device does not support 2FA push notification (if it is a 3rd party device, then you need to consult it with the other vendor).
Example below for illustration:
- FortiAuthenticator sends DNS queries to 'push.fortinet.com' to look up the actual IP address (A) of notification servers (for illustration check the below screenshot).
- FortiAuthenticator then contacts the first IP on the list and starts a TLS handshake with the selected server. An encrypted communication, signed by certificates, is then established between those ones.
- Notification data is sent to the respective Apple/Android notification server, containing details about the recipient (particular mobile device), timestamp, session_id, etc.
This is trackable in FortiAuthenticator -> debug -> push-service-worker -> debug output.
2021-07-22T13:41:28.628819+02:00 FAC pushd[1267]: MAIN: #012Stats:#011 workers=1#011 quest=0#012#011Worker[139952154474240] worked on last quest at 2021-07-22 11:03:16.308986
2021-07-22T13:48:27.753136+02:00 FAC pushd[1267]: MAIN: Accepted client connection from [('127.0.0.1', 36090)]
2021-07-22T13:48:27.761856+02:00 FAC pushd[1267]: Broker: Deliver push task to job queue. At position[1]
2021-07-22T13:48:28.198554+02:00 FAC pushd[1267]: Worker[139952154474240]: This registration ID has been found locally [4c20b0d03e50edc]
2021-07-22T13:48:29.467578+02:00 FAC pushd[1267]: Worker[139952154474240]: Sending push message[9e270504412d414fa47c1dfaeea0c052] to User[tokenuser1] with FTM2[FTKMOB*********] with device token[4c20bccf751d4c]...
2021-07-22T13:48:29.470556+02:00 FAC pushd[1267]: Worker[139952154474240]: Pushed 9e27050- tadmin to remote server.
2021-07-22T13:48:31.177488+02:00 FAC pushd[1267]: MAIN: Accepted client connection from [('127.0.0.1', 36100)]
2021-07-22T13:48:31.178063+02:00 FAC pushd[1267]: Broker: Valid login attempt[b'9e2d414fac].
As mentioned, this data is TLS encrypted, signed, and sent to the Apple/Android notification service, which then in return, sends a notification message to the specified mobile device.
The mobile phone is an Apple device in this case, which is why the DNS query toward push-apple.com is seen in the case it is wanted to capture the WAN traffic on FortiGate.
- The FortiToken Mobile app is then used to process notifications and shows a pop-up with login details. Then OTP token or access Approve/Deny response is sent securely in the background from the mobile app 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.
For 3rd party integrations only, there is the possibility of triggering push without RADIUS challenge
|
