| Description | This article describes that to authenticate the users via the LDAPS server, FortiGate should make a successful secure connection with the LDAPS server using port 636. |
| Scope | FortiGate, FortiProxy. |
| Solution |
Case 1: Generally, this issue happens when the issuer of the incoming certificate from the LDAPS server to FortiGate in the 'Server Hello' packet is not valid on FortiGate. In this case, it is possible to see the error message 'Alert (Level: Fatal, Description: Unknown CA)' in the PCAP file:
To check the imported CA certificate on FortiGate, run the following command and look for the imported CA certificate:
get vpn certificate ca details
Run the below sniffer command via CLI and then go to LDAPS config on FortiGate and select 'Test Connectivity' to to see the possible reasons for failed LDAPS connection:
diagnose sniffer packet any "host <LDAPS server IP> and port 636" 6 0 l
In this example, it is possible that the issuer of the imported CA certificate does not match the issuer of the certificate coming from the LDAPS server:
get vpn certificate ca details == [ CA_Cert_1 ]
While the issuer of the incoming certificate from the LDAPS server is Fortiservice-UNIVERSE-ESX41-CA <-----
The issue is on the LDAPS server, and the certificate issue should be resolved on the LDAPS server side.
Case 2: If the server is sending an immediate RESET in response to the Client Hello from the FortiGate, it might indicate that the user account is blocked on the AD server. Unblocking the user account on the AD server can resolve the issue.
Related articles: Troubleshooting Tip: Status of LDAP server connected via IPsec VPN shows 'Can't contact LDAP server' |
