Fetching LDAP users during Access Role creation in SmartConsole ends with "Error retrieving results"

[daniel_ranft1]

Hi,

about 10 months ago I've set up Identity Awareness in our production environment, which worked like a charm since about a week or two ago. Now I'm faced with an SSL handshake error that doesn't make any sense to me. The symptoms are absolutely identical to what I found in sk167159 (including the DEBUG logs). Sadly there is no solution at the end of the article, that is anywhere useful.

Also important: I don't use #Quantum Security Management but the common virtual management based on Gaia.

Did someone of you encounter this ever before, or does know what to do?

What I've already tried:

• rebooting my whole environment one by one
• cpca_client set_sign_hash sha256 into cpstop;cpstart
• googling like crazy

What also makes this weird:

• AD-based user authentication for Remote Access also does not work
• I can still use the old SmartDashboard (fwpolicy.exe) to search the AD (works like expected), but not the new SmartConsole
• The AD Query (usernames in log entries) works like it should

Any help is appreciated.

Best regards,
Daniel

Logs ($FWDIR/log/cpm.elg😞

26/04/21 14:31:16,203 DEBUG internal.wrappers.LdapConnectionWrapper [qtp1192021461-72]: Constructing LDAPConnection.
26/04/21 14:31:16,203 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Connection timeout(in seconds): '30'.
26/04/21 14:31:16,203 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Trying to create the SSL Socket factory(have different behaviour depending on the JRE vendor).
26/04/21 14:31:16,203 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Checking if environment variable 'PROPERTY_DEFAULT_SSL_PROTOCOL' defined and not empty.
26/04/21 14:31:16,203 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Environment variable 'PROPERTY_DEFAULT_SSL_PROTOCOL' is not defined.
26/04/21 14:31:16,203 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Creating first SSL socket factory with protocol: 'SSL_TLSv2'.
26/04/21 14:31:16,227 DEBUG internal.wrappers.LdapConnectionWrapper [qtp1192021461-72]: Got result code different from 'ResultCode.SERVER_DOWN(81)', not reconnecting.
26/04/21 14:31:16,228 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Connect error(CONNECT_ERROR), checking if SSL connectivity(I/O) or certificate problem.
26/04/21 14:31:16,228 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Checking if the error is SSLException error.
26/04/21 14:31:16,228 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Error is SSL error, checking if it's SSL handshake error.
26/04/21 14:31:16,228 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Error is SSL handshake error, checking if it's SSL certificate error.
26/04/21 14:31:16,228 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Error is SSL certificate error, checking if it's framework certificate error or ckp error.
26/04/21 14:31:16,228 DEBUG internal.wrappers.SslLdapConnectionWrapper [qtp1192021461-72]: Error is ckp certificate error, forward it to the client.
26/04/21 14:31:19,284 DEBUG internal.wrappers.LdapConnectionWrapper [qtp1192021461-204]: Connection not exist, trying to connect.
26/04/21 14:31:19,284 DEBUG internal.wrappers.LdapConnectionWrapper [qtp1192021461-204]: Trying to connect to the directory according to: com.checkpoint.objects.ldap.connection.internal.properties.QueryAdConnectionDetails {Domain Name='*******', Connection Key='*******', Connection Info list='[]', Directory ID='*******', Username='svccheckpointldap', User DN='CN=*******,OU=Service Accounts,DC=*******', Password='*******', Bind DN='DC=*******', Server name / FQDN='*******', Server IPv4='172.*******', Server IPv6='', Server Uid='*******', Port='636', Use ssl='true', Ui fetch profile ID='*******', Object domain ID='*******', Branches list='[DC=*******]'}.

[_Val_]

Best is to take this to TAC

[Tobias_Moritz]

Can you post the output of

echo | openssl s_client -connect 172.16.1.1:636 | openssl x509 -noout -text | grep "Signature Algorithm"

where 172.16.1.1 is your LDAP server ip (redacted in your debug output)? Has to be done from a machine which can reach the LDAP server of course. If you are using GAIA for that, use cpopenssl instead of openssl.

Then we can see if it is really the issue from sk167159.

[Daniel_Ranft]

Hi,

your reply melped me to understand the issue - i was thinking the client configuration is the issue. Our LDAP-Server uses SHA256 so it is in fact a different issue.

I will follow Val's recommendation and open a case.

Best regards and thanks for your effort

-- Daniel

[GrassF]

Hi,

what was the solution to this issue? Our customer is having the same issue with r80.40.

Thank you

[Daniel_Ranft]

Hi GrassF,

actually i'm not 100% sure. Our issue grew to an almost full failure of AD integration, which we were able to solve by re-fetching the fingerprints of all Domain Controllers in the related LDAP Account Units (Object Browser -> Servers -> ...).

In the end I was angry about myself because this is kind of obvious and is also stated in the Administrators Guide.

-- Daniel

PS: This ended up as a yearly reminder in my calendar 🙂

[_Val_]

@Daniel_Ranft can you elaborate a bit? I think that would help the community to have a more detailed description of the resolution steps

[Daniel_Ranft]

sure...

First of all: This only applies if your domain controllers use LDAPS (LDAP + SSL via Port 636).

Typically the domain controller SSL certificates used for LDAPS are valid for a year. These certificates are used to establish a trust relationship to the Check Point environment.

If these certificates expire and are renewed (most likely without interaction), your firewalls need to know the new fingerprint of the certificates. This is a manual process, that is done for every domain controller.

As mentioned before, you do this in the related LDAP Account Unit object in the Servers tab. For all servers you hit Edit, switch to the Encryption tab and click on "Fetch" next to the old fingerprint. If the fingerprint changes and you install the policy, this might solve all your issues (hopefully).

[_Val_]

Thank you, @Daniel_Ranft 

[GrassF]

Hi Daniel,

thank you for the quick answer. Issue solved 🙂

Thank you

[Egenity]

On sk167159, I may have a customer with this issue.  What did you find as a solution for this?  sk167159 seems to just give you a general brush off and points finger at IBM.  How is a customer supposed to deal with that?  

Any information you can provide on the topic would be useful.

Thanks