Due to a misunderstanding of a poorly designed form it is easy to allow LDAP to bypass Fortitokens or other MFA technologies when implemented on Fortigate VPNs. In a Fortigate VPN configuration, you create an inbound rule to allow VPN tunnel access. That rule specifies the source objects and groups that have access to the tunnel.
In the example above you see that a firewall group named SSLVPN-GROUP is allowed to use the tunnel. The bypass arises because the form that controls that group does not make it clear that adding an object to the remote groups section is an additional accepted authentication source.
I assume that some engineers are interpreting the remote groups section as a directory lookup for users placed into the members section of the firewall group. The bypass occurs due to Linux and Window’s interpretation of character case. If the user enters their credentials in a case that matches the way it appears in the member’s section of the firewall group, they will be prompted for their MFA token.
However, if the user enters their credentials in the client using a case that is different (all caps, mixed case, etc.) then the credentials will not match a member of the group. The Firewall group will then proceed to check the remote groups, in our example this would be an LDAP server. The credentials will match (Windows doesn’t consider case in usernames) and the user will be logged in without MFA.
LDAP directory lookups are accomplished by selecting the protocol and then the LDAP server object when adding new users to the Firewall group, not by including it as a Remote Group.
If you have Fortigate VPN devices in your environment, I suggest that you ask your network engineer to check for this situation. I’ve run into the misconfiguration quite a few times in the field. I’ve submitted a feature request to Fortigate to have the “Remote Groups” section on the form more clearly defined.
techbloggingfool.com 