LDAP User Sync not working anymore. Under LDAP Server Settings there is an expired Default-Server-Certificate. Renewed the Default-Server-Certificate with a Reboot. LDAP User Sync still not working.
Time (local) = Wed Sep 6 15:54:21 2023 CEST IDs of rules to be synchronised for table ldap_ldapusersync = 3 2 Received notification for table ldap_ldapusersync from Postgres - Waiting for data on socket Received notification for table ldap_ldapusersync from Postgres - Waiting for data on socket Time (local) = Wed Sep 6 15:59:21 2023 CEST IDs of rules to be synchronised for table ldap_ldapusersync = 3 2 Received notification for table ldap_ldapusersync from Postgres - Waiting for data on socket Received notification for table ldap_ldapusersync from Postgres - Waiting for data on socket
"LDAP Sync" log should provide more information. Was the LDAP sync rule worked before? Did the issue appear after any upgrade or any change on your network? Can you test with LDAP in order to exclude certificate issue? BR
Hello, Regarding issue: Unable to add token FTK200BBXXX for remote LDAP user xxx: Unable to retrieve FTK seeds: Problem with SSL communication layer. Please check the connectivity between FAC and following directions: directregistration.fortinet.com ftc.fortinet.com
Check on edge firewall for any deep inspection or other security policy applied recently. FAC should be able to reach Fortiguard servers to activate the Tokens.
Hi @sadmin , "Problem with SSL communcation layer.
Default-Server-Certificate expired and was renewed with a reboot. " Not quite sure which cert was renewed. However above claims seems to me more like there is invalid cert somewhere. If LDAP server cert was renewed, then Remote User Sync uses underlying Remote Auth, Servers / LDAP config. And if that one has "Secure Connection" enabled, then check if new LDAP server cert was signed with CA set there. If you got even further and "Use Client Certificate for TLS Authentication" is in place, effectively enforcing not just ANY cert signed by CA but specific cert presented by "client" which is your LDAP server, then check if that is set to renewed cert.
Another possible issue might be some MitM actor, like SSL Deep Inspection on any of your intermediate firewalls between FAC and LDAP server. As that SSL/TLS inspection needs to decrypt traffic to be able to see and inspect what's inside, it then needs have encryption keys and way to do so is to step into stream and introduce its own CA. So server->decrypt->inspect->encrypt->Client kind of operations. If Server or Client does cert inspection and knows what is supposed to be present by counter-party, then certificates messed by inspection are detected and such communication is then assumed as being hijacked (insecure) and is terminated.
But those messages about waiting for data does not means there was an issue. You can trigger/enforce sync manually and observe result right on page:
And result is also expected to be seen in normal Log section.
Unless there are no issues the /debug should not be needed.
In case of issues I'd recommend to do packet capture to see if there are any issues on TLS layer. And if you are able to either decompose TLS (a bit tricky), or simply switch from LDAPS to LDAP temporarily, then you could see LDAP communication in tools like Wireshark in plain. That should disclose if search filter was OK, what was query and result returned by LDAP server. Logs on LDAP server side might help as well.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.