Active Directory Authenticaton with Groups (LDAP)

[#1]

Active Directory Authentication I' ve had a rough couple of days parsing through documentation trying to figure out how to get my Fortigate 100A router to use Active Directory 2003 for IPSec VPN authentication. This tutorial is the result. It results in a very clean setup that allows an administrator to allow/disallow VPN access based on Security Group membership in AD. This configuration should also work for any other type of access control, such as SSL-VPN or Web authentication. Create a Security group in AD, I called mine " VPN Users" Add any users to this group that will need VPN access. Create a User in AD, mine is named " Fortigate" . This user MUST be located in the root of the tree containing user accounts. The fortigate router will only try to authenticate clients that are located in the same OU, or a sub-OU of this user! The following configuration can only be configured using the CLI. This is because the " group" tag is not available in the web interface. (This at least holds true in 3.0 MR6 Patch 2) If you are not already familiar with FortiIOS, now is a good time to learn. You could also just log in and type the following commands, but do so at your own risk. Please read all my comments below before doing this part. config user ldap edit " <LDAP NAME>" set server " dc.example.com" set cnid " sAMAccountName" set dn " OU=People,DC=example,DC=com" set type regular set username " Fortigate" set password ENC <Fortigate' s Password> set group " CN=VPN Users,OU=People,DC=example,DC=com" set filter " (&(objectCategory=CN=Group,CN=Schema,CN=Configuration,DC=example,DC=com)(member=*))" next end server = IP address or DNS name for the domain controller to authenticate against. type = The type of LDAP authentication to be done. regular is the only one that can do Auth->Search->Auth->Group Verification username = The username that will initially authenticate against LDAP. (NOTE: Must be located in the root of the " dn" ) In other words, when the router tries to login, it will try DN prepended by username as the LDAP User! password = Password for the username dn = This is the Distinguished Name where where the Fortinet does everything. This serves 2 purposes. 1) This is where the username is located in LDAP 2) This is the base of searching for ALL USERS THAT WILL TRY TO AUTHENTICATE! cnid = The username that the client tries to authenticate will be matched against this. I chose the sAMAccountName, which is the Windows Logon Account. You could also choose to use the displayName, userPrincipalName, or any other LDAP attribute you choose. group = This is the DN of the group that the user MUST belong to in order to login. Note: Full LDAP Path Required. (Does this need to be in the DN tree? I don' t believe so, can someone verify?) filter = Once the group is found, it' s list of members is found using this query, which is ran against the group object itself. So, the above line first makes sure that the group is actually an AD Security Group, and then gets the list of all members. If the user trying to authenticate is in the list, access is granted, otherwise access is denied. Well, I hope you enjoyed this write-up, it was painful but fun! With any luck, you will find this helpful and avoid needing too much asprin. :-) Cheers!

