FAC: LDAP User Sync not working

[sadmin]

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.

ldap_user_sync logs:

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

[ndumaj]

Hello @sadmin
What is the FAC Sw version?
Are you using LDAP or LDAPs?
If you are using LDAP there shouldn't be any cert issue. If you are using LDAP try to run a PCAP on port 389.
Review the following articles:
https://community.fortinet.com/t5/FortiAuthenticator/Technical-Tip-FortiAuthenticator-remote-user-sy...
https://community.fortinet.com/t5/FortiAuthenticator/Troubleshooting-Tip-How-to-work-with-FortiAuthe...

BR

[sadmin]

Firmware Version v6.4.4, build1028 (GA)
We are using LDAPS

[ndumaj]

"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

[Boxheimer_Corp]

General recommendation:

To troubleshoot, add /debug to the FAC url: https:<FAC-IP>/debug there you may find a clue to the problem.

Marcus

[sadmin]

Unable to add token FTK200BBXXX for remote LDAP user xxx: Unable to retrieve FTK seeds: Problem with SSL communcation layer.

Cannot add user from LDAP server XXX because of this error: Unable to import valid token

LDAP also not working.
Default-Server-Certificate expired and was renewed with a reboot.

[ndumaj]

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.

Also Check if you have enable proxy on FAC?!

BR

[xsilver_FTNT]

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.

[xsilver_FTNT]

Hi @sadmin ,

I do agree that https://FAC-IP-FQDN/debug/ldap_user_sync/ could be more verbose.

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.