Identity Awareness Issues

[ShemHunter]

There are two similar SK

https://support.checkpoint.com/results/sk/sk134292
https://support.checkpoint.com/results/sk/sk106964

And I don't understand how exactly they work, I'll explain it with an example:

I have two environments - a test environment (regular GW and cluster), and a production environment (Maestro).

In the test environment, I have AD - indeed.cp
It also has - prod.indeed.cp

In the production environment, I have AD - indeed.cp
It also has about 8-10 ADs. - europa.indeed.cp/europa1.indeed.cp - and so on.

I created a group in the prod.indeed.cp and the user himself is from indeed.cp and using the access role and pdp m u - I see the group for this user

I haven't applied any settings, but I use group nesting settings of 4 or 5 and I see the group. When using setting 2, I don't see the group. If I disable group nesting altogether, I doesn't see the group.

Connecting to the main AD via Port 636 is different from port 389.

In the production environment, everything is configured exactly the same, but at some point, access roles stopped resolving, and PDP MUI doesn't see groups and shows all users. I'll say right away that I didn't apply any settings before the problem occurred.

I use a collector in both environments.

Version 81.20, take 158

[simonemantovani]

Anything has been change on AD side?

[ShemHunter]

There have been no changes on the AD side.

Additionally to my post:

The group that was created—the group's scope is universal—if that helps solve the problem, of course.

[simonemantovani]

I haven't enough experience on Active Directory, but maybe this PDF could be an helpful point to start:

https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://community.checkpoint.com/f...

In particular take a look from page 14.

[Chris_Atkinson]

DC Windows server version the same in Prod & Test - 2025?

[ShemHunter]

In the test environment - 19 and 22

In the production environment - from 16 to 22

[PhoneBoy]

Maybe @Peter_Elmer can help here.

[ShemHunter]

@Peter_Elmer Hi,

If possible, I would listen to you.

[ShemHunter]

Hi @Royi_Priov,

Maybe you can help with this issue?

[Peter_Elmer]

Hello @ShemHunter ,

sorry for the late response, I was off for Summer vacation.

First, I see you have overlapping AD Domains: prod.indeed.cp and indeed.cp. You want to review in detail the LDAP Account Unit objects you created and the Gateway > Identity Awareness > Identity Collector > Authentication settings. 

In the LDAP Account Unit the BASE DN determines where the gateway starts looking for group membership. If the gateway has "all Account Units" selected, it queries all AD Servers given in all LDAP Account Unit objects to learn the group. This a) takes time and b) may lead to find contradicting results. The group nesting setting is of second impact here. The main impact lies in the AD servers that are actually queried and you may want to review and document your current configuration. 

You referenced sk106964 and sk134292. The sk106964 is dated and not detailed. I contacted R&D to review it.

The sk134292 is documenting Active Directory Global Catalog integration. Global Catalog holds a subset users and groups attributes. Searching the Global Catalog instead of the Local Catalog speeds up searches and consumes less resources. I recommend using Global Catalog.

The Identity Collector signals the login event of a user towards the gateway. You may want to review and document, which AD Server is connected to which Identity Collector and make sure, the gateway does not learn one login event from multiple sources. There is logic to handle this, but running this logic consumes resources. 

I do respect the complexity here and you may want to ask your Check Point sales contacts for an offer of a Professional Services to help you here. In case you want to study further check sk179544 for some more information on this subject.

best regards

pelmer

[ShemHunter]

Thank you very much for your detailed answer. From everything I know and have read, I have come to the following conclusion:

In Authentication Settings, I have all account units selected.

My current assumption is that because the global catalog isn't explicitly added to the account unit, CheckPoint simply doesn't see groups in the global domain.
In SmartConsole, there are only two LDAP Account Units (indeed and prod.indeed), configured on standard ports 389/636. Each only sees the local database of its domain.
When nesting is disabled (Mode 0 / Off) or Mode 1: The gateway only queries direct memberOf attributes within the branch of a specific Account Unit. A user from indeed.cp who is a member of a group in prod.indedd.cp will not receive the group.

At deep nesting (4-5): The gateway attempts to follow LDAP referrals/recursive links. In a small environment, this sometimes "breaks" the connection, but in a high-load production environment, it generates a flood of requests, hits timeouts, and completely breaks the mapping (the user is displayed, but the groups disappear).

In Mode 4: The request is blocked by the scope of the branch specified in the Account Unit (get groups from the branch specified in the LDAP account unit), so cross-domain groups are cut off.

Even when I configured port 3269 on prod.indeed.cp, CheckPoint continued to search for users/groups in DC=prod,DC=indeed,DC=cp.

On my end, the settings should look like this:

Using Global Catalog (Mode 2) - pdp nested_groups __set_state 2
1. Create an LDAP accounts OU for the root domain - as an example, I'll make a slight change to the root and AD: root - indeed.cp, child domain - prod.indeed.cp, child domain - infra.indeed.cp = Let's assume that the root is not added and only child domains are added and you need to explicitly add the root

2. Specify port 3269/3268 in the server properties for root domain in LDAP Accout Unit.

3. The base search DN (Fetch Branches) should return DC=indeed,DC=cp.

Important note - regarding why other groups may be displayed even if their group scope is set to Universal:

All groups that include users from other domains must be of the Universal type (Global/Domain Local groups are not fully replicated to the Global Catalog).