[#2]

Hi, Similar case for me. I can' t figure out what is the problem. I' m looking for information concerning diagnose command of CLI, it seems hard to get documentation no it. Anyone could help ? thank you

[Jesús_Cambera]

Iain, Whould you mind to post your LDAP configuration?? (Get it from the Fortigate console) Something like: config user ldap . . . end

[#4]

I too get the " Query Failed" message when I use the " query distinguished name" button. Here is my config: config user ldap edit " KAUST-AD" set server " 172.16.10.240" set cnid " sAMAccountName" set dn " OU=KAUST,DC=kaustgrp,DC=com" set type regular set username " FortiGate-Auth" set password ENC 6cASN0v7FEdC0FE9TYwRl54321NxHJM/lvrklp1TxsKzv0UHGZ/G2q+00YzYltxQWNrhTnidkyaRgJ/4VBfD8dRKq1QswzxEEww+o2ZPlNS9b6xT set group " CN=VPNUsers,OU=KAUST,DC-kaustgrp,DC=com" set filter " (&(objectCategory=CN=Group,CN=Schema,CN=Configuration,DC=kaustgrp,DC=com)(member=*))" next end Any information would be nice. I' ve run LDAP queries using a non-domain workstation using these credentials successfully.

[Jesús_Cambera]

Hi JeffTate, Try this: OLD --> set group " CN=VPNUsers,OU=KAUST,DC-kaustgrp,DC=com" NEW --> set group " CN=VPNUsers,OU=KAUST,DC=kaustgrp,DC=com" It should do the job. Greetings, Jesús Cambera

[#6]

DOH!! I dunno how many times I' ve gotten a stinking dash in there when I wanted an equal sign!~!!!!

[#7]

Wish that worked - the query button still returns " query failed" ... Any more information? Thanks for all the help jeff

[#8]

I have a question about this. Lets say when I open up my AD I have company.com and one of the OUs is Company and a sub OU under Company is Users. Users, obviously, is where all my users are that need access. How do I insert multiple OUs? Im just not sure on the syntax of the command to have an OU and its sub-OU. Other than that, I think I get the rest of it. Thanks!

[#9]

FordM, In the case that you are using Active Directory. " Users" is NOT an OU, it is a container. Containers cannot be Delegated or assigned Group Policy. As such, using them for user management is often discouraged. This is why I generally create a " People" OU and move all " Real Users" into it, leaving the system accounts in the " Users" container. Regardless of which way you do it, all user' s would just need to exist in the same " DN" , which would be " CN=Users,DC=company,DC=com" . And the Fortigate user would need to be in the " Users" container. You could create as many users within this container as you want, and the FortiGate router will search for them and authenticate them automatically as per the above procedure. Hope that helps.

[laf]

Hy guys, I' m struggling for about 4h to make this work on another location, but no success. PLease, help me out with some advices, debug commands, anything. 1. First of all, if I' m not using xAuth, VPN is working perfectly; and I' m running on MR7 patch 3. 2. I created a Domain Local Security Group: VPN User, and I add to it a test user; 3. All users are to be found in Users container, which is the builtin OU on every 2003 server; here I created fg user (for initial Fortigate authentication) do I have to add this user to VPN User group ? I assume I don' t have to. 3. On FG here s my configuration: config user ldap edit " ldap_userr" set server " 192.168.1.7" set cnid " sAMAccountName" set dn " OU=Users,DC=sixt,DC=local" set type regular set username " fg" set password ENC 6AMAAJNaGbqNkg7qGLJRp0kfq1mqWBqbMOT1unBRbEkJdbm9+m1L8rn5jrI+Gf4ZJmU83g7c8NrJ0sFGwhZBOQGX6GshquDzaVghMPROSAdmaofu set group " CN=VPN User,OU=Users,DC=sixt,DC=local" set filter " (&(objectCategory=CN=Group,CN=Schema,CN=Configuration,DC=sixt,DC=local)(member=*))" next end The username I payed close attention to all capital letters, and the objectCategory is the same as ADSI tool showed me. After that, I made that FW group and add the ldap_userr and check xAuth in IPSEC policy; Do I also have to configure a FSAE user on Fortigate CLI or install FSAE on that server ? Below is the traffic generated each time I enter the test username and password: 53.853130 192.168.1.252.1393 -> 192.168.1.7.389: syn 2609583035 53.853300 192.168.1.7.389 -> 192.168.1.252.1393: syn 1139397826 ack 2609583036 53.853354 192.168.1.252.1393 -> 192.168.1.7.389: ack 1139397827 53.853633 192.168.1.252.1393 -> 192.168.1.7.389: psh 2609583036 ack 1139397827 53.854244 192.168.1.7.389 -> 192.168.1.252.1393: psh 1139397827 ack 2609583060 53.854279 192.168.1.252.1393 -> 192.168.1.7.389: ack 1139397936 53.950172 192.168.1.252.1393 -> 192.168.1.7.389: psh 2609583060 ack 1139397936 53.950198 192.168.1.252.1393 -> 192.168.1.7.389: fin 2609583067 ack 1139397936 53.950336 192.168.1.7.389 -> 192.168.1.252.1393: ack 2609583068 53.950380 192.168.1.7.389 -> 192.168.1.252.1393: fin 1139397936 ack 2609583068 53.950403 192.168.1.252.1393 -> 192.168.1.7.389: ack 1139397937 Here' s a server overview picture: http://s6.transfer.ro/storage/transfer_ro-d6a6e5b03b.zip

[laf]

Ok, I ve made up, yesterday night to this conclusion, it didn' t work because I was using an OU which was builtin. I created another container and it worked at once. As a diagnose tool for everyone else, if you want to setup on future, first step, if it' s not working: diagnose test authserver ldap <server_name> <username> <password> where server_name is the ldap server you defined in your configuration config user ldap edit server_name Again, thanks a lot for all who posted in and especially for the author of this.