LDAPS issue, 'Can't contact LDAP server'

[aw-sysadmin]

I am trying to enable LDAPS on our Fortigate 60F. We currently have LDAP to a DC working, but when I enable LDAPS over port 636 and click 'Test Connectivity' I get the error message 'Can't contact LDAP server'. This is before selecting a certificate.

I have imported a certificate from the Microsoft Intermediate CA in our domain, tried binding that to the setting but get the same error. I ran a packet sniffer to confirm the Fortigate is sending and receiving traffic to the DC over port 636.

I also ran ldp.exe to the DC over port 636 and the connection was successful.

What else could cause the error message? Any advice would be helpful as I am new to Fortigate administration, thank you.

[dbhavsar]

Hi @aw-sysadmin ,

- Also make sure your windows defender is turned off or if you have turned it on make sure you have allowed rule for that port.

[aw-sysadmin]

I have added inbound rules on Windows Defender Firewall on the DC for ports 389, 636, and 3269. I also ran the packet sniffer from the Fortigate and traffic was sent and received from the DC over port 636

[akanibek]

Could you make a packet capture with some debugs on FGT enabled, and compare outputs. Which device does terminate connection? Maybe you could see some errors from debugs:

1. packet capture between FGT and DC.

2. debugs:

diag de reset

diag de app fnbamd -1

diag de console time enable

diag de enable

***To stop debugging:

diag de disable

3. Reproduce the issue several times, compare outputs. you can share outputs in the forum as well.

[pminarik]

The typical low-hanging-fruit explanations of LDAPS not working (but plain LDAP being fine) are:

- configured server address not matching the identity of the server certificate (cert must include FQDN or IP in its SAN field, FGT must use one of these values in its config)

- wrong CA imported and/or selected

- intermediate CA missing (assuming a chain like: rootCA -> intermediateCA -> LDAP-server-cert; the intermediate is neither sent by the LDAP server during TLS handshake, nor is it imported into the FGT, thus validation cannot succeed)

- maaaaaybe MTU/MSS issues (certificates in TLS handshake might push frame size into the territory of fragmentation-related issues). Unlikely to be relevant on a local network, potentially worth investigating if the traffic gets encapsulated at any point on the path (IPsec, VXLAN, etc.)

- "legacy issues" such as server cert, or intermediate CAs, using outdated crypto (e.g. SHA1 signatures). This could potentially happen with old MS AD Certificate Authorities if nobody bothered updating their certificate templates.

fnbamd debug should tell you more, as already noted. A look at a packet capture of the connection attempt can also help (as long as it isn't TLS 1.3, which doesn't send certificates in plaintext)

[aw-sysadmin]

Thanks for the reply, I posted a reply to another comment that enabling LDAPS (without certificate) is working now, the error message was caused by a bug in the GUI. However, I am still getting the error message when I select the certificate.

The certificate I am using was exported from the Intermediate CA (Microsoft CA) server (not the LDAP server) on our domain. The Root CA is offline. I read on another forum that importing this certificate will then allow the firewall to trust all domain server certificates signed by that CA.

Do I need to import and bind a certificate from the LDAP server (Domain Controller) as well?

When I try to import the Domain Controller certificate, I get the error 'Certificate file is duplicated for CA/LOCAL/REMOTE/CRL cert.'

[dbu]

You can try delete the previously imported certificate on FortiGate and re import this certificate. 

[pminarik]

The bare minimum to import is the root CA + any intermediate CAs that are not sent by the LDAPS server during the TLS handshake. (= everything needed to reconstruct the chain of trust from the server certificate up to the trusted root)

In the LDAPS config on the FGT, you can then select any CA in the chain (root or any intermediates) for the trust to work.

The LDAP sever's certificate is not needed or expected to be imported for LDAPS to work.