Firstly, thank you very much for everyone’s help, guidance and offers for support. From memory I started on this in anger on the 12th. 9 days later of pretty much eat, sleep, checkpoint, repeat (plus a very understanding wife!) I think I have cracked what I feel is the best way to do this. I will at some point write up a detailed guide on exactly how I have achieved this using the same baby steps I have used to make any troubleshooting easier and with my justifications etc. However, until I have time to write this up, I will give a quick summary here:
My original requirement was Layer 3 VPN using Check Point. I essentially had separated my clients into two categories, managed end points I "trusted" and unmanaged end points I did definitely did not trust. The trusted clients should get full access to the network and the unmanaged clients should just be able to access a VDI environment. This is over simplified but is okay to demonstrate the point I am trying to make. When I have previously done this with other firewalls I have used two tunnels with different authentication types that then provided different levels of access. For the managed tunnel I have used certs that could only be issued to machines in the domain + the users password. For the unmanaged tunnel I have used password + a one time password. Always use two factors, if you can use multiple!
Check Point does not work like this and instead all your users essentially come in via the same tunnel. You can setup different authentication types, but you cannot then use that to make an enforcement decision. The best way to get around this is using the Identity Awareness Blade to configure rules in the policy based upon Access Roles. This is my first shout out specifically to @Tobias_Moritz for a solid suggestion! I wanted to configure two access roles, one for my managed devices and one for my unmanaged devices.
For my managed device access role, I have configured the users to be “All identified users” and the Machines to be “All identified machines”. For my unmanaged device access role, I have just configured the users to be “All identified users”, I have machines section as default. You could of course lock this down to specific groups, networks etc if you so desired.
In fact, in a production environment, you should always make permissive security policies as granular as possible. This helps to ensure that you have a good security posture, but this also helps to avoid the situation where your rule that was originally intended for VPN also starts getting used by your server farm. This doesn’t sound too bad until you try and decommission the VPN solution and have to reverse engineer all the accidental traffic that’s hitting the rule. Rant over!
When I was doing this on the LAN side of the firewall using AD Query these worked nicely and is a neat little trick to discourage people putting unmanaged devices on your network if you do not have 802.1x.
However, when I tried to use the access roles with devices on the VPN these did not work as the computer never got identified. This seems to be a limitation of using Remote Access as an identity source. This was a bit annoying and resulted in a bit more head scratching followed by another good suggestion from @Tobias_Moritz . Use the Identity Agent combined with Kerberos Authentication. Out came the pot of coffee again! After quite a bit of abuse I eventually got this working as I desired. In fact, this works so nicely I suspect I am going to disable AD Query and just use the Identity Agent with Kerberos moving forwards. As pointed out somewhere in this thread using AD logs is not really rock solid.
I am not going to bother using this on unmanaged clients as I only need their user’s identity and I can get this through the remote access blade. It might be worth noting that identities sourced from Remote Access have a higher priority than identities sourced from the Identity Agent. This means that the Identity Awareness source that gives both machine and user identities should get overrules by the Remote Access blade that just gives the users identity. However, I suspect because the Identity Agent has more information this still seems to takes priority.