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 , i tired with diagnose test authserver ldap 19.168.1.50 user password i am getting " 192.168.1.50 is not a vaild ldap server name"

[abelio]

ORIGINAL: Gopinath hi , i tired with diagnose test authserver ldap 19.168.1.50 user password i am getting " 192.168.1.50 is not a vaild ldap server name"

indeed, you need provide to diagnose command the object `name of your ldap server, not it´s IP number run CLI command: " show user ldap" to get the ldap´s server name., thereafter test your connection with diag test authserver ldap " ldapservername" user passwd regards

[fcb]

What version are you all using? I am on v4.0,build0291,100824 (MR2 Patch 2) and his method no longer works. Be careful with you configs once you upgrade as my config (which was working) allowed for anyone to authenticate. the " Set Group" attribute is no longer present. I questioned support on this and here is their response: Hello, I have checked with some senior engineers and they made sure that filtering is based on OU and not on user group also it is not possible to use FSAE to authenticate the client by XAUTH. If you really need this feature you can send a feature request to your reseller. If you not have any other questions, i will close this ticket. Please advice. Regards, Fortinet TAC Americas 1-866-648-4638 https://support.fortinet.com Anyone else seen this or have other ideas?

[Mikkel_Andreasen]

Hi, Bringing back an old post... I' m attempting to replicate this configuration, but cannot get it to work. The filter is being ignored and everybody is successfully authenticated. My configuration is as follows

Company_Fortigate_~ (LDAPSERVER) # Company_Fortigate_~ (LDAPSERVER) # show config user ldap edit " LDAPSERVER" set server " LDAPSERVER.DOMAIN.local" set cnid " sAMAccountName" set dn " OU=Company,DC=DOMAIN,DC=local" set type regular set username " ldapforti" set password ENC xXNEEZwa7UWa9j0EW8KnPplqfJ7blLDuj5y8xFFZOMSl8ZXEKaW1TzXVBeElUwpEV088Kc0Nhv3432430hLAEIs3Sn23v3PPPsG2LuG+XpE7td5ZqS87fL set group " CN=VPN-Company-Konsulent,OU=Company,DC=DOMAIN,DC=local" set filter " (&(objectCategory=CN=Group,CN=Schema,CN=Configuration,DC=DOMAIN,DC=local)(member=*))" next end

And I' ve triple checked the username, OU name and everything else. I' ve made a wireshark dump of the traffic between the firewall and the LDAP server, and three things are puzzling me 1. The name of the group, VPN-Company-Konsulent, is no where to be found 2. All LDAP binds are listed as " simple" as opposed to " regular" 3. initially I had made an error in the filter domain name, and all authentication worked just fine (too well - everyone was allowed access). please advise - this is driving me nuts! Sincerely Mikkel Andreasen

[rwpatterson]

Below is my working config. Compare with yours:

 config user ldap
     edit " DC01-RDP Users" 
         set server " 192.168.xxx.xxx" 
         set cnid " samaccountname" 
         set dn " dc=ad,dc=domain,dc=tld" 
         set type regular
         set username " cn=fortigate,cn=users,dc=ad,dc=domain,dc=tld" 
         set password ENC /////+ <blah-blah-blah>
         set group " cn=RDP Users,cn=users,dc=ad,dc=domain,dc=tld" 
     next
 end
 

I left the filter at the default. Works like a charm. FGT vers. 4.0.4. Your mileage may vary.

[Mikkel_Andreasen]

I do appreciate all the help I' m getting - unfortunately I' m not progressing :-( Tried your suggestion, but it was the exact same thing - the group restriction was ignored. Enabled debugging, and as I suspected the groupname is nowhere to be seen Allowed user

COMPANY_Fortigate_~ # diagnose debug enable COMPANY_Fortigate_~ # fnbamd_fsm.c[846] handle_req-Rcvd auth req 49938439 for USERNAME in LDAPSERVER opt=27 prot=0 fnbamd_ldap.c[375] resolve_ldap_FQDN-Resolved address LDAPSERVER.DOMAIN.local, result 172.16.1.21 fnbamd_ldap.c[144] start_search_dn-base:DC=DOMAIN,dc=local filter:sAMAccountName=USERNAME fnbamd_ldap.c[674] fnbamd_ldap_get_result-Going to SEARCH state fnbamd_fsm.c[1040] poll_auth-Continue pending for req 49938439 fnbamd_ldap.c[172] get_all_dn-Found DN 1:CN=FULL NAME,OU=OUNAME,OU=COMPANY,DC=DOMAIN,DC=local fnbamd_ldap.c[188] get_all_dn-Found 1 DN' s fnbamd_ldap.c[214] start_next_dn_bind-Trying DN 1:CN=FULL NAME,OU=OUNAME,OU=COMPANY,DC=DOMAIN,DC=local fnbamd_ldap.c[589] fnbamd_ldap_get_result-Going to REBIND state fnbamd_fsm.c[1040] poll_auth-Continue pending for req 49938439 fnbamd_ldap.c[697] fnbamd_ldap_get_result-Auth accepted fnbamd_ldap.c[769] fnbamd_ldap_get_result-Going to DONE state res=0 fnbamd_auth.c[1356] fnbamd_auth_poll-Result for ldap svr LDAPSERVER.DOMAIN.local is SUCCESS fnbamd_comm.c[129] fnbamd_comm_send_result-Sending result 0 for req 49938439

Disallowed user (i.e. not in any groups)

COMPANY_Fortigate_~ # fnbamd_fsm.c[846] handle_req-Rcvd auth req 49938441 for vpn in LDAPSERVER opt=27 prot=0 fnbamd_ldap.c[375] resolve_ldap_FQDN-Resolved address LDAPSERVER.DOMAIN.local, result 172.16.1.21 fnbamd_ldap.c[144] start_search_dn-base:DC=DOMAIN,dc=local filter:sAMAccountName=vpn fnbamd_ldap.c[674] fnbamd_ldap_get_result-Going to SEARCH state fnbamd_fsm.c[1040] poll_auth-Continue pending for req 49938441 fnbamd_ldap.c[172] get_all_dn-Found DN 1:CN=vpn,OU=COMPANY,DC=DOMAIN,DC=local fnbamd_ldap.c[188] get_all_dn-Found 1 DN' s fnbamd_ldap.c[214] start_next_dn_bind-Trying DN 1:CN=vpn,OU=COMPANY,DC=DOMAIN,DC=local fnbamd_ldap.c[589] fnbamd_ldap_get_result-Going to REBIND state fnbamd_fsm.c[1040] poll_auth-Continue pending for req 49938441 fnbamd_ldap.c[697] fnbamd_ldap_get_result-Auth accepted fnbamd_ldap.c[769] fnbamd_ldap_get_result-Going to DONE state res=0 fnbamd_auth.c[1356] fnbamd_auth_poll-Result for ldap svr LDAPSERVER.DOMAIN.local is SUCCESS fnbamd_comm.c[129] fnbamd_comm_send_result-Sending result 0 for req 49938441

According to http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=13141&sliceId=1&d... I should be seeing references to both the group name and memberstate... Bloddy odd! Sincerely Mikkel

[Mikkel_Andreasen]

Eureka! It' s working now - turned out to be a filtering error :-) Thank you all for assistence! /mikkel

[rwpatterson]

Please post the working config with the firmware version so others won' t have to bang their heads against the same wall again. Obfuscate the IPs and domain info if you want privacy. Glad it worked out.

[Mikkel_Andreasen]

Working config

config user ldap edit " LDAP-COMPANY-Konsulent" set server " IP.ADDRESS.OF.DC" set cnid " sAMAccountName" set dn " DC=DOMAIN,dc=local" set type regular set username " CN=Ldapforti,OU=COMPANY,DC=DOMAIN,DC=local" set password ENCODEDPASSWORD set group " CN=VPNGROUP,OU=COMPANY,DC=DOMAIN,DC=local" next END

Which I thought I had attempted several times, but apparently took a while to finally nail down... live and learn. Actually very simple, but I was focusing on the " set filter" part when in reality I should have left it at default. /mikkel