- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
I didn't found the location for Identity Awareness issues, therefore I picked General Topics but if anyone knows what is the right location please let me know,
The title is a bit long and maybe will not be clear enough so here's my case :
First the architecture :
The main purpose of this architecture is to test Identity Awareness and its abilities,
I've decided to use the terminal agents (light version) and managed to make kerberos logging in for both domain, I've set up rules to test both users from A and B and everything is fine so far.
But when I've tried to create a rule with an Access Role containing a local group created on A that is containing users of B the users of B aren't matched on the rule while users of A that are in the same local group are matched by the rule,
Actually we won't have the access on B to create and manage groups, I know that we can do the same thing by creating an Access Role on the SmartConsole and adding the groups / users to it and it should be working fine but this will be tedious as all groups/OU... are already created on A
Is there anything that I can do to fix this or am I missing something ?
I know that it may not be clear so feel free to ask any question you have,
Thanks in advance for your help and your time,
The group information for a user is only obtained by querying the relevant AD domain via LDAP.
Since you're not querying the users of B (and only A), the users from B won't be part of the relevant group.
This seems like expected behavior.
The group information for a user is only obtained by querying the relevant AD domain via LDAP.
Since you're not querying the users of B (and only A), the users from B won't be part of the relevant group.
This seems like expected behavior.
Thanks for your answer,
So even if the user is in the group, the rule won't match because they are not created on the same AD domain ?
There is no other solution to counter this than creating Access Roles containing both users/groups of A and B ?
Right, because the underlying LDAP query is likely only getting the users from the domain in which it is queried, not the ones from the cross-trust relationship.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 19 | |
| 17 | |
| 14 | |
| 8 | |
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY