Skip to main content
jwood
New Member
April 12, 2013
Solved

Two Factor Authentication (LDAP)

  • April 12, 2013
  • 3 replies
  • 34620 views
I have an FG-80C setup with LDAP authentication for SSLVPN. It' s been working great and we recently introduced FortiTokens for two factor authentication. The way I' ve set it up is by creating local accounts on the Fortigate unit and assigning the password field to LDAP lookups, along with the token s/n and adding them to an SSLVPN group. The issue we' re running into is case sensitivity on the usernames. I' ve got them all entered on the Fortigate in lower case and when a user logs in they are prompted for a token PIN code. Works great. However, if a user happens to put their username with an uppercase letter in the username, the Fortigate does not require a token PIN code and allows VPN access with just the AD password. I' ve got a ticket open with Fortinet support, but I' ve managed to stump the first engineer, so thought I would post here. They suggested removing the local accounts, but I/they were unsure how to bind the tokens to each user.
    Best answer by jwood

    After speaking with an engineer, I was told that ldap is not case sensitive.  My solution was to deploy a RADIUS server for my two factor solution, which seems to have fixed the problem for me.  Mind you, the user still has to input the username in the format it was created (ie -  all lowercase), otherwise they get rejected and cannot sign on.  Before with ldap, changing the case sensitivity of the username, would just circumvent the two factor and bypass it completely.  Not the case when using RADIUS.

     

     

    3 replies

    Louwiif
    New Member
    August 27, 2015

    Hello,

     

    How did the ticket go? 

     

    Case sensitive username is an issue to me too. I was wondering if it was possible to tell the FortiGate change this and make it case insensitive.

     

    Thanks!

    jwood
    jwoodAuthorAnswer
    New Member
    August 27, 2015

    After speaking with an engineer, I was told that ldap is not case sensitive.  My solution was to deploy a RADIUS server for my two factor solution, which seems to have fixed the problem for me.  Mind you, the user still has to input the username in the format it was created (ie -  all lowercase), otherwise they get rejected and cannot sign on.  Before with ldap, changing the case sensitivity of the username, would just circumvent the two factor and bypass it completely.  Not the case when using RADIUS.

     

     

    dooasmi
    New Member
    March 21, 2016

    Im willing to bet you are using LDAP groups on the FG for users that you want to enable 2FA for? When you use an LDAP group (Remote group created on the FG), the user authentication request first checks for a local user. If not found, the FG then forwards the req. to LDAP based on the group above. This is your problem. In order to fix this, use local groups instead of LDAP so that the auth. request is not forwarded on to LDAP when a local user is not found. Changing the case of the username should result in a failed lookup for a local user and terminate the authentication request.

    emnoc
    New Member
    March 21, 2016

    FWIW

     

    This is very easy to test and demo by using the diag command;

     

    e.g

     

    diag test authserver  ldap myldapserver_name kenfelix mypassword

     

    diag test authserver  ldap myldapserver_name KENFELIX mypassword

     

    jvanderzee
    New Member
    August 11, 2016

    I opened a ticket as well for this issue.  Hope it helps others as well and is fixed in a future release.  Running 5.2.8 on a Fortigate 60D.

     

    I was using remote LDAP groups on the fortigate for user group association. This is because I much prefer to manage the active directory groups rather than fortigate groups. The usernames pulled from LDAP had capital letters in them so when the user would log in with all lower case the two factor step would be completely bypassed (the fortigate would not recognize the login name). The username request would be passed on from the fortigate straight to the domain controller (login would then succeed). If the user logged in with the capital letters (case) of the username (originally pulled from LDAP) then 2 factor would prompt for the token. To "fix" I removed the remote LDAP groups from the fortigate groups and added each user individually to the fortigate group. I then ensured their usernames were all lowercase. The behavior after doing this was if the user logged in with all lower case they would be prompted for the two factor authentication. If the user used any capital letters (case) then the VPN connection would be denied. To me this is a workaround rather than a true fix. The fortigate should have the intelligence to use a remote LDAP group to authenticate 2 factor users regardless of the username case (upper or lower) used. What I now have to do is manage my user group associations in the fortigate rather than on the domain controller. All that would be needed is the ability for the fortigate to take the username and apply the 2factor association regardless of the case the user types in. Then there would never be an issue of bypassing the 2 factor feature, a huge security flaw. Please add this to the bug or feature suggestion list.

    emrecicek
    Explorer II
    May 9, 2022

    Today the date is 2022. Still not working. They know the issue and do not want to solve it. Any idea?

    Debbie_FTNT
    Staff & Editor
    Staff & Editor
    May 9, 2022

    Hey Emre,

    we have a number of KBs on this:

    https://community.fortinet.com/t5/FortiGate/Technical-Tip-Description-of-CVE-2020-12812-bypassing-two-factor/ta-p/197737

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

    There are configuration settings available to deal with this and make FortiGate case-insensitive on a per-user basis.

    GeoffA
    Visitor III
    May 27, 2022

    Hi Debbie, we have just noticed the same issue, is there not a solution that can be applied to everyone in 1 hit, as I'm not sure that we would like some able to access without a token and some need, we would have created separate groups