Identity Awareness and AD convergence

[Juraj_Skalny]

Dear Colleagues,

I very often end up here reading interesting questions/answers

Today I seek help myself.

We have successfully deployed Identity Collectors that talk to AD environment and to PDP Gateways.

PDP gateways then distribute data further to PEP based on SmartPull

All works juts fine.

Now we would like to create Identity Based  Access rules based on working IA environment

The problem is how to keep IA world as much up to date as possible with AD world ,

For example how to fine tune efficiently DHCP time leases , Association time-to-live, Cache time-to-live and other timers.

For example I noticed that old records are being kept in the IA database potentially creating mess in real access control.

Potentially IP addresses associated with user/machine roles get matched against Identity Based rules regardless of real IP ownership...

As far as I understand it is IP address that is being authorized by DC environment based on correlation between user/machine role and IP address. That is all what firewall knows...IP address...and makes decision based on that IP.

So this IP is then allowed by Identity Based rule regardless of the user owning it in real or not as the user/machine could get new IP or even could get off the network and other machine that belongs to different access role could pick the same IP which already is allowed for different access role...

Please correct me where I go wrong with assumptions and deductions...

We just need to make sure that somehow user/machine/IP address are really up to date between AD and IA world so firewall can make appropriate decision 

Thank you,

JS

[G_W_Albrecht]

I would assume that you did follow the R80.30 Identity Awareness Admin Guide. But did you also study how IA works in detail - sk86441: ATRG: Identity Awareness ? For deployment in a larger scale, there is also sk88520: Best Practices - Identity Awareness Large Scale Deployment.

[Juraj_Skalny]

Hello,

yes, we have gone through all available documents.

We have it all set according to best practices already

It would be not possible to deploy without study.

However we could not find any relevant fine tuning information how to make IA effective.

How to make Identity Collector effective when working with AD. 

Everything works but we dont find IA effective when it comes to Identity Based access rules as of now. Solution must be fine tuned somehow. Especially when it comes to timers. When info expires in IA world. Why timers are set the way they are by default? We were hoping someone on this thread has gone trough this already and is fully aware that information from IA blade must be rock solid and precise and accurate if identity based access roles are built on top of it...

Thanks,

JS

[G_W_Albrecht]

You could always use CheckPoint Professional Services for a professional IA configuration or consult another in-depth specialist. In practice, IA access roles work as expected everywhere i know of (that bugs and misconfiguration happen is clear to everyone involved in security), so i would suggest that you state clearly what does not work for you !

[Juraj_Skalny]

yes you are correct...thank you...

Ill try to give example.

user is on wire and has x.x.x.x IP

user has logged in into domain account so PEP learned very quickly from PDP that user XXXX has x.x.x.x and based on the rule allowing user XXXX to ANY this user is allowed so the IP will be proceeded.

now user went to the meeting and connected to the WiFi obtaining different IP YYYY without touching the keyboard

new IP however doesn't propagate to PEP any time soon and the user is cut off from the network since only XXXX with IP xxxx is allowed.

situations like this....

[Timothy_Hall]

You should check out loading the Identity Awareness Agent on the workstations in your network.  This software is optional but can be very helpful for handling roaming users and multi-user kiosks/workstations in an Identity Awareness environment:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Roaming users can also be handled by Transparent Kerberos Authentication but this can be tricky to get working properly in some environments. The "light" version of the agent should do everything you need.

[Juraj_Skalny]

Hello Timothy,

thanks for your input.

also thank for your IPS Immersion Training.

Im recently going through the videos. Very informational and comprehensive. I would highly suggest to any CheckPoint IPS admin to go through this course.

Are you planning to work on any other course perhaps?

I wish everything in CheckPoint would be covered to this kind of great detail. 

In relation to the Identity Agent.

This would be of course the best solution as the users/IP address would be immediately propagated over to IA gateways.

We have 50 gateways in the company and many travelling users.

I have to look into this and see if there is any way to deploy this "without users noticing"

Maybe combination of staged Identity Agent deployment and already working Identity Collector could be way to go.

Thanks a lot!

Juraj

[mdjmcnally]

Identity Awareness won't pick this up as is looking at the Domain Controller Logs for Login Events etc.

When you unplug and move from Wired to Wireless you do get a new IP but you aren't authenticating against the AD Servers so no event on the AD Server.

Where you have that type of connectivity change then Identity Collector or even the older AD Query won't have an AD Log to update them.

As such the IA Collector won't see the change as IA Collector is looking at the following events

4624 - An Account was successfully logged on

4768 - A Kerboros Authentication Ticket was requested ie Account Logged in

4769 - Kerberos Service Ticket requested

4770 - Kerberos Service Ticket renewed

That would be where the Identity Agent on the machine would come in useful as the Agent updates the PDP which would do with a change of IP Address

Another potential way forward depending upon the Network is that if you are using Network Access Control on the Network and use either Cisco ISE or possibly one of the products using the Identity Awareness - Web API

