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.

4. Additionally, I also need to make changes to $CPDIR/tmp/.CPprofile.sh according to sk134292

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

[Peter_Elmer]

Hello @ShemHunter ,

let me add some comments 😊

1) "because the global catalog isn't explicitly added to the account unit"

Global Catalog support must be configured on the gateway and on the LDAP Account Unit.

2) about nested groups

Nested Group support means "Alice/Bob is a member of to Milano-Group. Milano-Group is a member of Lombardia-Group. Lombardia-Group is member of Italia-Group and Italia-Group is a member of Europe-Group." Nested means "something is inside". In this example the Milano-Group is nested at the 4th level counting from the top level "Europe-Group". 

The Nested Group configuration controls how the gateway will queries the LDAP server. You may want to explore mode 2 or 4 for your environment. If you are running nested group state 1 and have configured a max depth 2, the Milano and Lombardia Groups are never learned, in this example.

It is my experience in projects and understanding of the referenced documentation, that nested group state 2 requires configuration of Global Catalog. Whenever one of my customers moved to Global Catalog they could benefit from state 2 and behavior of group membership improved. Note: you need to configure the gateway as well ( sk134292) and unfortunately that requires a reboot.

Maybe the CLI command 'ldapsearch' can help you on the gateway level to check the AD Server and their response.  The syntax is a bit complex, but I found this command very helpful in proof of concept environments, where we had to explore the AD structure. You just need a domain user account to explore it. Best using the account that is configured in the LDAP Account Unit, so you can verify it has relevant access rights.

best regards

pelmer

[ShemHunter]

This command gives us all the information, and we receive it clearly and precisely – in the output, we clearly see that the user is in this group.

Yes, I also asked about nested groups just in case, and you confirmed that I'm not confused and understand how it works 🙂

So, if there are nested groups, I need to follow all four options. If there aren't any, I configure the AD itself as a global catalog and the others as child catalogs – through server settings, and then checkpoint on the server side. I set the LDAP account unit for the global catalog to 3269/68 and the lowest priority, and for child catalogs, I set the highest priority.

[Peter_Elmer]

Hello @ShemHunter ,

"the AD itself as a global catalog and the others as child catalogs "

To my understanding there is no concept in Active Directory such as "child catalogs", but I am not certified by Microsoft for Active Directory (or any other technology). I am just reading their documentation and verify things in my lab 😊

If you query the Global Catalog and get what you need, great. That is the expected way of working since many years. 

greetings

pelmer