R82 + Windows Server 2025 – LDAPS Connection Fails

[ghosty]

Hi,

In my lab environment I'm running:

• Check Point R82 – Build 151

• Distributed deployment

• Windows Server 2025

• LDAPS (port 636)

• AD CS Enterprise Root CA

Working:

• Port 636 reachable

• I can browse AD structure in SmartConsole

Failing:

• Connection attempts fails with:
  “Gateway could not connect to… Credentials are valid, but LDAP communication with the server failed.

I have done the solution steps in sk164834.

On both SMS and Gateway:

cpopenssl s_client -connect DC_FQDN:636

Returns:

Verify return code: 21 (unable to verify the first certificate)

Question:

Is anyone able to replicate this behavior on R82 with Windows Server 2025?
Any tips on additional troubleshooting steps would be appreciated.

Thanks.

[the_rock]

@Vincent_Bacher 

I believe you may had mentioned in one post you had this windows server 2025 in the lab? Apologies if I am mistaken. I spoke to Casper about this yesterday, but we dont sadly have that image in the lab, so cant set one up to test. Based on remote we did, Im 99.99% sure it is something on that server causing an issue, as we dont even see any drops or traffic even hitting the firewall. We even disabled native windows fw on the server, no joy.

[Vincent_Bacher]

No I just suggested some debugs.

Any news about the issue ?

[the_rock]

Got it, sorry, my bad then. 

@ghosty , here is IA debugs I got from TAC while back.

# cd $FWDIR/log
# rm pdpd.elg.*
# echo "=debug_start=" >> $FWDIR/log/pdpd.elg
(•) To turn pdp debug on:
# adlog a d on
# pdp debug on
# pep debug on
# pdp debug set all all
(•) Replicate the issue
(•) To turn them off:
# adlog a d off
# pdp debug unset all all
# pdp debug off
# pep debug off
# pdp d reset
# pep d unset all all
Collect debug:
$FWDIR/log/pdpd.elg
# tar zcvf pdpd_debugs.tgz pdpd.elg*
# tar zcvf pepd_debugs.tgz pepd.elg*

[Vincent_Bacher]

consider increasing the debug file size and number of rotations 

[the_rock]

Yes, good point, Vince.

[Chris_Atkinson]

Please confirm the Jumbo take applied to the MGMT / gateways and version of IDC if used etc.

[ghosty]

Just running the base version atm.

[Lesley]

Never good idea to run base version without jumbo take. What about IDC? Or you use AD query? Are you able to fetch the fingerprints and branches in the ldap account unit? 

[the_rock]

Not sure if thats even related, but nevertheless, I always install latest jumbo in my lab the day it comes out.

[Vincent_Bacher]

Is this question "Are you able to fetch the fingerprints and branches in the ldap account unit? " answered?
And are the debugs collected?

Asking because in pdpd.elg you can clearly see all details about ldap communication and due to the error message in the starting post i would says pdpd.elg will be helpful to see any hints.

[ghosty]

Yes, fetch is working.

Debug files are attached.

[Vincent_Bacher]

Strange, I don't see any log lines related to any communication to a device inside the logs, neither in pdp nor in pepd logs.
For AD query there should be at least a hostname or IP in the logs. Nothing.
Did you really replicate the issue after turning on the debugs?

Thanks

[ghosty]

I did. But I now tried with IDC instead, and it works like a charm, so I'm gonna use that instead.

[Vincent_Bacher]

Yes, IDC is a valid option 👍

[the_rock]

100%, definitely way more preferred one today.

[Vincent_Bacher]

But pdp debug analysis ist an interesting use case for a tool 🙂

[ghosty]

I upgraded to take 73. Same issue still, unfortunately.

I'm using AD query.

Fetch works.

[Lesley · Accepted solution]

Move away from AD query and use IDC instead:

As part of Check Point's response to CVE-2021-26414, "Windows DCOM Server Security Feature Bypass", Check Point recommends to use Identity Collector as the Identity Source instead of AD Query. For more information about Check Point's response to CVE-2021-26414, see sk176148.

In the October 2022 Windows update (KB5018411/ KB5018419), Microsoft made changes to read privileges that affect AD Query from an Identity Awareness Gateway to a DC. If AD Query is configured for a DC user who is not an admin (see sk93938), AD Query cannot access the DC. For customers with such a configuration, Check Point recommends to use Identity Collector as the Identity Source instead of AD Query. For more information and workaround procedures, see sk180232.

[the_rock]

I made it work with AD query though.

[Lesley]

It can work of course. But if every document states IDC is the way the go and recommended I would stay away from it. From security point of view but also performance. ADquery loads the gw unnecessarily. 

[the_rock]

I totally agree. Just in this context, I would like to make it work for Casper using AD query.

[ghosty]

Thanks for this information. I tried with IDC instead, and it works like a charm.

[the_rock]

Glad you got it working!

[the_rock]

@ghosty I did want to mention IDC to you, but glad @Lesley brought it up. I figured we could make it work with AD query, but he is 100% right, IDC is way better method these days.

You can read all about it in below post and discussion we had about it back in the day.

https://community.checkpoint.com/t5/Firewall-and-Security-Management/New-IA-Implementation/m-p/18585...

[the_rock]

Well, you are in luck, my friend. I just checked and looks my colleague did upload windows 2025 image, so give me some time, will let you know in 1 hour tops if it works or not.

[the_rock]

@ghosty 

Just set it all up, rebooted, disabled windows fw, exact same issue as you...let me keep working on it and see if I can fix it.

[the_rock]

I tested with any any allow rule, got exact same issue like you did Casper when we did remote yesterday, so thats how Im 100% sure its windows issue.

Here is what I ran to make it work (found this after 10 mins on Google lol)

netsh advfirewall set allprofiles state off

[ghosty]

This did not solve the issue for me, unfortunately.

[the_rock]

I did reboot after doing it, mind you.