Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
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 ?
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.
I like the NPS idea. I will try it, thanks!
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?
Today the date is 2022. Still not working. They know the issue and do not want to solve it. Any idea?
Hey Emre,
we have a number of KBs on this:
There are configuration settings available to deal with this and make FortiGate case-insensitive on a per-user basis.
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
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.
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!
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 :)
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1688 | |
1087 | |
752 | |
446 | |
226 |
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 2024 Fortinet, Inc. All Rights Reserved.