SSL VPN authentication by Security Group using LDAP on Fortigate Firewall Appliances with 4.0 MR2

Posted on December 6, 2010

If you're using a fortigate appliance, one of the most fantastic features is the SSL VPN. It's light-weight, efficient, msi, highly secure, and supports authentication using LDAP (in this example active directory).

First and foremost, do NOT mistake FSAE with LDAP when using the SSL VPN. FSAE is designed for internal network policies only, not for incoming SSL authentication requests. You must use LDAP, radius, etc. to facilitate incoming SSL VPN auth requests.

For this example, we are using default locations to save objects. We recommend you use unique OUs for users and groups created below.

1) Create a standard active directory user object to allow the Fortigate to run LDAP queries

In this example we are using the following:

User Name: Fortinet LDAP
Username: fortinet
Password: (something verify complex)
Password never expires: Enabled
User cannot change password: Enabled

2) Create an Active Directory security group

Users who are members of this group will be allowed to authenticate to the SSL VPN.
For this example we are using: SSL VPN Users

3) Add the LDAP server to the Fortigate appliance

To speed things up we are using the CLI. You will require the following information to complete this step:

  • Pick an LDAP ID Name:¬† serverLDAP
  • LDAP Server (domain controller): 10.200.1.10
  • CNIDAllows you to choose what values are to be referenced when authenticating. In this example, we are using staff usernames (ie. jsmith):CNID = sAMAccountName
  • Distinguished NameA distinguished name is path the OU or domain you wish to filter. In most cases using the entire domain is sufficient and will not affect performance (less than 1000 users). For this case we will be using a default instance, please replace domain.com with your own details.DN: DC=domain,DC=com
  • LDAP Auth Type (basic, regular, anonymous)

 

Use regular, it requires a valid user ID to make LDAP queries.

  • AD Username

 

You will need the LDAP path to the "Fortinet LDAP" user object created in section 1. Load the command prompt on your domain controller:

dsquery user -name "Fortinet LDAP"

which will return the value you need:

"CN=Fortinet LDAP,OU=Users,DC=domain,DC=com"

Now that you've acquired all the information, you can generate the required entry into the Fortinet CLI:

config user ldap

edit "serverLDAP"

set server "10.200.1.10"

set cnid "sAMAccountName"

set dn "dc=domain,dc=com"

set type regular

set username "CN=Fortinet LDAP,OU=Users,DC=domain,DC=com"

set password

next

end

4) Create a firewall user group

This group is used when creating your SSL VPN firewall policies.

You will require the following information to complete this task:

  • Group Name: LDAP VPN UsersPick a name to reference in future tasks.
  • Tunnel Type: Tunnel-AccessYou can create unique tunneling policies by visiting (VPN->SSL->Portal). We will use the default tunnel-access for this task. If you would like to setup split tunneling, you will need to visit the "tunnel access" profile and enable it.
  • LDAP Server Profile Name (created in section 3)serverLDAP
  • Security Group LDAP pathThis is the important part! You need to acquire the exact LDAP path to the security group you are using to allow access to the SSL VPN. In this example, we created this security group in section 2.To find it, use dsquery. Load the command prompt on your domain controller:

    dsquery group -name "SSL VPN Users"
    which will return the value you need:

    "CN=SSL VPN Users,OU=Builtin,DC=domain,DC=com"

    Now that you've acquired all the information, you can enter the details into the Fortigate CLI: :

    config user group

    edit "SSL VPN Users"

    set sslvpn-portal "tunnel-access"

    set member "serverLDAP"

    config match

    edit 1

    set server-name "serverLDAP"

    set group-name "CN=SSL VPN Users,OU=Builtin,DC=domain,DC=com"

    next

    end

    next

    end

    5) Create an incoming firewall policy to open the SSL VPN Auth mechanism

    Generally most situations call for WAN1 to Internal1. Depending on your network, you may need to setup several incoming rules if you would like to allow authenticated users to access internal WLAN or other internal interfaces. For this example, we will just create the standard.

    Using the Web-Gui:

    - Firewall -> Policy -> Policy -> Create New

    Source Interface: WAN1
    Source Address: All
    Destination Interface: Internal1
    Destination Address: ALL or Internal LAN
    Action: SSL-VPN

    At this point you will notice the form change.

    - Click for the "Add" button located directly below "Configure SSL-VPN Users".

    - Move "LDAP VPN Users" to the available user groups

    - Move "Any" to the selected services.

    - Save.

    - Save the new firewall policy.

    - Move it to the top of the "Wan -> Internal" list so that this new policy is the first.

    6) Create a firewall policy to allow the authenticated users to access your internal network.

    Once users are authenticated, they need access to the internal lan. Create another policy as follows:

    Source Interface: SSL Tunnel Interface
    Source Address: All
    Destination Interface: Internal1
    Destination Address: ALL or Internal LAN
    Action: Accept

    This allows all SSL traffic to pass to all internal LAN IPs

    7) Add users to the security group and test

    Remember that each user with access to the VPN needs to be a member of the security group in section 2. Once added, you can load the SSL VPN client from an external location and attempt a connection.

    Server: (your external ip or hostname)
    Username: (active directory username)
    Password: (active directory password)

    Hopefully this helps!

    UPDATE: As this article is apparently being leeched on other sites without mentioning the original author rights, please be advised this was written by Kris Wilkinson @ http://wiki.sirkit.ca/

Comments (4) Trackbacks (3)
  1. Your article really saved me! I was trying by days to resolve this case… CNID was the main detail! I was putting it as “cn”, as the same I put in the LDAP query parameters I have for FSAE using advanced mode. Now its working as expected!!

  2. Thanks for the article. I got LDAP authentication working now, but I can’t seem to come up with a way to make the Two Factor auth work via SMS. I have two factor auth working if I don’t use LDAP, but once I introduce LDAP, I start getting “Permission Denied” errors when I attempt to authenticate to the SSL portal page. Have you had any luck making this work? I had it working using RADIUS auth against IAS as long as I also built a local user with the same name. It would use RADIUS to verify group membership and password, then would send the SMS message (or email) with the code.

    Thanks,
    Jon

  3. Having the same problem as JohnnyWifi. Cannot get anything other than “Permission Denied.” However, I took it a step further. I created a local user on the firewall and even THAT one can’t log in. Gets the permission denied error as well. I’m missing something else….

  4. This article really helped me. Better than Fortinet’s own manual.


Leave a comment