CheckPoint Identity Collector requires NTLM? Does not use Kerberos?

[David_Herselman]

We have made good progress on depreciating all versions of NTLM in our environment. With us getting assistance from Microsoft premier support, from a non-public knowledge base article, we were able to migrate AD CS (Active Directory Certificate Services) over to Kerberos as well for automated certificate enrolment interactions.

CheckPoint identity awareness is now the last remaining item in our environment which appears to break when we disable NTLM completely. Surely CheckPoint, as a security focused vendor, have a method for gateways to retrieve the security event logs without relying on NTLM?

Group Policy (GPOs) are applied to members servers and workstations to disable NTLM:

This then breaks CheckPoint Identity Collector, unless we apply the following policy just to the DCs (whilst continuing to apply the above policy to the dedicated Windows Server 2022 host running Check Point Identity Collector v81.035.0000). The following GPO is exclusively applied to our Domain Controllers:

With this applied everything works perfectly:

Wanted to reach out to the community before opening a case with TAC, we have Kerberos AES integration working between the gateways and the DCs, it's purely the Identity Awareness application which does not appear to provide support for Kerberos.

Edit:

My unenlightened understanding is that the DCOM call from the Identity Collector to the DC isn't using NTLM, otherwise it should have been blocked by the GPO blocking any and all NTLM. I thus presume the NTLM auth is within the LDAP TLS tunnels to the individual DCs then.

Problem currently is that the NTLM auth doesn't originate from anywhere, we can't even lock down NTLM by adding an exception via the 'Network security: Restrict NTLM: Add server exceptions in this domain' GPO.

Herewith a sample:

NTLM server blocked audit: Audit Incoming NTLM Traffic that would be blocked
Calling process PID: 4
Calling process name:
Calling process LUID: 0x3E7
Calling process user identity: REDACTEDDC01$
Calling process domain identity: REDACTED
Mechanism OID: 1.3.6.1.4.1.311.2.2.10

Audit NTLM authentication requests to this server that would be blocked if the security policy Network Security: Restrict NTLM: Incoming NTLM Traffic is set to Deny all accounts or Deny all domain accounts.

If you want this server to allow NTLM authentication, set the security policy Network Security: Restrict NTLM: Incoming NTLM Traffic to Allow all.

[David_Herselman]

No change in behaviour after upgrading to v81.040.0000 (released the 22nd of September 2022).

[G_W_Albrecht]

Did you involve TAC yet ?

[the_rock]

Maybe @PhoneBoy can confirm for you, but I dont see any options for Kerberos when I looked at my lab for IDC.

[PhoneBoy]

There’s a couple of SKs that mention NTLM and Identity Collector:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

As far as doing it without NTLM, I’ll have to defer to R&D if that’s currently possible or if it’s an RFE. @Royi_Priov 

[David_Herselman]

The frustration with this currently is that we have to leave NTLM enabled in the domain globally and can't simply define the system running the Identity Collector as an exception. I did however manage to find a way to export and filter the security events to get examples of the NTLM based authentication request that's occurring over the LDAPS (yes, TLS encrypted) connection:

   4624, DC03.redacted, 01/20/2023 10:35:55, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x2249854a 3 Kerberos Kerberos - {2e8bcb9a-5b4f-0d50-6ed1-20c55870b16a} - - 0 0x0 - 192.168.230.2 54584 %%1833 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:53, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x2249806e 3 Kerberos Kerberos - {57c56588-a70a-0182-d2e7-9c7d41bdc4a5} - - 0 0x0 - 192.168.230.2 54580 %%1840 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:53, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x22498040 3 Kerberos Kerberos - {57c56588-a70a-0182-d2e7-9c7d41bdc4a5} - - 0 0x0 - 192.168.230.2 54578 %%1840 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:53, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x22497f2f 3 Kerberos Kerberos - {57c56588-a70a-0182-d2e7-9c7d41bdc4a5} - - 0 0x0 - 192.168.230.2 54577 %%1840 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:53, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x22497f05 3 Kerberos Kerberos - {57c56588-a70a-0182-d2e7-9c7d41bdc4a5} - - 0 0x0 - 192.168.230.2 54574 %%1833 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:53, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x22497e6e 3 Kerberos Kerberos - {57c56588-a70a-0182-d2e7-9c7d41bdc4a5} - - 0 0x0 - 192.168.230.2 49687 %%1840 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
