We currently have a dial-up SSL VPN configuration that requires a user to connect using both their Windows AD (LDAP) credentials AND a local computer certificate issued from our internal Windows CA. On top of that, we use FortiToken with push notifications for MFA on the LDAP user accounts.
With the recent push to migrate away from SSL VPN and switch over to using IPsec IKEv2 VPNs instead, I have not been able get the same requirements to work via IPsec.
Our setup includes:
FortiOS – 7.4.8
FortiEMS – 7.4.3
FortiClient – 7.4.3
FortiToken Subscription (not cloud)
Windows NPS for RADIUS (not FAC)
Is this even possible with the above? Seems like it is supported, but I can not get it to work with NPS.
According to the article below, I should be able to get FortiToken MFA push notifications working using local RADIUS user accounts:
…but as soon as I enable FortiToken on a RADIUS user account, NPS fails authentication (error code 16). If I don't enable FortiToken, simple RADIUS user authentication works fine.
If I try to leave out the MFA requirement, I can’t seem to get the right combination of settings on the IPsec Tunnel and in FortiClient (using EMS) to require both a username/password AND a local computer certificate to authenticate successfully using NPS. I can get one or the other working.
Any guidance would be appreciated.
Thanks!
You might want to check out the following article to see if it matches the issue that you are facing:
According to the article, "However, as of now, the FortiToken (MFA) is not supported on Windows FortiClient with LDAP (EAP-TTLS)."
So I take this to mean that using a FortiGate user account of type "LDAP" with FortiToken MFA is not yet possible when using IPsec IKEv2.
This indeed appears to be the case, so it looks like the only available option for IPsec IKEv2 with FortiToken MFA and Windows AD accounts is to use a user account type of "RADIUS" which is the path I'm trying to go down.
Hi FortiNet_Newb,
As per your description, it should be supported. Please run the following command in FGT and reproduce the issue:
diag debug reset
diag debug console timestamp enable
diag debug app fnbamd -1
diag debug app ike -1
diagnose vpn ike log filter rem-addr4 x.x.x.x >public ip
diag debug enable
A little progress this morning....
I was able to finally get FortiToken MFA to work on a FG RADIUS user account.
As I mentioned in my original post, when I followed these instructions (https://community.fortinet.com/t5/FortiGate/Technical-Tip-IKEv2-Dialup-IPsec-tunnel-with-RADIUS-and/...), my Windows NPS was rejecting the authorization.
I found what was causing the issue in our environment. We apply Microsoft's Security Baseline GPO's to our servers. One of the MS security baseline GPO's sets the LmCompatibilityLevel to 5, which causes our servers to refuse LM and NTLM authentication responses, and allows only NTLMv2 responses. Because the NPS server only accepts NTLMv2 with that GPO applied, the MS-CHAP-v2 request from the FortiGate was being denied.
As soon as I applied the registry work around found here, the FortiToken MFA with FortiGate RADIUS user authentication started working immediately. I'm not sure how secure this is, so I have removed the work around for now and am looking for alternative solutions.
User | Count |
---|---|
2568 | |
1358 | |
796 | |
650 | |
455 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.