Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Gold

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

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

15 Replies
Highlighted
Employee+
Employee+

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 

Highlighted

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.
Regards, Maarten
0 Kudos
Highlighted
Employee+
Employee+


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.

Thanks,
Royi Priov
Group manager, Identity Awareness R&D
0 Kudos
Highlighted

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.
Regards, Maarten
0 Kudos

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

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

0 Kudos
Highlighted
Gold

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.

LDAP1.png

 

 

 

 

 

 

 

 

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

0 Kudos
Highlighted

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!

Highlighted
Employee+
Employee+

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.

Thanks,
Royi Priov
Group manager, Identity Awareness R&D
Highlighted
Silver

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...

0 Kudos
Highlighted

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.

Highlighted
Silver

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?

0 Kudos
Highlighted

Highlighted

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. 

Tags (2)
0 Kudos
Highlighted
Ivory

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.

0 Kudos