We identified a new bug with the Fortinet authentication mechanism being used to query LDAP. If you are using active-directory to authenticate remote SSL-VPN users with no success, please check your event log for a "no_matching_policy" error. Recent escalations with Fortinet have confirmed the username and password being used for LDAP queries must not include complex characters.
Our testing confirms that using characters like "#", "!", and "$" in the password can create the "no_matching_policy" issue. After removing them and sticking to alpha-numeric only, the authentication immediately works. This bug is not applicable to the incoming SSL-VPN credentials; it ONLY affects the account used to query LDAP.
Things to know about the LDAP Server settings:
1) Common Name Identifier
Using the "sAMAccountName" as shown above will authenticate your users with their assigned active-directory username. This is case-sensitive.
2) Distinguished Name
This is the LDAP path to your highest level query folder. You can increase security by drilling down into a specific Organizational Unit (OU), if you prefer. The authentication mechanism will only allow users within or below this path/folder/OU.
Example: DC=domain,DC=CA (this would search the full domain)
Example: OU=users,DC=domain,DC=ca (this would search objects within the users OU only)
3) User DN (Distinguished Name)
The Fortinet appliance needs a valid and working active-directory user to run queries. This account is used to test incoming SSL-VPN login credentials against your domain controller. You MUST use the complete LDAP path to this user object. Failure to include everything, even the spacing, will break things. I suggest you look into DSQUERY or ADSIEDIT.MSC for copy/paste of the path.
4) Password (for your User DN)
The password field on this page is reserved for the User DN (the user object you will use to send LDAP queries to your domain controller). To avoid the bug described at top of this article, use ALPHA-NUMERIC CHARACTERS ONLY! If you use "!", "#", "$", etc. you may run into failure. I also suggest you do not make your password exceptionally long. Watch your event log for the "NO_MATCHING_POLICY" issue and tweak accordingly.
Testing SSL-VPN Authentication from the CLI
Fortinet has a nice built-in diag you can run to test things. Pick a user with SSL-VPN access and run the following command:
diag test authserver ldap "server-name" aduser "some.user" "password"
Typically this situation should never happen, you can always forward ports through at the other side. Right? As all you IT guys know, 3rd party software and complex networks will ask for some weird deployment tasks. This demonstration assumes you already have an existing Interface based IPSEC tunnel running between 2 fortinet appliances and they are talking like best friends. I've tested this on 4.0 MR3 P5, I would suggest you use the same or current.
--- WAN1: 220.127.116.11
--- Int1: 10.20.1.1
--- Port 36008 should be forwarded to 10.10.1.17 in Site B
--- WAN1: 18.104.22.168
--- Int1: 10.10.1.1
--- Server on 10.10.1.17 with port 36008 open and ready
IPSEC Interface Name: IPSEC-YKN1-SPG1
The idea ... when anyone on the internet connects to 22.214.171.124 on port 36008, they will be redirected up through the IPSEC tunnel and to the remote server. Let's get started!
1) FortinetA - Create a port-forwarding rule just like any other
2) Fortinet A - Create a firewall policy to allow the internet traffic in on WAN1 and out the IPSEC Interface to your port forwarding rule (remote server)
Do not forget to enable NAT!!!
3) Fortinet B - Create a reverse route to manage the WAN1 interace on Fortinet A
Without this, the fortinet will drop the incoming packets when it does a reverse path check.
"id=36871 trace_id=188 func=ip_route_input_slow line=1268 msg="reverse path check fail, drop"
I recommend you set the distance to 1 so that it takes priority, you should decide depending on your other routes.
Instead of using the /24, you could use the gateway the WAN1 port of the Fortinet A is using. For this demonstration to help keep your sanity, we've left it at the full subnet.
4) Test it out!
The best method to test this is to telnet to port 36008 from an EXTERNAL location to 126.96.36.199.
You can do this with any operating system.
Telnet 188.8.131.52 36008
If it connects to your service, you're good to go!
If you're having issues, I suggest changing the forwarding port to a port that you know is open on the server. Try using telnet from the inside of your network to verify the port is open, and then test externally.
Common server ports are 21, 22, 80, 110, 143, 3389
Check which ports are open on your server, head back to Step 1) and use this port instead.
Once you have it routing through to that port correctly, change it to the actual port you need.