Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
emrecicek
New Contributor II

FortiClient SSL VPN Two-Factor Authentication with Active Directory Issue

Hi Everyone,

 

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?

https://community.fortinet.com/t5/Fortinet-Forum/Two-Factor-auth-issue/m-p/58734#M58644

 

Best Regards

Emre

EC
EC
6 REPLIES 6
vdralio
Staff
Staff

Dear Emre,

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:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Local-user-username-case-sensitivity/ta-p/...

There are some other options to prevent this:

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

Best Regards,
Vasil Dralio

 

 

emrecicek
New Contributor II

Hi Vasil,

 

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

 

Best Regards 

Emre

EC
EC
Debbie_FTNT

Hey emrecicek,

we also have a guide to SSLVPN authentication in general: https://community.fortinet.com/t5/FortiGate/Technical-Tip-A-quick-guide-to-FortiGate-SSL-VPN-authent...
That might give you a clearer understanding as to why the case-sensitivity setting is relevant.

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++
vdralio
Staff
Staff

 

Dear Emre,

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:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Local-user-username-case-sensitivity/ta-p/...

Best Regards,

Vasil Dralio

emrecicek
New Contributor II

Hi Vasil, 

Which version of FortiClient do you suggest to us? Which one is working better stabilization and valid? We need to transfer all users to the same version on it.

Thanks for your help.

 

Best Regards

Emre

EC
EC
vdralio

Dear Emre,

I am sorry but I do not have any specific answer regarding the version you should go to, this depends on your environment and the known issues that may affect your situation. 

I will suggest taking a look at all release notes so you can avoid matching a known issue that may affect you.

If you need any other specific information regarding any known issue, please create a Support Ticket and the Team will be happy to help you.

 

Please also update the status of the case if you do not have anything else :)

Best Regards,

Vasil Dralio

 

Labels
Top Kudoed Authors