How Identity Awareness Works

4/30/2013: This is what I took out of my meetings with Amnon Perlmutter who is heading up Identity Awareness. I have not tested any of this so put a grain of salt on it.

So I figured out how Identity Awareness works. CP talks about the components of IA, but I never saw it explained like this. This should help debugging IA when its starts losing identities.

Gotta run to conference so here is the quickie.

Debug IA

So first thing you have to remember is how CP evaluates how a packet is associated with a user. The gateway goes through an evaluation process in this order. Whenever something does not work, make sure you go through these steps in your head.

Slide2

So this is nothing new. You see this in all the IA documentation. These are the process that filter IA information:

  • PEP – Enforces user/machine access according to rulebase
  • PDP – Stores user/machine and group session info, this feeds PEP if user has active sessions. NOTE there is SIC between PDP and PEP so that PDP can feed multiple PEPs on different firewalls. Avoids having to hit AD or LDAP servers multiple times.
  • LDAP – Retrieves user group information about the user from the associated LDAP server that the user belongs to

Three basic ways of identifying ( packet belongs to Bob) and authenticating ( Bob’s packet was created by a person that new Bob’s password/certificate so I know it belongs to Bob):

1) ADLOG: Retrieves info from AD events log such as login events. If Bob can login to AD, then Bob has valid AD credentials
2) Captive Portal: User uses username/password(or cert) to log into a web browswer hosted on a CP gateway
3) Identity Agent: software running on use desktop or mobile client. god help you if you implement this, don’t call me.

Slide3

In this menu for the gateway ( you have to enable the Identity Awareness blade), is where you can specify how clients authenticate.

Slide4

OK, so groups are going to be funky. The business happens when a packet from Bob gets into the gateway and the rule reads (‘Sales’ is allowed for HTTP). so the gateway has to decide “Is Bob in Sales???”. PDP is the process that monitors that. PDP works with the LDAP environment to pull down group information.

This is admittedly complex. Works differently for each LDAP environment. OR if you define all this locally to the Domain on an internal database ( you really should not do this, to much admin).

If the future I want to dig into this further. I’m just touching the surface here.

Slide5

So here you can see how the groups are built. Ideally you want to use the groups defined on the LDAP server. With CP internal, you have to define groups again! In large environments, this won’t fly.

SSlide6

CP works pretty transparently with AD groups. You can see them inside CP Identity Awareness and don’t have to recreate the groups.

Slide7

If you work with some sort of custom LDAP server, you might have to redefine the groups which would be a pain. This is how you do it. You can actually define a dynamic group search. For example: group=sales for all dn=sales.acme.com email groups.

Slide8

OK this will seem obvious AFTER you read this. Note that LDAP queries are made while you are creating rules in SmartDashboard as well as when the packet is flying through the firewall. So if it works in SmartDashboard, the gateways are seeing the same thing.

Slide9

Authentication is transparent for a pure AD environment. PDP pulls down AD event logs looking for login events (and other events like mounting disks, web browser authentication, etc).  NOTE: ADlog only sees login events, there are NO NONE ZIP NADA logout events!!!! Look at me when I tell you this. So if you ever wonder why names seem to mysteriously drop from IA, think about the caching timers, duplicate ID timers, default logout timers and how they all interact.

Also note that PDP can be shared between PEP’s running on multiple gateways. That way all the PEP’s aren’t hitting up a single AD Directory Controller in your environment bringing it to its knees.

Slide10

If  you don’t run an AD environment or have to support mobile clients, then Captive Portal might be a solution. Users use a web browser to authenticate to the gateway. Captive portal can hook into several different authentication mechanisms to authenticate the user. Here they are

Slide11

For logging, IA only works with AD. I wish it worked with RADIUS accounting so it can work outside of AD.

I’m testing this because I think it should work with mobile clients and RADIUS somehow, so put a grain of salt on this.

Slide12

As soon as you enable IA for logging, it tries to integrate it into AD….and nothing else. Bummer…but maybe I’m wrong. Still investigating.

Slide13

 

So with the above information, it should be easier to debug using the pdp, adlog, pep, test_ad_connectivity tools. Look into those next and map them back to my slides above.

Happy Identity Days!

dreez

 

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Srinivas  On May 6, 2013 at 4:41 pm

    Hi Michael,
    This IA information is very useful thanks for providing on the website, can you kindly provide some advance information on the same as i am implementing in bigger environment where we have around 25000 AD users and 100 plus firewalls. i want to implement every gateway should do a AD query to fetch user information from his local AD server at each of its location.We have a distributed environment with firewalls and AD’s.

    Currently IA sometimes fetches AD user information and sometimes not. pdp and pep services are not running on the testing gateway. Kindly if you can help in resolving the issue I would be very greateful and thankful to you. Checkpoint IA document is very basic and for large environments it is less useful i believe.

    Once again thanks for the update.

    Thanks
    Srinivas
    +91 9699940348

    • Dreezman  On May 6, 2013 at 6:45 pm

      Srinivas

      Oh geez I’m not sure I understand your questions aside from its not working consistently. You are going to have to use pdp, pep, adlog query along with tcpdumps on the LDAP and WMI traffic to understand what is going on. Obviously support or CPUG is a good start. If you ever learn some tricks, please update this thread. My followup on this will be debugging tricks.

      Thanks for your comment
      dreez

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

blog.lachmann.org

Michael Endrizzi's - St. Paul MN - CheckPoint blog on topics related to Check Point products and security in general.

%d bloggers like this: