FortiVPN and AD Integration Issue

[emrecicek]

Hi Team,

In the currently used system, users and user groups are registered in Active Directory (AD). AD does not have case-sensitivity or Turkish character sensitivity. For this reason, users and access groups are manually registered on the Frotigate Firewall in order not to create vulnerabilities, but users are added by withdrawing from AD with LDAP. Users have also enabled the 2-Factor Authentication feature on Firewall. Thus, only the query regarding username-password authentication is sent to AD on the Firewall during the connection. If the answer is “True” from AD, the Firewall creates a token and performs 2-Factor Authentication. In summary, control is entirely on the Firewall. When the user input is incorrect, they cannot log in, they are blocked on the Firewall as an incorrect credential, and no tokens are produced, so the user cannot connect to the VPN.

It is expected that the Firewall will stop being a control mechanism. Just the users will be moved to Firewall with LDAP over AD again. However, user groups will not be entered into the Firewall manually. Thus, users' access groups are requested to be forwarded to Firewall as a result of a VPN query over AD. However, in this case, when the Firewall makes the query for the user who wants to connect to the VPN, AD receives the query and scans the user for username. Although there is no request with the user name registered on AD on a character basis, AD case-sens do not work, so it recognizes the user and returns confirmation for the VPN login. When the Firewall looks at the users received with LDAP over AD, it cannot see this user, because the user definition entered with the wrong characters does not exist on the Firewall, but AD's request is to make the VPN connection successful. As a result, the user who is not on the Firewall is considered a new user from scratch and the process continues. At this point, it is considered as if 2-Factor Authentication is not turned on for zero users. Because of this configuration, the option "Allow all users to authenticate" is selected. However, this user is seen as outside and unregistered user. For this reason, the VPN connection is considered successful without the user's involvement in the 2-Factor Authentication stage and he is allowed to enter. While the user is making a group query to AD, AD's response from the query is confusing due to different character input.

For example; The user is registered as “cagri” in AD. This information is transferred and saved on the Firewall with LDAP via Active Directory. When the user does not log in as "CALL" or "CAGRI", that is, exactly the same as the AD record, the Firewall does not recognize the user and queries the AD. AD returns the response that the logged-in user exists and which groups the user belongs to. In order to perform 2-Factor Authentication, the user must be among the user names in FW. Since this is not visible, all inputs other than “call” are taken in.

This is an emergency situation for our company. Could you please help us ASAP? Thank you for your interest from now on.

Best Regards
Emre CICEK
EC

p.s.: Used versions;

-FortiClient 6.0.9 Version of it.
-FortiManager 6.4.8 Version of it.

FortiClient FortiGate FortiManager FortiAuthenticator

[Debbie_FTNT]

Hey Emre,

we have a KB detailing how VPN authentication works: https://community.fortinet.com/t5/FortiGate/Technical-Tip-A-quick-guide-to-FortiGate-SSL-VPN-authent...
In your case:
- the user will not match a local entry due to case-sensitivity on the FortiGate

- the FortiGate will query LDAP directly and add the user to groups based on LDAP group membership (it does a memberOf query)

You can turn off case-sensitivity on the FortiGate to work around this: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Description-of-CVE-2020-12812-bypassing-tw...

Let us know if this resolves your issue :)

[pminarik]

Indeed, MS LDAP's insensitivity to case and accents has been an issue in the past, especially since FortiOS by default performs exact case-sensitive and accent-sensitive matching for locally-defined users with FortiTokens.

This has been addressed by bug ID 688989 - since versions 6.0.13 / 6.2.10 / 6.4.7 / 7.0.1, user's can be configured to be matched in a case/accent-insensitive manner.

Quote from 7.0.1 release notes:

Change username-case-sensitivity option to username-sensitivity. This new option includes both case sensitivity and accent sensitivity. When disabled, both case and accents are ignored when comparing names during matching.

config user local
    edit <name>
        set username-sensitivity {enable | disable}
    next
end