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.
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!
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.
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.
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
PCNSE
NSE
StrongSwan
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.
hey guys,
sorry for hijacking, but i have a question about LDAP / Fortinet
We use the two-factor authentication with email in context with LDAP. everything works fine but i wouldlike to automate the LDAP synchronisation with the Forti --> is this possible?
My aim is, to create a user in the LDAP, the ldap sync with the forti, put the new create user to the firewall and fill up the missing email for the token...
is this possible?
rafael
thanks in advanced Rafael
Did anyone figure out an answer for this? I authenticate users via RADIUS. I'm adding two-factor with FortiTokens. I've created the local user account on the FortiGate with all lower case.
If I try to login with all lowercase, FortiClient properly asks for my FortiToken code. If I login with ANY other mix of case, the local user isn't found, the authentication is passed to RADIUS, and I can login WITHOUT being asked for a FortiToken...
Hopefully you found an answer by now, but we just identified the same issue with Radius and wasted 3 days tracking it down. There's a check box on the Radius setup called "Apply to All Groups" that needs to be unchecked ... that will make it not bypass the Radius authentication and maintain the case sensitivity. LDAP and AD aren't case sensitive, so it appears that the FortiTokens won't work with that solution.
Fortinet Support directed us to only create local user accounts on the Fortinet and not use Radius or LDAP, which isn't really an answer as then you're trying to maintain separate login credentials vs. normal AD credentials, which isn't practical for more than a few users.
Cheers.
"Fortinet Support directed us to only create local user accounts on the Fortinet and not use Radius or LDAP, which isn't really an answer as then you're trying to maintain separate login credentials vs. normal AD credentials, which isn't practical for more than a few users."
I was able to get this to work WITH LDAP/AD... The difference being, a "user group" in the FortiGate that uses LDAP/RADIUS as a "Remote Authentication Server" doesn't seem to work at all with FortiTokens because of the case sensitivity issue; however, "local users," who are of type "LDAP" or "RADIUS" and themselves authenticate against LDAP or RADIUS, added to a different "user group," DOES work with FortiTokens, since you can assign the token to the local user.
This is not the perfect solution, because, as you say you would have to maintain a "local user" account on the FortiGate for each user that needs access in LDAP or RADIUS (but you'd need to do that anyway to assign the FortiToken); however, you don't need to maintain login credentials (since that can still be handled with LDAP or RADIUS). Meaning, the username must be duplicated as a local user, but password authentication is handled from AD/LDAP/RADIUS and FortiToken authentication is handled from the FortiGate.
Oh, and IMHO, the FortiGate "local user" username should be all lowercase, and you should tell your users to use all lowercase when connecting (or some other simple and enforceable format). If the case doesn't match, the user won't be found in the FortiGate local users, and access will be denied.
Hope this helps.
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.