Policy verification failed for rule with network objects and access roles

[phlrnnr]

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

[Daniel_Taney]

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.

[Kaspars_Zibarts]

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]

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]

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

[PhoneBoy]

@Royi_Priov did we ever address this limitation?

[Royi_Priov]

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.