Fortinet SSL VPN Authentication with LDAP – no_matching_policy

Posted on July 12, 2012

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.

Example:  CN=LDAPUser,OU=Users,DC=domain,DC=ca

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" 

 

Comments (2) Trackbacks (2)
  1. Ludo,I hadn’t gotten that far yet :). Currently, since this for teitsng. My initial idea was to use setuid root. After you posted I thought I’d poke around, but I can’t figure out what I’d need to actually make setuid root since making the OpenDS.jar or the start-ds script won’t really work.If someone has an idea, I’d like to hear it.So after some hacking around with the other admins here, we have decided to try some iptables rules.We made the Directory server owned by a regular user, and let it attach to an unprivileged port, and then tossed this into iptables:iptables -t nat -A PREROUTING -p tcp –dport 389 -j REDIRECT –to-port 1389iptables -t nat -A OUTPUT -p tcp –dport 389 -j REDIRECT –to-ports 1389I am not sure how much I like that, but it’s a fix for now.

  2. It’s an amazing article in favor of all the online visitors; they will take advantage from it I am sure.


Leave a comment