Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
phlrnnr
Advisor

Policy verification failed for rule with network objects and access roles

I am new to identity awareness.  I have implemented identity collector with AD and LDAP connectivity from the GWs.  I have an existing network rule that has normal source / destination hosts and network objects in them.  I added an access role to the 'destination' column, and the policy verification fails stating " 'Destination' column of the rule contains both Access Roles and network objects". 

1. Why can't network objects and access roles co-exist in the same column?  

2. What is the best practice for deploying these rules?  Do I have to create an identical rule with the source / services, and put just the access role in for the destination?

R80.20 / JHFA 87

thanks,

Phil

0 Kudos
6 Replies
Daniel_Taney
Advisor

Unfortunately, I do not know the answer to #1.

But in regards to #2, when I haven't been able to just fully replace the src/dst with an Access Role, I usually just put another rule above the existing one with just the Access Role in place of the src/dst object. It is a little clunky, but it seems to be the only way to get around the issue.

R80 CCSA / CCSE
Kaspars_Zibarts
Employee Employee
Employee

I'm not a checkpoint r&d person but I would guess that regular network objects are "static" whereas IA roles are dynamic and IPs for them will be changing constantly therefore policy compilation principles would be totally different in both cases and mixing them in one rule would not work
As for best practice. I don't think there is one - just use whatever fits your requirements. We mostly use it to identify "source" users that are allowed to access certain resources in the company. So it doesn't matter where they sit or what IP they have as rules are enforced based on AD identity.
PhoneBoy
Admin
Admin

There was a thread that explains the logic behind not allowing Access Roles and host/network objects in the same source/destination cell.
It’s basically what Kaspars describes in this thread.
I believe this limitation will be addressed in R80.40.
phlrnnr
Advisor

It appears this was not addressed in R80.40.  Do you know if this was changed in R81?

0 Kudos
PhoneBoy
Admin
Admin

@Royi_Priov did we ever address this limitation?

Royi_Priov
Employee
Employee

Hi @phlrnnr ,

No, there is no plan to address it - the logic behind this decision is indeed in the same area as Kaspars wrote above.

Thanks,
Royi Priov
Group manager, Identity Awareness R&D

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events