LDAP users cannot login to SSL VPN

[Levi]

Hi Folks,

I have an issue with a new SSL VPN on my Fortigate 3240fgt running 5.2.10.  It is set up the same as a working SSL-VPN in a different vdom on the same device.

If I login to the SSL VPN portal using a locally configured user on the Firewall it is succesfull.  However if I try with my AD account it is not succesfull.   Debuging does not even show a single packet trying to reach the domain controller.   But the Test function in the LDAP server section is succesfull (and packets can be seen when debuging).

Next oddity, when using my AD account the username is not propagated into the VPN events log, just user-N/A

But if I try a made up name (that does not have a local PKI user) the username is propagated into the VPN event log.

So it seems to me that after the Firewall confirms the PKI users exists it fails the authentication rather than forwrd the auth to AD.

These SSL VPNs have always been tricky, but I stumpped by this latest issue so would appreciate any assistance

Many Thanks

Levi

[emnoc]

I'm amaze on your diagnostic they are good ;)

Here's what I would do, 

>I would double check the   user group  for any match statements

> I also would double check the config vpn ssl setting and any auth-rules

> ensure the  Base dn search  is correct

[Toshi_Esumi]

One thing I can tell based on a TT with TAC to verify authentication behavior was:

- if a local user with a given name exists, it decides "success" or "fail" based on the config and stops there. Never go to the next step.

- if a local user with a given name doesn't exist and remote authentication servers exist in the policy it tries all of them to see if any one of them gives a "success".

- if none of remote auth servers in the policy gives a "success", goes to the next policy.

TAC said they would document this somewhere since it's not available anywhere.

[emnoc]

Hmm..  I believe it falls the ssl vpn setting authentication rule.

My testing shows if you have a rule preference and match local and the user is local it will pass/fall or local-only

if the rule is remote-auth and it pass|fail it does not fall back to local

e.g

   config authentication-rule             edit 1                 set source-interface "WAN1"                 set source-address "all"                 set groups "RWGRP1"                 set portal "tunnel-access"             next             edit 2                 set users "user1" "user2" "user3"                 set groups "RWGRP1"                 set portal "tunnel-access"             next         end

user1 , 2 & 3 would be authenticated by  rule#2 

[Toshi_Esumi]

In my case, we're not using authentication-rule in ssl settings. We simply put all into one group referred by a policy to be equal to all auth methods. So that's the condition for the behavior I described above. I assumed peer users would behave the same way local users do since it's locally configured.

In any case, we need a better documentation.

[emnoc]

So back to diagnostic,

Can you have a user login and run diag sniffer packet <interface name>  "host <ldap server address>"

Do you see at least a request going out to the ldap-server(s)?

Ken

[Levi]

Thanks for all your responses folks.  I hope to go through them in the next few days,  will report back after

[Levi]

Hi Folks,

I gone through your suggestion without any success as below

> check the config vpn ssl setting and any auth-rules  - Looks ok  

> ensure the  Base dn search  is correct -  Have confirmed this is correct.  Can succesfully test poll AD to confirm and see the packets in debug

> I tried removing the local users from the user group, which left only the AD group in it  (also added the PKI users to the user to no avail).  This gave the same results as before (ie auth failled, no packets to AD server on debug and user N/A on event log.

- for local user with existing name - succesful login

- for local user that doesnt exist, but has PKI and is in AD - not succesful, no debug packets to LDAP server

Many Thanks

[Levi]

Further update

I found a difference between my work SSLVPN and the new one.   The working one does NOT have "Require Client Certificate" selected.   Whereas the new one does,  both should have it enabled as part of 2 factor auth.

So now my question is why does the Fortinet fail to try and contact the LDAP server to auth the user after the client cert auth is successful (message in log is "SSL new certificiate verification success").

Thanks Again

[emnoc]

- for local user that doesnt exist, but has PKI and is in AD - not succesful, no debug packets to LDAP server

Can you explain the above? Can you provide a redacted output of the config  ( show user ldap  &  show user group ) ?

If your doing 2factor, and the 1st factor is the "user authen against AD " than that should generate traffic even if it's a failure.

The working one does NOT have "Require Client Certificate" selected.   Whereas the new one does,  both should have it enabled as part of 2 factor auth.  

If your doing client-side PKI that's afunction of the   SSL and setting and has nothing todo with LDAP directly, BUT if the client PKI is not correct we would not  even attempt 1st or 2nd factor.

So further  extract the confusion is the problem 1>  PKI  and client-requires SSL or 2> LDAP query ?

Do this to to eliminate the;

1: run the sslvpd daemon in debug mode

2: enable  client- side cert required in the SSL vpn setting

i.e

config vpn ssl settings       set force-two-factor-auth enable

            config authentication-rule                  edit 1

                    set client-cert enable   <------IMPORTANT

             end

3: test 1st with a  local-user and local-password

4: if that passes, test again but with user set for "type ldap" and correct ldap server cfg, does it pass ?