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!

[MasterBratac]

Thank you! I´m trying to set this up since a few weeks now. I´ve read all the HowTos, PDFs, KBs and so on, and now yours ... but everytime I try to set this up results in

 fnbamd_ldap.c[392] fnbamd_ldap_init-Invalid params
 fnbamd_auth.c[314] ldap_start-Failed to init ldap for 192.168.50.10
 fnbamd_fsm.c[154] create_auth_session-Error allocating session
 fnbamd_fsm.c[859] handle_req-Error creating session
 

Any Ideas? I´m using MR6 P2 on a 100A, that should authenticate against a W2K8 Active directory ... I´ve now done this by using RADIUS, but I don´t like that ...

[MasterBratac]

Now it works ... my f****** testuser had an empty password ... with password everything works fine!

[Jesús_Cambera]

Hi guys, I just wanted to say " thank you" to Socrates. Your guide has been really helpfull. By the way, for those of you who are not ldap experts (like me ) I' ll give a couple of tips: The group parameter can be obtanained from the Adsiedit GUI ([link]http://technet.microsoft.com/en-us/library/cc773354.aspx[/link]), just go to the group that you selected and copy the " Distinguished Name" . That' s it. The filter parameter , left click on the group from the Adsiedit GUI and look for the " objectCategory" parameter, copy the value and paste in your script. You will need to add a few characters in order to make it work. So, it will be like this: (&(objectCategory=parameter)(member=*)) I hope this will help you people. I wasted a lot of time trying to figure it out. Greetings,

[#5]

I' m glad my guide came in helpful :-) You make some good points Jesus. I' ve used a number of LDAP browsers over the years. My favorite for Active Directory is ADExplorer by Sysinternals. Now owed by Micrososft. [link=]http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx[/link] I figure I' d write-up a little " How LDAP works" quick-n-dirty intro. LDAP is a hierarchal, object-oriented database. It' s essentially a tree, where each entry in the tree has one or more " objectCategories" , which is a fancy way of saying it' s types. It' s very similar to OO programming, in this case the objectCategory is the Class, and the entry itself is an instance (object). And just like Classes, the objectCatetories specify what properties are optional and what properties are mandatory for the entry. Be default, any entry in the tree that is a " User" can do basic authentication. Meaning some LDAP client sends a username and password, and the server accepts or rejects. This is " Simple Authentitication" in the case of FortiGate. Regular Authentication is more complicated. It takes multiple steps, which I' ll go over here. When a client tries to authenticate, the FortiGate sends IT' S OWN username' s DN and password . So in my example above, it is actually sending the complete path of the username to the LDAP server. i.e. DN = CN=Fortigate,OU=People,DC=example,DC=com <password> Then, once it is authenticated, it does a search for the client' s DN within some branch of the tree. In the case of the Fortigate, It' s says " Find all user' s within the DN branch of the tree that have the client' s username and get me it' s full DN" If found, the server will return something like DN = CN=ClientUsername,OU=Somewhere,OU=People,DC=example,DC=com Then, the client will try to authenticate using the newly obtained DN and the client' s password. If successful, the user is correct, but wait, we want to filter against a group still. In AD, when a user is in a group, that information is stored twice, both in the user' s entry in LDAP, by the " memberOf=<list of groups>" , attributes, and also in the Group itself. The group itself maintains a list called " member" , which has a list of the members of the group. The Fortigate uses the second method for discovering group membership. This is the best way, because other LDAP servers, like OpenLDAP, have always handled groups this way. Cross-platform for the win! So, now, still authenticated as the Fortigate user, the router performs a query for the group. It basically says " Get me the member list of the group DN who MUST be a Security Group" Then, if the client user' s DN is found in that list, which is parsed on the client, then the client is now authenticated!" I' d like to mention something that angers me greatly, as I' ve seen it come up a lot,. Hardware and software vendors alike, will often tote their products as being " LDAP compliant." However, when you look into what kinds of LDAP authentication is supported, they can only do Simple Authentication. Well that' s useless! If they can' t do Regular authentication, then there is no way to setup Access Control beyond " if they have a valid username and password, come on in" I hope this comes in handy. :=)

[laf]

10x guys, I tried this too, and finally worked. I had a headache about this because I created the Fortinet user in the User builtin group and not in the OU group. Also I ll mention for those who don' t know that for authentication in Fclient you have to type only the log on name: test and NOT test@domain_name.

[#7]

Hi Don' t know if anyone can assist, but when I try authenticating all I' m getting is ' need auth, but password not set' The password is certainly set ok, the path to teh account are set correctly and I' m getting this on different accounts.. ANyone have any ideas? Thanks

[laf]

Are you using for the auth an user belonging to your VPN Users? Did you check XAuth both on FG and FortiClient? Did you know the password for the user? Try logging in Windows with this user, see if it works.

[Jesús_Cambera]

Did you try loggin in with those users using JXExplorer [link]http://www.jxplorer.org[/link]?? or the Softterra LDAP browser [link]http://www.ldapadministrator.com/download.htm[/link] to check if yout parameters were ok?? Would you mind to tell us, what exactly are u trying to do?? which parameters are u using?? If don' t give information about the problem, anybody will be able to help you. Greetings, ** If you have already solved the problem, please post the aswer . That information would be helpful for others

[#10]

Hi Guys Sorry for not supplying all the information. What I am trying to do is create a ssl vpn on a Fortigate 500a. To this end I have enabled ssl-vpn. I' m now trying to get the AD users to be able to authenticate, so I can have them connect with their existing credentials. The server I' m trying to authenticate against is running windows 2003 sp2 at 10.2.3.93 The account I' m using as a authenticate account is named Fortigate and is a member of a VPN grp as well as a Domain Admin so should have suffecient rights. The Fortigate account is in the same location as my potential users details are Server/Name IP 10.2.3.93 Server Port 389 Common Name Identifier sAMAccountName Distinguished Name OU=Users,OU=Calgary,DC=example,DC=adroot,DC=com Bind Type = Regular Filter (&(objectcategory=CN=Group,CN=Schema,CN=Configuration,DC=adroot,DC=com)(member=*)) USER DN CN=Fortigate,OU=Users,OU=Calgary,DC=example,DC=adroot,DC=com Password According to ADSI my ldap setting are correct, and Softerra also confirms them and can contact 10.2.3.93 to retrieve settings The username and password for Fortigate are correct and I can log into other machines happily with them I can ping 10.2.3.93 happily from the Fortigate cli However when I click on query distinguished name I get Query Failed. Some advise/assistance would be appreciated before I loose my mind on this thing. I' ve trolled through teh ssl vpn MR7 guide which just referres me to teh Fortigate Admin Guide for the dreation of remote users and groups <sigh> Look forward to you comments Thanks