Identity Awareness – Using Access Roles as Source in Internet Access Rules

[Saranya_0305]

Dear Mates,

I am currently working on an Identity Awareness Blade lab.

I have successfully integrated Microsoft Active Directory (Browser-Based Authentication) with a Check Point standalone deployment.

However, I have a few questions:

Is it possible to create access rules based on users (Access Roles) as the Source for allowing Internet access and specific services, instead of allowing access for the entire network?
I have enabled Hide NAT for the entire network using the Network Object.
Do I need to create an access rule with the Network Object as the source first, or can I use only the Access Role as the source in the rule?
My expectation was that using the Access Role alone would be sufficient, but it does not seem to work.
During my testing, I noticed that when I specify the Network Object as the source, that rule is matched and takes priority. However, when I use only the Access Role, the traffic does not match the rule.
I am using a Unified Policy Package with the Application Control and URL Filtering blades enabled.

Could you please suggest the best practice for configuring Identity Awareness policies in this scenario?

Specifically:

Should Access Roles be used alone as the source, or should they be combined with network objects?
Are there any prerequisites or common configuration issues that could prevent Access Role-based rules from matching?

Regards,

Saranya

[emmap]

You can use the Access Role directly in the rule, there's no need to also use the network object. If it's not matching then your gateway probably doesn't have the identities collected. Users will have to do the browser based authentication before the access role will work. If you're expecting a redirect to occur make sure you have that set in the Action part of the rule they will match, and you'll probably need HTTPS Inspection inspecting the connection else we can't redirect it.

[Duane_Toler]

Browser-based is going to imply "captive portal" in an access rule.  Without that, browser-based is of no real value.  With captive portal, you can define various ways to match your users (AD, locally-defined, RADIUS, others).

Since you have Active Directory, use the Identity Collector to feed identities to the gateway.  This can be on any AD-connected host; doesn't have to be a domain controller.  Within the Access Role, you can match users based on your AD properties (OUs, Groups of users).

For Identity Collector, make sure your domain GPO has the auditing policy enabled for "Account Logon" and "Account Logoff": https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/advance...

Verify users are loaded onto the gateway with "pep show user all".  You can verify if a user is matched to a role with "pep show user query usr <name>"  (yes "usr" is shortened here; it's a query parameter).  In the output, it will say what role matches that user identity.

Like Emma said, use that role in your access rule, above the rule for that network object (otherwise, the object-based rule will have precedence).

The Access Role itself *can* also contain a network constraint; this is an "AND" process with the matching users, if you want "These users AND when connected to <this> network".  Sometimes valuable.

Without the network constraint, this role may also match users connected with Remote Access VPN client (if you enabled "Remote Access" as an identity source in the gateway properties).  With roles, you won't need to use the old-school "UserGroup@Any" method in the access rules (which only bind to "Remote Access" VPN community).  Roles work with ANY rule for matching a user.  This is how I do all of my customer policies now.

You *can* still have locally-defined users, and assign them to a local-defined user group; just put that group in your Access Role, then use the role in the rule, and remove the old-school "RemoteAccess" community.

This works; promise!  Holler if you have issues.