Out-of-the-box integration with 3rd party vendors

3rd party vendors already implement client side which updates Identity Awareness blade using the Identity Awareness Web-API:

• Aruba Clearpass - sk104958.
• ForeScout CounterACT - sk116235.
• Pulse Secure - sk121848.
• Extreme Networks ExtremeControl

These should also update the PDP as users move and not reliant on the AD Server events.

Used with the One User option then should disassociate the Wired IP for the User, and associate to the Wireless IP.

Obviously these have costs though whereas the Agent would be part of the Check Point License (obviously cost in terms of deployment) but possibly incorporate as part of machine build?

[Juraj_Skalny]

Hello mdjmcnally,

thank you very much for your input.

yes, you are correct. Relying on AD logs only is juts not enough.

another showstopper with Identity Collector only is address spoofing. I can just configure IP address of authenticated user and Im in.

we do not use any 3rd party NAC wich we could link with IA-Web API.

we are hoping to come up with resilient and reliable NAC with Checkpoint only.

For this reason I think it will be not an option to skip Identity Agent. 

maybe even full version of it.

Do you think Identity Collector and Identity Agent will not confuse PDP? Both may feed PDP with different info especially when the client moves from wire to wireless and I could not find an option " Assume that only one user is connected per computer."

Anyway...thanks for the input..

Juraj

[mdjmcnally]

When you deploy IA Collector you should deploy 2 for resilience, and before available ended up deploying a pair of Check Point 2200's as Dedicated AD Query boxes.

So should always get two feeds going into the Gateways as such from the IA Collector.

The system handles that fine.

Where had 1 User Per Computer (is under AD Query) then simply takes the latest one as being correct.

As this is the Agent on a Computer sending the information to the IA Gateway then when the user moves from Wired to Wireless then should get an update going off to the IA Gateway via the KeepAlive which by default is 5 minutes.

This should if I have understood correctly then override the IA Collector entry.

Then again if deploying the Agent to Windows/Mac then would you still need the IA Collector.

Only thing that wouldn't be covered would be Linux/Unix Desktop/Laptops as no agent and if Domain Joined would be picked up by IA Collector however they won't update if jump wired/wireless.   Don't know if you have Linux running in your environement.

[Juraj_Skalny]

when it comes to IDC..

we have two geographically independent IDC in place...

each IDC is tapped to every single DC in AD...

each IDC is feeding two geographically independent PDPs

each PDP is feeding PEP so each PEP gets info from two PDP

we believe this scenario is very resilient and lacks single point of failure

We dont have AD query enabled as this requires higher privileges for PDP in AD world and there are also another reasons why IDC is better that AD query. However IDC lacks an option to assume one user per computer unfortunately 

this introduces many entries in PEP database with old user/machine/IP match

if we add Identity Agent this confusion may be even greater... I dont know...could not find resolution for this assumption in official checkpoint docs...

could you please also elaborate a little bit on:

"Then again if deploying the Agent to Windows/Mac then would you still need the IA Collector." In my understanding IA collector works with DC and PDP gateways only and not with IA agents...maybe Im mistaking here....

in relation to:

"Only thing that wouldn't be covered would be Linux/Unix Desktop/Laptops as no agent and if Domain Joined would be picked up by IA Collector however they won't update if jump wired/wireless.   Don't know if you have Linux running in your environement."

we need to cover Win10 machines only as according to the goal NAC scenario only domain machines can go out to the internet...

[mdjmcnally]

If you are using the Identity Agent on your environment which is just Win10 machines then if every Machine has the Agent installed, then I don't believe would need the IA Collector as well as if using the Agent to update the PDP then not going to get a benefit from the IA Collector when the Win10 logs in.

As such would just be getting updates from the Agents.

I haven't had to do large scale agent deployment so not sure of the load on the Gateway would be though.

[Juraj_Skalny]

well...I was hoping not get involved with IA agents as this would be very difficult to maintain and distribute etc... 🙂

[FedericoMeiners]

@Juraj_Skalny 

Hope you are doing fine, I'm adding my 2 cents here based on the main issues that I had on Identity Awareness deployments. As you described the main point of conflict is when IPs are associated to wrong users.

• This issue happens mainly because the previous user did not log out from the the current host, therefore the IA database is not updated properly. To mitigate this you may want to enable the "One user per host"
• Exclude system accounts from IA, most of the time this cause a lot of WMI logs and the gateway is not able to parse them.
• Work with your DHCP lease to be as long as possible for corporate users.

Finally I highly suggest you to read this amazing document that does deep inside IA engine and large scale deployments: Identity Awareness for dummies v8 

Hope it helps

[Juraj_Skalny]

Hello Frederico,

thank you for your input. 

your suggestions are valid and based on your experience. I really appreciate it.

however we are using Identity Collector technology which is the most proffered way of gathering identities according to CheckPoint but Single User Assumption is just not there to configure.

remaining two bullets are valid.

Thanks again,

Juraj