Microsoft forces LDAPS march 2020, is Check Point aware of this

[Wolfgang]

Hello,

starting march 2020 Microsoft forces the use of LDAPS only for connect to ActiveDirectory

2020 LDAP channel binding and LDAP signing requirement for Windows  

I think there are some changes needed in the product. You can configure the LDAP-connection to AD with LDAPS, this works and is recommended. But there are still some feature they are using LDAP:

- first time wizard if enabling MOB or IA (gateway tries to connect to domain controller via LDAP not LDAPS)

- browsing ActiveDirectory (looks like problem from sk120669 is still active in R80.30)

Any statement from Check Point about this?

Wolfgang

[Ilya_Yusupov]

Hi,

please refer to sk164834 the solution is written in this SK.

if any further questions are needed you can contact me directly.

Thanks,

Ilya 

[Maarten_Sjouw]

The referred SK only shows how to work around the IA FTW, not the browsing problem.
Other question on the same subject, is the rpoblem of using different IP's resolved while using a domain with IA?
I know in R80.10 that the browsing through the AD was using the IP of the Domain but while adding an access-role the MDS main IP was used instead. I would have to check if this is now resolved.

[Royi_Priov]

---

Hi @Maarten_Sjouw ,

I will appreciate if you could elaborate about your questions.

---

@Maarten_Sjouw wrote:
The referred SK only shows how to work around the IA FTW, not the browsing problem.

---

Which browsing problem?

---

@Maarten_Sjouw wrote:
Other question on the same subject, is the rpoblem of using different IP's resolved while using a domain with IA?

---

Can you please elaborate?

Thanks,

Royi Priov

Identity Awareness R&D.

[Maarten_Sjouw]

as @Wolfgang mentioned:
-browsing ActiveDirectory (looks like problem from sk120669 is still active in R80.30)
In R80.10 I had issues with the connection to the AD server, while trying to add a access-role the connection was initiated from the IP of the MDS, while when you click Fetch Branches in the LDAP Account unit, the IP of the CMA was used.

[Maarten_Sjouw]

Ok, I double checked this and yes the MDS IP still shows up in the logs when you work on the LDAP account unit.

[Wolfgang]

I checked too some things they don't use LDAPS.

1. creating a new LDAP-Account-Unit via the MobileAccess- or IdentityAwareness-wizard fails if you don't allow LDAP on port 389 from the gateway. 

2. Browsing through the LDAP-directory via Smartconsole fails if you don't allow LDAP on port 389 from the machine running the Smartconsole. There is an unencrypted LDAP-connectivity needed on port 389 between Smartconsole machine and the LDAP-server.

Problem is still in R80.30 Jumbo_111

Wolfgang

[Wolfgang]

Ilya,

after some research I found one thing which is using LDAP via TCP/389, which should be solved.

If you add user certificates like shown in the screenshot, the host running Smartconsole initiate a LDAP connection via TCP/389 to the LDAP-server. Regardless the LDAP-AccountUnit is configured to use LDAPS.

The browsing problem does no more exist. Adding users or machines to an access roles is done via a LDAPS connection from SMS to LDAP-server. Only browsing through the LDAP-AccountUnit via old SmartConsole is done via the host running SmartConsole and LDAP on TCP/389. But there is no more need for this for me.

Wolfgang

[Norbert_Bohusch]

Another big pain point in using LDAPS for Account Units is the fingerprint fetch. 

If you forget it, everything related to it is broken (IA, RA-VPN).

It would be nice to import CA chain to trust LDAPS instead of manual fingerprint fetching!

[Royi_Priov]

Hi @Norbert_Bohusch ,

I totally agree.

We already have plans on our road map to add this functionality.

Please ask your local office to open an RFE ticket for this, so we will be able to track this request.

Thanks,

Royi Priov

Identity Awareness R&D.

[phlrnnr]

You don't have to fetch fingerprints for it to work.  LDAPS will work without fetching the fingerprint, it simply won't validate the fingerprint.  If you fetch fingerprints, and all the servers have incorrect fingerprints, then it will fail.

I'm not sure if that will change with the Microsoft 2020 requirement listed in this thread...

[GrassF]

Hi,

I'm having the issue describe in sk156853 - getting error: "An error was detected while trying to authenticate against the AD server. It may be a problem of bad configuration or connectivity."

The solution in sk156853 is to malually fetch the fingerprint. After reading your comment I'm concern about this solution. Any recommandation? We are Running R80.40

[Wolfgang]

@GrassF 

you have to fetch manually or remove the fingerprint.

If you remove the fingerprint and don‘t adding again this is working fine but you have no validation with the LDAP servers certificate.

Wolfgang

[PatrikSkoglund]

Just to add a clearification. It's not LDAPS(LDAP over SSL) Microsoft is enforcing, it's signed LDAP. But the work-around is to use LDAPS with Check Point.

[phlrnnr]

If using LDAPS, does the fingerprint verification have anything to do with this?  If I am using LDAPS already, but ignoring the fingerprint verification, will this still work after Microsoft's March patches are deployed?

[Tommy_Forrest]

Microsoft has backed off on forcing signing.

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

[SneakyPete]

Hi. Same here... the "Fetch" function seems to be a "randomizer". It did not work for me either. (R80.30)

I was looking for that cert that the "fetch" function was finding (thumbprint), but could not find such cert on the pointed Domain Controller. (But can't rule out that there is something in the process I'm not doing correctly)

Thanks for pointing it out. 

I had better success by just getting the correct certificates "thumbprint/fingerprint" from the Domain Controller and copy/paste it to the field. 

[pinball]

Did you ever figure this out? We also had some issues with the fetch... and the thumbprint that checkpoint fetched doesn't match up as to the cert on the DC...The thumbprint changed.. and broke IA/endpoint vpn connectivity.

[SneakyPete]

Hi... just a quick note.

I was using non-supported PKI certificates. I re-did the whole PKI and now were only issuing certs for the computers that uses "Signature algorithm" SHAxxxRSA" (the xxx meaning how big large the signature should be).

Now we have on:

RootCA SHA512RSA

Intermediate Issuing SHA384RSA

End-device SHA256RSA

Once the signature algorithm was changed and I installed the new certificates to DC (domain controllers) the "fetch" automatically got the correct cert for the function. I think Check Point uses some Java 7 code in the background for that function, and this version of Java only supports a handful of "signature algorithms". But anyway, this was the silver bullet in our case.

Hope this helps.

Sneaky

[JustTesting]

I came across the same thing while troubleshooting AD authentication errors today, where the fingerprints I was fetching didn't match any certificates on the domain controllers. It turns out that the fingerprint being fetched by SmartConsole is in MD5 format.

The best way I found to figure out which cert is being presented for LDAPS and what the 'Fetch' button should be getting is:

1. To fetch the cert being presented for LDAPS, use openssl s_client -connect <hostname>:636
2. Copy the -----BEGIN CERTIFICATE-----...-----END CERTIFICATE----- block into a text editor and save as .der (you can then open the cert to view it if you'd like)
3. To calculate the MD5 fingerprint of the cert, use openssl x509 -noout -fingerprint -md5 -inform pem -in c:\temp\cert.der

The MD5 fingerprint calculated here should match the fetched value within SmartConsole.