Need clarification on the Users DB
Need clarification on the Objects DB
Need clarification on the “Install database..” option in the “Policy” menu in SmartDashboard.

Problem:

The Check Point Security Management Architecture (SMART) is extremely involved (convoluted even?) and can be confusing to understand.

Definitions of terms used:

Security Magagement Server (SMS) AKA SmartCenter Server for R65 and older: This is what you log into with SmartConsole

SmartConsole: The entire GUI client that is needed to manage Check Point SMART, this includes SmartDashboard, SmartUpdate, SmartView X, etc…

Multi-Domain Server (MDS) AKA Provider-1 (phrase isn’t gone but depreciated): A management server that can manage several different virtual SMSs.

Customer Management Add-on (CMA): Is the domain, or virtual SMS, that is managed by MDS

Standalone Deployment: Single device has both Management and Firewall modules installed on same device.

Distributed deployment: Management is installed on separate server.

Management Module: The management (SMART) service (fwm process) that can manage a checkpoint gateway. You must have this service running on the device you connect to with SmartConsole

Firewall Module: really this is the full security services suite (processes like fwd, vpnd, and fgd to name a few) that is managed by fwm…

Solution:

First explanation of the reference databases:

Users DB:
This is the database of all users created via SmartDashboard. This does not include the one SMART administrator created via cpconfig (or the equivalent ‘cp_conf admin add’) CLI. You are only able to create 1 admin this way, and the Users DB has a variable of “cpconfig_administrators” in its place.

Objects DB:
The objects db is simply all objects that are created in SmartDashboard. ALL objects (except Users as that is a separate DB). So you can have separate policies (with different install targets), but this Object DB is the same across all of them. This gets interesting when you have a lot of objects with automatic NAT rule creations defined, that don’t have an install on target. You might just end up with an Edge gateway (barely +consumer grade) with a 200 NAT rulebase on them, and a customer wondering why they have a < 10 host gateway with consistent 95% CPU utilization. This is because those Automatic NAT rules are defined by the object and all objects are included in all policies managed by that SMS (MDS provides separation of objects DB on a per CMA basis, but a CMA from an MDS is equivalent to a single SMS).

Relation of Users / Objects DB Between Management and Firewall Modules:
When you change the users or objects for your deployment, in SmartDashboard, the “File” menu > “Save” function will update these on your Management module; however, even in a standalone deployment, it does NOT update this change on your FIREWALL module. In concern with the firewall module, the save function is similar to entering commands into an SRX, all your doing is pushing the changes made on your client to a “candidate” configuration; however, like the SRX “commit” command, no functionality change is made until you issue an “install” command.

It is true that policy install pertains to the installation of the firewall / NAT rulebases and VPN configuration; however, it also includes the install database function that is required for updating the users / objects database on the firewall module.

Just remember that even in standalone deployments, the firewall and management modules are completely separate services. It is easiest to always consider them separate servers, so you know that the firewall module never knows about your changes to the configuration without pushing the configuration to it. If you think about it that way, then it would be only logical that your firewall’s remote VPN configuration is clueless to a newly configured user without installing it.

I keep saying the firewall module, because that user change behavior is not the same on the MANAGEMENT module. The only users the management module cares about is the administrators, and a save is adequate to make those changes work. IE if you add an administrator in SmartDashboard, then go to “file” > save…, the new administrator can immediately log into SmartConsole using that new user. The objects db does require an “Install Database…” to a management module, but the only case that this is required is when a change / addition to the management module for that server’s object itself is made.

“Install Database…” explained:
In regards to “Install Database…”, this function installs two things, 1) the user database, and 2) the object database. By default, this function can only target SMART servers (IE not security gateways). Examples of such servers are the SMS (though this should only be needed when editing the management module of that server’s object, as “save” has the same function pertaining to the user DB for the management module), SmartLog or segregated log servers, and SmartReporter servers; the latter two being the reason the option is even available, really. That is because those databases need to be updated when user or object changes are made as SMART servers are not policy install targets, so instead they are install database targets.

IMPORTANT NOTE: It is not necessary to use this on secondary SMS in an SMS HA deployment, as it uses a sync functionality that is more complete (and using install database may break the management HA sync stats for the HA SMS deployment).

In a standalone deployment, installing the database to the localhost also installs it to the firewall module as well as the local SMS. Sk18666 explains how to configure install DB to target a gateway in a distributed deployment, but warns (a warning which is applicable to installing DB to localhost on a standalone as well): “Warning: Installing only the User Database on the Security Gateway is not recommended. If you do not install the policy at the same time, you can cause the User Database and Policy Database to be out of sync with each other, and thus cause unexpected behavior. That is the reason the option is disabled by default.”

In other words, the recommended way of installing these databases onto a security gateway is to install the policy.