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.

[Louwiif]

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 · Accepted solution]

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]

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]

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]

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.

[dudarra]

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

[Novox]

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

[CVops]

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.

[Novox]

"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.