Description
This article describes how to overcome the LDAPS TLS issue while using SSLVPN especially after upgrading the FortiGate.
Solution
To test the LDAP object and see if it's working properly, use the following CLI command:
#diagnose test authserver ldap <LDAP server_name> <username> <password>
Note :
<LDAP server_name> = name of LDAP object on FortiGate (not actual LDAP server name!).
For username/password, use any from the AD, but it is recommended (at least at the first stage) to test credentials used in the LDAP object itself.
If this credentials will 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 regarding the reason of 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
And then run an LDAP athentication 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 and see which TLS version is presented by the LDAP server using the below 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:
