What do I need?
Security Management
To use the SLAPI, we are going to need a Security Manager, Check Point R77.30 or later. This should be a lab or test device with access to the internet. Please do not use the API on a production system. It won't hurt anything, unless you make a point of using the API in your policies, but for the purposes of education and demonstration, the authentication and protection is stripped off. This demonstration is a free for all. If this is interesting in a pure test environment, let me know and we can setup a private version protected and customized for your environment.
For your first test drive, please setup a default install of the Check Point Management station that supports the vSec controller. I can also arrange a temporary virtual Security Manager if needed, like I mentioned, please let me know
Whichever version of Check Point manager you do choose, if this is a new install, or has not been used with the vSec controller, ensure you enable vSec as the administrator with the command 'vsec on'
R77.30 Gateway (optional)
You can track and see API actions from the Management station, so having a gateway to propagate changes through the API to isn't needed, but if we are going to see where this type of solution fits, the real power is making the old, new again.
Why 77.30 gateway? Because there are allot of them out there, and these gateways are busy, delivering services that can't afford the time, effort, or cost of an upgrade anytime soon.
Moving to R80 gateways alleviates allot of challenges with agile service platforms, but it is likely your organizations drive to cloud adoptions is moving much faster than the gateway lifecycle management, leaving you not only stalling critical business projects, but potentially exposing risk as you try to apply larger and larger scopes of network enforcement, on what really should be a service offering that autoscales and rapidly changes.
So let's tackle that challenge using an R77.30 gateway, and take away the risk of rushed upgrades or permissive policies now, before its too late to go back. You need time to migrate to R80.10, but you do not have to be without the benefits until you get there.
It's not like there isn't a patch required, but it is not a major version change, and if you are at the latest hotfix for 77.30, you probably already have what you need.
You will need the critical patch that allows you to take advantage of the SLAPI, as well as all the vSec integration currently available.
For the purposes of the SLAPI demo site, do not use a production gateway to test with, you should prepare a fresh install of R77.30.
To use the vSec table to propagate object changes for enforcement on the gateway, the gateway must first have Identity Awareness enabled.
- Log in to SmartDashboard.
- From the Network Objects tree, expand the Check Point branch.
- Double-click the Security Gateway on which to enable Identity Awareness.
- In the Software Blades section, select Identity Awareness on the Network Security tab.
The Identity Awareness Configuration wizard opens.
You will be presented with the methods for acquiring identities of managed and unmanaged assets.
- AD Query - Lets the Security Gateway seamlessly identify Active Directory users and computers.
- Browser-Based Authentication - Sends users to a Web page to acquire identities from unidentified users. If Transparent Kerberos Authentication is configured, AD users may be identified transparently.
- Terminal Servers - Identify users in a Terminal Server environment (originating from one IP address).
Terminal Servers must be selected to support the update of vsec objects. The presence of an actual terminal server is not required, but the limitation of one IP per object limitation of terminal server identities still applies.
The api integration must be enabled on the gateway through the command line utility pdp.
Once this is completed, the gateway is ready for the enforcement of vSec objects.