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