Two Factor Authentication (LDAP)

[jwood]

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.

[Kalliek]

This is really a problem.  We have some users using 2FA and most others not.  We have implemented RADIUS auth which means that if one of the 2FA users types in his/her username in any case other than exactly as defined on the local account, the system does not match the local 2FA user and uses RADIUS which matches the user in our AD regardless of case.

The 2FA user then logs on without having to provide the Forti-Token.  It is quite ridiculous!  The best fix for this would be to switch off case sensitivity on the Fortigate for usernames.  Can this be done ?  

[Novox]

I totally agree with you.  It seems like a Forti should be able to turn off case-sensitivity (or make it an option).  I can't imagine anyone wanting to maintain local users with identical spellings, but mixed case...  i.e. an "admin" user, an "AdMiN" user, an "ADMIN" user; and any permutation in between.  It would be as simple as ToLower()'ing all local users and the attempted username, then performing the string comparison...

Potential workaround for you:

If you're using Network Policy Server (NPS) from Microsoft for RADIUS, you could technically create a "Non-2FA" AD user group, add everyone who doesn't need 2FA into that group, and add that group as a "Condition" for the RADIUS "Network Policy."  That way, if a 2FA user attempts to login with mixed case, after they bypass the FortiGate, the RADIUS authentication will reject them.  This should enforce your 2FA policy for select users.

[Kalliek]

I like the NPS idea.  I will try it, thanks!

[XavierMP]

OK, I understand I can use local groups and credentials still handled by LDAP in order to not have a problem with 2 factor authentication. But I see a problem: redundancy, I mean high availability of LDAP servers.

When I define a local user I can just pick one LDAP server. Whereas if a create an LDAP group I can select 2 or more LDAP servers.

In this way, the local user will not be able to authenticate if one LDAP server is down: that's a big problem.

Any idea?

[emrecicek]

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

[Debbie_FTNT]

Hey Emre,

we have a number of KBs on this:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Description-of-CVE-2020-12812-bypassing-tw...

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

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

[GeoffA]

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

[emrecicek]

Debbie is a kind of bot user. They don't try to understand us. LDAP integration is not working truly. Forti is not interested in users and user problems. Forget it, you need to pay and buy a VPN product. Thanks for your comment.

[Debbie_FTNT]

Hey Emre,

I'm sorry to hear that I misunderstood you in some regard.

Do you have any suggestions how I can improve my responses in the future?

In addition, if you do still have questions about the LDAP integration and token, or if there is anything I can elaborate on, please let me know.

From what I understood, your question was this:

- you have LDAP users linked with FortiToken (or a different two-factor authentication method) on the FortiGate

- you found that sometimes these users can log in without a token being required

- this happens if the users log in with a different case

-> the user on FortiGate is 'jdoe', but the user logs in with 'JDoe' for example

- is this correct?

As mentioned above, this is a well-known and well-documented behaviour stemming from the fact that FortiGate is case-sensitive whereas LDAP is not. Changing the FortiGate default behavior to be case-insensitive as well would be a VERY significant change affecting far more than LDAP users with an assigned token.

There are a few workarounds in earlier versions, and a setting added to make users case insensitive so no matter how they log in (in the example, 'jdoe', 'JDOE', jDoe' etc) would all trigger two-factor authentication.

If you are unclear how exactly the behavior is triggered or why the FortiGate behaves like that (skipping two-factor authenticaton), I am happy to elaborate on what is going on during the authentication processs :)

I hope this helps!

[Debbie_FTNT]

Hey GeoffA,

there is no setting on FortiGate where you can force case-sensitivity across the board, sorry; you have to set case-insensitivity (and thus enforce token no matter how the user logs in) in each user individually.

Aside from that, there are the workarounds outlined in the KB above (using realms/groups or a FortiAuthenticator) to ensure that users can't log in without token when they have one assigned.

If you have questions about any of the options mentioned in the KBs above, let me know and I will try to provide additional information :)