Identity Collector - LDAPS

[Magnus-Holmberg]

Hi,

When checking SK108235 for ports.

Communication Protocols

Direction	Port	Protocol
Identity Collector to Identity Awareness Gateway	443	Proprietary Check Point protocol, over HTTPS. Used for ongoing communication between the Agent and the Security Gateway.
Identity Awareness Gateway to Domain Controller	389 / 636	LDAP / LDAPS
Identity Collector to Domain Controller	53	DNS
*Identity Collector to Domain Controller	389	LDAP
Identity Collector to Domain Controller	135, and dynamically allocated ports	DCOM protocol, which makes extensive use of DCE/RPC.
Identity Collector to Cisco ISE	5222	Session subscribe. Gets notifications of new login/logout events.
Identity Collector to Cisco ISE	8910	Bulk session download. Fetches all the active sessions from the ISE Server.

* Note: LDAPS is also optional (through port 636) when using "NetIQ eDirectory". For all other uses (which are the most common ones), we are using LDAP only. 



I dont see LDAPS, 636 for standard Microsoft AD. not sure what this NetIQ eDirectory is.
When is LDAPS 636 comming for IA if its not already present, (if so i dont see where to change it in the GUI)

Regards,

Magnus

[PhoneBoy]

I believe it's configured on the relevant LDAP Account Unit object.

[Magnus-Holmberg]

Within smartconsole, yes sure.
But the Identity collector you dont have any options like that.

And Microsoft is pushing pretty hard to remove LDAP for LDAPS, 

[PhoneBoy]

I'm guessing Identity Collector will try both LDAP and LDAPS but maybe @Royi_Priov can confirm.

[Royi_Priov · Accepted solution]

Hi Magnus,

LDAP is used on Identity Collector in 2 ways:

1. AD integration - only for discovering the AD servers in the environment. After this discovery, the entire communication is done securely with Microsoft API. The discovery itself is performed with LDAP (not LDAPS).
2. NetIQ eDirectory - this is an LDAP server by NetIQ, which we are communicating over LDAP / LDAPS all the way for fetching logged in users.

Thanks,

Royi Priov.

[Val1976]

Hi Royi

I have a customer that is exactly in the same situation, trying to move away from AD query and use Identity Collector... As the AD environment is configured to allow only LDAPS connections, the initial test connection to and AD server, using plain LDAP is unsuccessful and the  migration cannot progress further...

Is there any way of forcing the initial test connection to use LDAPS instead of LDAP? The customer has downloaded and installed the latest version of the Identity Collector software - R81.040.0000 / 20 Sep 2022...

Thanks and best regards,

Valeriu

[Zolo]

Hi Valeriu,

You can connect to the "Active Directory" LDAPS server if the LDAPS certificate contains the IP address of the DC in the SAN field.

Click New Source > Active Directory > Fetch Automatically and choose LDAP over SSL.

The IC only accepts IP address and the DC IP address must be entered.

Br,

Zolo

[Jöran_Kaußel]

Hello Check Mates,

any tipps for those whose PKI does not support IPs in SAN field?

Any help appreciated,
Jöran

[PhoneBoy]

Upgrade to R82 when it's available as the validation mechanism for the LDAPS certificate will change.
Instead of validating the existing certificate, we'll ensure the certificate is valid and signed by a specific CA.

[Zolo]

Hello Jöran,

Good news 😀

As I checked, the latest IC version (R81.069.0000) finally supports FQDN.

Br,

Zoli

[Jöran_Kaußel]

Hello Zolo,

unfortunately I can't confirm. Using R81.069.0000 throughout the currently running DC migration to Windows Server 2022 I can only fetch them via the remaining 2016 DCs, not directly. And then I can't get them connected neither via IP, nor hostname or FQDN.

Fetching via IP works instantly while hostname and fqdn needs about 30 secs.

Error states "Unable to connect; please check connectivity with server and server firewall configuration". I can see tcp/udp 389 but no 636. Nothings getting dropped, tried debug options via regedit but got not significant more info other than "ErrCode (1722)" which seems to be a dead end.

Any tipps appreciated
Jöran

[Jöran_Kaußel]

Hello mates,

sorry for the noise. DCs local firewalls refuse to answer to RPC when freshly deployed. Problem solved from my side.

Thanks