Identity Awareness setup

[Josh_Dill]

Hi All,

I will be setting up Identity Awareness in an R80.10 MDS environment. We will be using Identity collects to communicate with the DCs and provide what is in the security logs to the firewall. After reading the documentation I have some questions regarding setup and usage. Thanks in advance:

1) I have read the following identity collection requirement:

"Identity collector provides information about users, machines and IP addresses to the Security Gateway. LDAP Account Unit(s) should be configured to allow PDP gateways to perform group lookups on IDs that are provided from Identity Collector to match them to Access Roles."

If an account unit is created in the domain (checkpoint local domain NOT active directory) and applied to the firewall object under firewall properties - others - user directory. Is that all I need to perform this requirement?

2) There is no way to apply an account unit I created in global directory (at least not that I can find). Does this mean I cannot use global rules with identity awareness since the global account unit would not be assigned to the firewall to perform global lookups?

3) Is there anyway to create rules for individual users opposed to groups?

Thanks,

Josh

[Vladimir]

Actually, I'd like to get some clarity on this statement too:

"Identity collector provides information about users, machines and IP addresses to the Security Gateway. LDAP Account Unit(s) should be configured to allow PDP gateways to perform group lookups on IDs that are provided from Identity Collector to match them to Access Roles."

I thought that the Identity Collector was, in part, used to circumvent the necessity of creating the Administrative account for Check Point's LDAP Account unit.

But looks like it is required anyway for IA to work as intended. 

[Josh_Dill]

Hey Vladimir,

I do know in my readings that the collector only gets events from the domain security logs (user login/logout info). The collector then sends these usernames to the gateways to match it with an IP address BUT its only one part of the total equation. The gateway still needs match this username to  AD groups and memberships hence the need for the LDAP account unit. Once you have this piece you can make access role objects and query anything in the AD directory for the gateway to enforce.

Josh

[PhoneBoy]

The Identity Collector just obtains the usernames.
LDAP Lookups still occur at the gateway level and those are tied to a specific domain, not global.
Which likely means you cannot configure LDAP groups at a global level, but @Royi_Priov should comment further.

If you want to create a user-specific rule, isn't that just a matter of defining an access role for the specific user in question?

[checkpoint_chec]

Hey Phoneboy,

Once IC is implemented, Admin account is still needed onto LDAP account unit to perform LDAP lookups?

I saw on @Peter_Elmer videos that he switched to a non admin account onto LDAP account unit.

Last question, Will Captive Portal get identities correctly if LDAP account unit has not configured an Admin Account?

Thank you

[Sorin_Gogean]

Hey,

In regards to AD account used to configure IC to read Login data from AD, our account is not an admin account (is just allowed to read the AD logs) therefore I would say that you don't require an Admin account like it was needed with AD Query. 

(we use same account for LDAP objects)

I can't answer on Captive Portal as we don't use it, we only get AD and ISE data into IA via IC 🙂 .

Ty,

[PhoneBoy]

The LDAP lookup piece has never required admin privileges, only the WMI piece.

[Peter_Elmer]

Hello @checkpoint_chec ,

Best to look at the flow of events from the start: 

• user logging on to his/her computer (user@machine@IP_Address)
• Windows OS verifies login credentials with AD Server (given computer can reach AD Server)
• AD server is writing a security event log message
• ID Collector has subscribed to read these login events and learns that user@machine@IP_Address is existing.
  • The ID Collector requires a userID for this subscription that is part of the Event Log Readers AD Group
• ID Collector is forwarding this information to PDP instance on the gateway
• PDP instance runs LDAP(s) group membership lookup against AD Server
  • The PDP requires a userID for this group membership query that has read access to relevant directories in the AD containing users, machines, user groups and/or machine groups. In all my projects a regular domain user account was sufficient here.
• PDP learns group membership of the relevant user/machine from AD and checks which Access Role object is matching for this user@group@machine@IP_Address
• PDP creates ID Session (run cli 'pdp monitor' to see the evidence
• PDP shares this ID Session with PEP instances who have subscribed to it for getting information about ID Sessions

I created videos on sk179544 showing the above flow and related configuration.

When using the Captive Portal the same as above is taking place, besides the Login Event is signalized by the client browser connecting to the portal. The user is providing credentials and the PDP is sending those to the AD Server. In case AD server authenticates the user, then the PDP is starting the authorization process and runs LDAP(s) group membership queries. Here, just like above, domain user access rights are sufficient. 

Note the LDAP Account Unit object is holding the userID credentials the PDP uses to run the LDAP(s) group membership queries.

best regards

peter (pelmer)

[CheckPointerXL]

Hello Peter,

we need to deploy in  around 20 CMA same LDAP Account Units.... to facilitate the process, we create the LDAP AU objects in Global Domain, but it seems that the LDAP AU cannot be selected in the User Directory tab in authentication method (they are not visible)... is there any limitation on this? 

thank you

[CheckPointerXL]

from User Directory tab we got: 

[PhoneBoy]

Looks like this is expected behavior: https://support.checkpoint.com/results/sk/sk181042
You need to set the priority in the object at the global level (not the local one).

[CheckPointerXL]

yes i'm aware about that sk, but i left default values.... TAC Case araised