4> 4624, DC03.redacted, 01/20/2023 10:35:53, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14289 checkpointidcollect DOMAIN-01 0x22497dd7 3 NtLmSsp NTLM FWCP-IDCOLLECT {00000000-0000-0000-0000-000000000000} - NTLM V2 128 0x0 - 192.168.230.2 54566 %%1833 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
3> 4624, DC03.redacted, 01/20/2023 10:35:53, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14289 checkpointidcollect DOMAIN-01 0x22497da6 3 NtLmSsp NTLM FWCP-IDCOLLECT {00000000-0000-0000-0000-000000000000} - NTLM V2 128 0x0 - 192.168.230.2 49717 %%1833 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
2> 4624, DC03.redacted, 01/20/2023 10:35:53, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x22497c58 3 Kerberos Kerberos - {4434cb5d-84fc-7e9e-aa6a-9e0323176c38} - - 0 0x0 - - - %%1840 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
1> 4624, DC03.redacted, 01/20/2023 10:35:52, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x2249761d 3 Kerberos Kerberos - {2e8bcb9a-5b4f-0d50-6ed1-20c55870b16a} - - 0 0x0 - 192.168.230.2 49701 %%1833 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:51, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x22497603 3 Kerberos Kerberos - {2e8bcb9a-5b4f-0d50-6ed1-20c55870b16a} - - 0 0x0 - 192.168.230.2 49697 %%1833 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:51, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x224975e2 3 Kerberos Kerberos - {2e8bcb9a-5b4f-0d50-6ed1-20c55870b16a} - - 0 0x0 - 192.168.230.2 49677 %%1833 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:51, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x2249752a 3 Kerberos Kerberos - {d5bc5d2a-1314-a8cf-94c6-df1ee47d08a1} - - 0 0x0 - 192.168.230.2 49687 %%1840 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:51, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x22497368 3 Kerberos Kerberos - {2e8bcb9a-5b4f-0d50-6ed1-20c55870b16a} - - 0 0x0 - 192.168.230.2 49692 %%1833 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)
   4624, DC03.redacted, 01/20/2023 10:35:50, S-1-0-0 - - 0x0 S-1-5-21-3939028960-2985278838-3069617384-14790 FWCP-IDCOLLECT$ REDACTED 0x22497344 3 Kerberos Kerberos - {2e8bcb9a-5b4f-0d50-6ed1-20c55870b16a} - - 0 0x0 - 192.168.230.2 49688 %%1833 - - - %%1843 0x0 %%1843,(System.Diagnostics.EventLogEntry.message)

The Kerberos requests appear to be from the system itself checking in to the DC after the VM was restarted. This VM runs nothing besides the Identity Collector. Events 3 & 4 are the ones that originate from the Identity Collector:

Events 4 & 3 generate the following event log entries in Microsoft-Windows-NTLM/Operational:
PS: Events 4 & 3 generate the exact same NTLM operational log entries so only one example is shown:

Source: NTLM
Logged: 2023/01/20 10:35:53
Event ID: 8002
Task Category: Auditing NTLM
Level: Information
User: SYSTEM
Computer: DC03.redacated
OpCode: Info
General Event Data:
NTLM server blocked audit: Audit Incoming NTLM Traffic that would be blocked
Calling process PID: 1388
Calling process name: C:\Windows\System32\svchost.exe
Calling process LUID: 0x3E5
Calling process user identity: LOCAL SERVICE
Calling process domain identity: NT AUTHORITY
Mechanism OID: (NULL)

Audit NTLM authentication requests to this server that would be blocked if the security policy Network Security: Restrict NTLM: Incoming NTLM Traffic is set to Deny all accounts or Deny all domain accounts.

If you want this server to allow NTLM authentication, set the security policy Network Security: Restrict NTLM: Incoming NTLM Traffic to Allow all.

Events 3 & 4 are identical, herewith a single example

4>
An account was successfully logged on.

Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0

Logon Information:
Logon Type: 3
Restricted Admin Mode: -
Virtual Account: No
Elevated Token: No

Impersonation Level: Impersonation

New Logon:
Security ID: DOMAIN-01\checkpointidcollect
Account Name: checkpointidcollect
Account Domain: DOMAIN-01
Logon ID: 0x22497DD7
Linked Logon ID: 0x0
Network Account Name: -
Network Account Domain: -
Logon GUID: {00000000-0000-0000-0000-000000000000}

Process Information:
Process ID: 0x0
Process Name: -

Network Information:
Workstation Name: FWCP-IDCOLLECT
Source Network Address: 192.168.230.2
Source Port: 54566

Detailed Authentication Information:
Logon Process: NtLmSsp 
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): NTLM V2
Key Length: 128

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The impersonation level field indicates the extent to which a process in the logon session can impersonate.

The authentication information fields provide detailed information about this specific logon request.
- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

NB: Adding FWCP-IDCOLLECT to the Network security: Restrict NTLM: Add server exceptions in this domain does not allow the above to work. I presume this is due to NTLM happening within LDAPS so the NTLM authentication requests appears 'out of nowhere' and doesn't directly originate from the FWCP-IDCOLLECT system as such...

PS: Still slogging through tier 1/2, hoping to get an answer from R&D whether or not this is on the road map already or requires a request for enhancement.

Herewith the crux of the problem, defining the hostname of the dedicated Windows Server that is running the CheckPoint Identity Collector does not allow NTLM via the method the application is using. Creating exceptions for BYOD wireless network access controller (PacketFence) or other RADIUS systems work perfectly when we exempt the workstation name:

[bzc]

Having the same issue, did you get an official answer from TAC / R&D on this?

[mr_bigglesworth]

Also having the same issue. curious as to what progress if any has been made.

[the_rock]

+1...I actually had TAC case on this for the customer and it went absolutely nowhere. They told me would contact R&D (no clue if task was even created, I doubt it, as one was never provided to begin with) and that was pretty much it.

[pini · Accepted solution]

Hi @David_Herselman , 
I believe with the new IDC version (R81.069.0000), support for Kerberos authentication was added. 

See https://support.checkpoint.com/results/sk/sk134312:

IDA-5593

[Greg40 · Accepted solution]

You're right Pini, However it is not working by default and need the following setup : 

• To enable the Add Domain Controllers automatically by DNS and LDAP queries as well as the periodic AD discovery flows to function seamlessly with Kerberos  authentication, it is imperative that domain credentials be formatted in the User Principal Name (UPN) format. It is crucial to note that the use of a combination of User Principal Name format and DC IP address is not compatible.

[pini]

Good to know!

Thanks.