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
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
PCNSE
NSE
StrongSwan
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.
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
PCNSE
NSE
StrongSwan
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.
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
PCNSE
NSE
StrongSwan
Thanks for all your responses folks. I hope to go through them in the next few days, will report back after
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
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
- 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 ?
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1632 | |
1063 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.