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/

Filed under: Uncategorized 4 Comments

Importing NK2 addresses into Outlook 2010 suggested contacts

Posted on September 1, 2010

In previous versions of Microsoft Outlook (2003 and 2007) the nickname cache was stored to a NK2 file locally on the client's pc. This is hands down one of the most used features for pretty much anyone using Outlook. Let's face it, it's quick, simple and does what it should.

You can find the NK2 files here:

  • Windows XP
    Drive:\Documents and Settings\Username\Application Data\Microsoft\Outlook
  • Windows Vista and later versions
    Drive:\Users\Username\AppData\Roaming\Microsoft\Outlook

With the release of Outlook 2010, the NK2 file has been retired and replaced with "suggested contacts".  Of course with user relying on their existing nickname cache so heavily, you don't want to lose the data. The following method will assist you by importing an existing NK2 file from previous version into Outlook 2010.

  1. Make sure that the .nk2 file is in the applicable folder listed above.
    NoteThe .nk2 file must have the same name as your current Outlook 2010 profile. By default, the profile name is "Outlook." To check the profile name, follow these steps:

    1. Click Start, and then click Control Panel.
    2. Double-click Mail.
    3. In the Mail Setup dialog box, click Show Profiles.
  2. Click Start, and then click Run.
  3. In the Open box, type outlook.exe /importnk2, and then click OK. This should import the .nk2 file into the Outlook 2010 profile.Note After you import the .nk2 file, the contents of the file are merged into the existing nickname cache that is currently stored in your mailbox.
    Note
    The .nk2 file is renamed with a .old file name extension on the first start of Outlook 2010. Therefore, if you try to re-import the .nk2 file, remove the .old file name extension.