FortiGate.
Solution
<LDAP server_name> = the name of the LDAP object on FortiGate (not the actual LDAP server name).
Any username and password combination from the AD can be used, but it is recommended (at least at the first stage) to test credentials used in the LDAP object itself.
If these credentials fail then any other will fail as well as the FortiGate will not be able to bind to the LDAP server.
CLI example:
diagnose test authserver ldap LDAP_SERVER user1 password
Advanced troubleshooting:
To get more information about the reason for authentication failure, run the following commands from the CLI:
diagnose debug enable
diagnose debug application fnbamd 255
To stop this debug type:
diagnose debug application fnbamd 0
Then, run an LDAP authentication test:
diag test authserver ldap AD_LDAP user1 password
Based on the Fnbamd output, ssl negotiation errors should appear.
This means that the LDAPS TLS negotiation is not working properly.
This can be checked with a sniffer to see which TLS version is presented by the LDAP server using the following command:
diag sniffer packet any ‘host <LDAP server> and port 636>' 6 0 a
For example, if the LDAP server is presenting TLS1.0 (windows 2008) and the FortiGate is using version 6.2.x, the TLS negotiation will not work.
The following command under the LDAP config will fix this issue:
config user ldap
edit <LDAP entry>
set ssl-min-proto-version TLSv1 <----- This version depends on the TLS version used by the LDAP server.
next
end
From FortiOS V7.2.0, the LDAP server configured on FortiGate can authenticate it with client certificate to LDAP server.
config user ldap
edit <ldap_server>
set client-cert-auth enable
set client-cert <FGT_CERT_NAME>
next
end
Refer to the following document for information:
https://docs.fortinet.com/document/fortigate/7.2.0/new-features/33548/configuring-client-certificate....
If LDAP authentication is working fine locally from the FGT, but the user still getting issues connecting the firewall using SSL VPN. Share the output of the below debug command with TAC by reproducing the issue:
diagnose debug disable
diagnose debug reset
dia debug console timestamp enable
diagnose vpn ssl debug-filter src-addr4 < user PC public IP >
diagnose debug application sslvpn -1
diagnose debug application fnbamd -1
diagnose debug enable
It is possible to verify the user group and portal mapping with the below command:
get vpn ssl monitor