VPN authentication using Windows AD

No, the Client VPN should able to use AD to validate the users, in the similar way that use LDAP. The differences is the VPN profile and the rules to use AD instead of LDAP. I already made the configuration to use AD, but it doesn' t work, so i guess that i have the wrong procedure or something isn' t working well. Other Firewalls (like Watchguard) are able to validate using AD and after that user is validated, all network resources are available without ask for network user/pass every time. With LDAP is very tedious enter the user/pass every time, and if you save it, when the net password expire i have claims from all users. I' m sure that Fortinet should have this ability to do more easy the vpn experience to the users.

This means that VPN access only work using LDAP? So, why inside of VPN configuration phase 1, the XAuth parameter show as available option the Active Directory' s user groups? Sorry, but i don' t understand why FSAE that capture the AD information and sent it to the firewall is not able to validate a user using AD instead of LDAP.

Martin V. I believe we are in the same boat. I' ve installed FASE and configured LDAP. I can' t get anyone to authenticate. Maybe this is why? I was just about to start a post about this... My Problem: I have about 25 VPN users. Max is 20 on the Fortigate. I need my VPN users to be able to authenticate with their domain username/pass!

One can authenticate via LDAP/AD for VPN (It' s even an FCNSP exam question) This via defining a LDAP connector to an AD. So define a LDAP in the GUI and define Bind DN user / password in the CLI. Works fine, I believe there' s also a white paper that decribes this. Alternatively you can authenticate via radius on IIS. Below an old post on IIS/Radius auth Requirements/assumptions: • Windows Server 2003, Standard Edition • Fortigate-60 2.80, MR7, build318, 041206 • FortiClient 1.2.172 Windows 2003 Server: • Install the Internet Authentication Service (IAS); it will act as our RADIUS server - see http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_ias_install.asp • Note: I had to reboot the server after installing IAS • Register the IAS in Active Directory - see http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_ias_add_activedir.asp • Open the IAS and create a new RADIUS-Client - Address: <IP address of FortiGate unit> - Client-Vendor: RADIUS Standard - Do not enable " Message Authenticator" - Shared Key: <FG60 supports a maximum of 15 characters> • Create a remote access policy - Contraints: for the first connection attempt you may add only the IP of the FortiGate as " Client-IP-Address" - Profile: edit the profile and enable PAP authentication - see http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_nap_node2.asp • Go to your user accounts - Check if your users are able to dial-in - In my case, the dial-in access is controlled by RAS policy - You don' t have to enable " reversible encryption" , because we will use PAP not CHAP • Note: You may have to switch your domain from mixed to native mode to enable RAS policies More infos on IAS: • http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_ias_howto_top.asp • http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_ias_checklist_corp.asp • http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_IAStopnode.asp FortiGate: • Login via SSH to the CLI • Enter the following commands: config user radius edit " MyRADIUS" set secret SecretKey set server " IP address of radius server" next end • Note: the secret must match the shared key on the IAS and is limited to 15 characters • Note: You can also enter the configuration via the web interface. Goto " User -> RADIUS" and create a new entry. Test from the FortiGate: • You should now be able to successfully authenticate against the RADIUS server • Enter the following CLI command to test the authentication: diagnose test authserver radius MyRADIUS pap ' windowsuser' ' password' • Note: " MyRADIUS" is the name of our radius server defined above • Note: You don' t have to quote the username and the password • Example: If your windows username is jack and the password is test123, the diagnose command would look like: diagnose test authserver radius MyRADIUS pap jack test123 And the response should be: authenticate ' jack' against ' pap' succeeded! • Check the event log of the windows server for IAS entries (under " System" ) - http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_ias_logproc1.asp Test from a client: • You should also be able to test the authentication from another client • You can use the NTRadPing 1.5 RADIUS Test Utility - Get it from http://www.novell.com/coolsolutions/tools/1932.html • Note: Don' t forget to to add a new RADIUS client in your IAS configuration with the IP address of your client • Check the event log of the windows server for IAS entries (under " System" ) - http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_ias_logproc1.asp If you get any errors: • The event log entries are usually very detailed • If you get error code 16 - check the shared key - check the windows password for typos • If you get error code 65 - check your RAS policy - check if the correct RAS policy is applied - check if dial-in access is enabled for the user • You can also enable " tracing" on the RADIUS server - http://www.microsoft.com/technet/security/topics/cryptographyetc/secmod192.mspx Back to the FortiGate: • If authentication is successfull, we can configure the VPN tunnel • Configure a user group config user group edit " ugDialupUsers" set member " MyRADIUS" set profile " strict" set types-in-group 1 next end • Note: We make the RADIUS server the only member of the group, so the whole remote access is controlled by the RAS policy on the RADIUS/IAS Server • Now we need a Phase1 policy which XAuth enabled config vpn ipsec phase1 edit " gwDialupUsers" set dpd enable set nattraversal enable set proposal aes192-sha1 set type dynamic set xauthtype pap set authusrgrp " ugDialupUsers" set psksecret SharedSecret next end • Note: You also need to define a Phase2 tunnel and a firewall policy • Note: You can of course also enter the configuration via the web interface (goto " VPN -> IPSEC" ) FortiClient: • Configure the appropriate connection • Don' t forget to enable " eXtended Authentication" (under " Advanced" ) • Test the connection Debug: • If you still have problems you can enable the debug mode • Login to the FortiGate via SSH and enter diagnose debug enable diagnose debug console timestamp enable diagnose debug app ike 2 • Test the FortiClient connection • Carefully watch the output on the FortiGate console - see http://kc.forticare.com/default.asp?id=115&Lang=1 Security: • Why PAP - see http://www.freeradius.org/faq/ • The communication between the FortiGate and the RADIUS Server is secured by the shared secret - see http://www.freeradius.org/rfc/rfc2865.html • The communication between the FortiClient and the FortiGate is secured by the VPN connection - see http://kc.forticare.com/default.asp?id=115&Lang=1

Martin, You are going they wrong way FSAE is used for Authentication outbound e.g. users on the inside network that need to authenticated to access resources such as HTTP/FTP and Telnet. You will need to use LDAP RADIUS or local user groups to allow inbound authentication.

I am ver new to this but this is my understanding. The manual says " Users authenticated by Active Directory server do not need local user accounts on the Fortigate unit." And when creating groups you have the option to select from Active Drectory. So you should be able to use the tables that the Fortigate unit pulls from AD thru the FSAE software to authenticate VPN users. Even though the user has not logged into the domain yet the tables are still available on the Fortigate unit. This would allow you to give access to users by just adding them to a AD group instead of manually entering into the Fortigate unit. My problem is that as soon as I enter my AD information into the User->Windows AD page that pages starts giving me an Internet Explorer cannot display the webpage error. Anyone ever have trouble with this?

I dont beleive I was very clear on my explanation. Once i put in my Active Directory information into the User->Windows AD page, everything still works fine, but now the User->Windows AD page now says Internet Explorer cannot display the webpage, but the error is only for the one page, i can still access all of the other setting pages and internet works fine.

I have used the CLI, as soon as I clear the FSAE settings it starts to work again. I have submitted a ticket, hopefully it wont take too long to get a response

I presume you have tried it from another workstations browser? Also, clear out your IE cache, as it may have cached data from a previous firmware GUI.