What triggers the email to be sent by FortiAuthenticator for users that receive token via email?

[fcb]

Please try to stay with me on this longer post... I've tried to shorten it up but there is a lot to relay on this one and I appreciate your taking the time and reading through it.. First off, Let me elaborate on that Subject a little.

My user is currently configured to receive a token into my email account when I do things such as: log into any of our Gates, Connect to IPSEC VPN's, Log into our VMware Horizon virtual desktops, etc... I am receiving the token via a RADIUS Client on the FA where the authentication group ultimately looks at our AD environment via LDAP and/or FSSO so I can use the same credentials across several platforms.

This works fine with the exception of an occasional delay in the SMTP conversation(s) which will occasionally cause the login to timeout before I can get the token input -  Other than that, I have been using this method w/o issue for a couple of months now BUT most everyone in the company are using FortiToken Mobile.

I was recently tasked with getting our Ironport SPAM and AV box to participate in 2FA for the admin account logins. It has a config section for RADIUS (and LDAP) but my boss for whatever reason wants to use the local accounts on Ironport over the LDAP we use most everywhere else. 

In testing I can get the Ironport to prompt me for the token but I never receive the taken into my email so I have nothing to enter in there. When troubleshooting and looking at a PCAP on our Gate that is directly connected to Ironport,  I do not see the Ironport attempt to communicate with FA until I input some random numbers (Recall that I never got a token in email to input) and hit "login" which obviously....

So my question(s) go back to:

1. What event triggers that email to be sent from FA to the user when they are wanting to use a device protected by that realm via 2FA and FA? The FSSO/LDAP?

2. Can you use the token to email when using only the RADIUS client on FA?

Apologies for long post.

dt

[pminarik · Accepted solution]

For RADIUS triggered authentication, the 2FA-email is triggered as soon as the initial Access-Request is accepted. FAC sends an Access-Challenge, sends the email, and then waits for a follow-up Access-Request that should contain the OTP code from the email.

If your client app (IronPort) only uses FAC for OTP (just verify the token, no password), then the initial Access-Request is missing and there is nothing to trigger the sending of the email with the OTP code. As a consequence, email- and SMS-based do not actually work for "token-only" authentication scenarios.

[fcb]

pminarik,

That was explained exactly in a way that makes it very clear to me now how that whole thing works. It's funny, I have found that if you type a problem out (as I did when posting my message) the solution seems to present itself in most cases. I just realized when typing up my post that all of the clients I had configured and working vs the two I've been working on, the glaring difference is that they were all local accounts and not using FAC (directly or indirectly) to authenticate to the domain so I think I was on the way to nailing this down but you got me there so much faster.. Good post and thanks so much for your quick and excellent help on this one.

[pminarik]

For the sake of completeness:

For OTP-only verification scenarios with email- or SMS-based 2FA, it is possible to use REST API. (one API call to request a token to be sent to a user, another API call to verify the token provided by the user)
However, this usually requires someone to implement this in code in the service that wants to use it, as it is not a general standardised protocol like RADIUS or LDAP. I have no idea if you could modify or extend the functionality of IronPort in such way.