FortiAuthenticator
FortiAuthenticator provides access management and single sign on.
Hawada1
Staff
Staff
Article Id 230258
Description This article describes in detail how FortiAuthtenticator Push notification works.
Scope FortiAuthenticator, FortiGate.
Solution

1) FortiGate first forwards the user credentials in the Access-Request packet to the FortiAuthenticator server.

2) 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'.

3) FortiGate responds back 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:


No RADIUS Response to Access-Challenge.png
4) Then 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).


Push Token in my lab.png

 

5) 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.

6) 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 Apple/Android notification service, which then in return sends a notification message to the specified mobile device.

 

The mobile phone is 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.

 

Push Token in my lab Laptop.png

 

7) 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.

 

8) When a response from the FortiToken Mobile app is received, RADIUS Access-Accept (Approve) or Access-Reject (Deny) is sent from FortiAuthenticator to RADIUS Client.