- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Identity Awareness setup
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Identity Awareness setup
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The LDAP lookup piece has never required admin privileges, only the WMI piece.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
from User Directory tab we got:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes i'm aware about that sk, but i left default values.... TAC Case araised