Explorer

Question

LDAPS issue, 'Can't contact LDAP server'

Forum|Forum|2 years ago
April 25, 2024
16 replies
15934 views

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.

funkylicious

SuperUser

I think that you need the server certificate of the AD server, exported and imported on the FGT and that should be selected as cert to secure the connection to the AD over 636.

As per, https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-LDAP-over-SSL-LDAPS/ta-p/189972 ,

Configure LDAPS on the Microsoft Windows Certificate Authority server:

"jack of all trades, master of none"

aw-sysadminAuthor

Explorer

From another forum post, I read that enabling LDAPS without defining a cert will still work, and that an error at that stage indicates a problem connecting to the LDAPS server over port 636, before indicating it's a problem with the certificate. However, I tried selecting the cert (exported from Intermediate CA) to secure the connection as well, and got the same error

dbu

Staff

Yes it is correct that LDAPS can work without defining a certificate.
Can you share output of command :

config user ldap

edit "LDAP"

show

dbhavsar

Staff

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-sysadminAuthor

Explorer

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

Staff

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

Staff

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-sysadminAuthor

Explorer

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.'

2024-04-26 15_48_41-Remote Desktop Manager [SVWFG-ITutil01].png