FortiClient SSL VPN Two-Factor Authentication with Active Directory Issue
We are using the " FortiClient 6.0.9.0277 " version for remote connection with SSL VPN. User information comes from the Active Directory. After the connection is established, users need to do 2-Factor Authentication with SMS Verification. There is no any problem until that situation. If the username in the Active Directory is "lowercase" and the user tries to connect SSL VPN with "lowercase", verification SMS comes to the user's mobile phone. BUT, the username in the Active Directory is "lowercase" and the if the user tries to connect with any "UpperCase" or all "UPPERCASE" with using the true username, SMS does not come to the user's mobile phone. So, 2-Factor Authentication broke and the user done a perfect connection with using FortiClient SSL VPN. There must be any solution for that because it is a kind of HUGE BUG to pass the two-factor authentication security step. Also, the same situation occurs with using any non-English character using in a username. For instance, the user's name is Ömer, and the username in the Active Directory is defined as "omer" with using English characters. If the user enters the username in SSL VPN "ömer" or "OMER" or "Omer" or "ömer" or "omEr" it does not matter, again two-factor is passed easily.
Also, I found a similar problem continuing since 2012. Could you please inform me ASAP?
You need to know that Usernames on the FortiGate are case-sensitive while usernames in Windows Active Directory are not case-sensitive. So FortiGate will match only the exact username with case sensitivity to perform 2FA (two-factor authentication) in your case will send the message to the user.
The issue is down to FortiGate treating usernames as case-sensitive by default, whereas LDAP does not. This means that, under specific circumstances, users can bypass a local user entry on FortiGate in place to enforce TFA, and instead authenticate against LDAP.
This requires: - local user entries on the FortiGate with a token/SMS assigned, referencing back to LDAP for credentials - these local users also being members of LDAP groups - at least one of the LDAP groups they are a member of added on FortiGate and is able to authenticate to SSLVPN outright
As an example. - in LDAP there is the user "emrecicek", member of group "VPN-User" - in affected FortiGate, there is a local user "emrecicek" with a Token/SMS assigned and added to policies/authentication rule - in affected FortiGate, there is a group "VPN-User" pointing back to LDAP with filter "CN=VPN-User, OU=[...]"
If the user logs into VPN with "emrecicek", the token/SMS is requested. If the user logs in with "Emrecicek", or "emreCicek", or "EmreCicek", or "EMRECicek" or anything that is NOT an exact match to "emrecicek", it will not match the local user. -> So FortiGate will check other authentication options -> it finds the LDAP group "VPN-User", and so sends credentials for "EmreCicek" or any of the other options to LDAP -> LDAP is NOT case-sensitive, so it does not care about capital/non-capital letters in username, and should accept the credentials -> user is successfully authenticated as a member of "VPN-User" group WITHOUT SMS and has access to anything that the LDAP group has
In firmware versions where this is fixed, a CLI option has been added to the 'config user local' entry, 'case-sensitivity' or 'case-insensitivity' depending on firmware version. Enabling/disabling it will enforce or not enforce case-sensitivity. If case-sensitivity is enforced, the behavior will remain. If case-sensitivity is not enforced, then the user can log in with any capital/non-capital letter variation of his username, but the SMS will still be required.
Please follow the article below for more information:
- keep token/SMS and non-token/SMS users in separate LDAP groups, so they cannot authenticate via LDAP group instead of the local user entry --> only use non-token/SMS LDAP groups for VPN authentication and in policies to enforce this; a token/SMS user should not have membership in these groups and so would fail the group-matching stage in VPN authentication
- do not add any LDAP groups to VPN authentication/policies at all --> this is only an option if all users should be required to present a token/SMS
- use FortiAuthenticator to associate LDAP users and tokens/SMS instead of FortiGate --> in this case, FortiAuthenticator (which is case-insensitive) would handle authentication and FortiGate would have a RADIUS server entry for FortiAuthenticator along with a user group containing the RADIUS server (and possible group filtering)
Thank you so much for your interest in our emergency. Firstly we are using LDAP for taking our users from the Active Directory. These users seem in the "local" part of the Fortigate. We can make a configuration for "enable/disable" to case sensitivity. Nevertheless, we want another solution without using FortiAuthenticator or FortiManager because this makes everything more crowded. We don't want to do the same thing many times in the Active Directory and FortiManager. If we have a chance, we just want to usFortiClient # and LDAP (Active Directory) together with using case-sensitive mode for two-factor authentication. If you have any suggestions, please let inform us. Thank you so much for your interest in m
Thank you for your reply. As you are limited on the use of other devices, the only solution is to disable case sensitivity on the FortiGate side so all the combinations will go through a 2FA check. In firmware versions where this is fixed, a CLI option has been added to the 'config user local' entry, 'case-sensitivity' or 'case-insensitivity' depending on the firmware version. Enabling/disabling it will enforce or not enforce case-sensitivity.
If case sensitivity is not enforced (set username-case-sensitivity disable), then the user can log in with any capital/non-capital letter variation of his username, but the SMS will still be required.
Please follow the article below for more information:
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.