Understanding Check Point MDS Management Beginner-Friendly Guide
NOTE: I attach a PDF with all this informations to be easier.
Introduction
When you start your journey with Check Point Software Technologies Firewalls, one of the first things you’ll notice is that there are many different types of management.
And yes… this can feel confusing at first — totally normal.
Types of Check Point Management
In the Check Point world, these are the most common management types you’ll hear about:
- SMS – Security Management Server
- Smart-1 Appliance
- Smart-1 Cloud
- Spark Management
- MDS – Multi-Domain Server
Today, we’ll focus on MDS, a powerful option that is often less talked about, but extremely important in large environments.
What is MDS (Multi-Domain Server)?
Think of MDS as a “management server that can host multiple independent management servers inside it.”
Instead of having:
- one SMS managing one environment
You get:
- one MDS managing many isolated environments, all running independently.
Each environment has:
- Its own objects
- Its own policies
- Its own administrators
- Its own logs
Perfect for service providers, large enterprises, or MSSPs.
DMS – Domain Management Server
A DMS is a virtualized management environment inside the MDS.
You can think of it like this:
DMS = a standalone SMS
Inside a DMS, you can:
- Create objects
- Build security policies
- Manage gateways
- Install policies
Each DMS is isolated from the others.
DLS – Domain Log Server
A DLS is responsible only for logs of a specific DMS.
- Each DMS can have its own DLS
- Logs are separated between domains
- Improves scalability and organization
DMLS – Domain Management Log Server
The DMLS is the component that:
- Hosts
- Manages
- Virtualizes
All the Domain Log Servers (DLS).
Think of it as the “log manager of the log managers”
MDS Initial configuration
To configure a Multi-Domain Server (MDS), the process starts by preparing the virtual machine that will host the MDS. This virtual machine must meet the MDS prerequisites.
Minimum Requirements
- CPU: Intel Pentium IV, 2.6 GHz – 8 vCPU
- RAM: 32 GB
- Disk Space:
- 100 GB for the MDS
- 110 GB for each Domain
Recommended Requirements
Hardware requirements can vary significantly depending on the log volume that the MDS and the Management Log Server (MLS) will handle.
As a starting point, it is recommended to double the CPU and memory compared to the minimum requirements.
For disk space, allocating 5 TB or more is advisable, based on practical experience.
Operating System for MDS
The MDS uses Gaia as its operating system, just like the Security Management Server (SMS) and Security Gateways.
What determines whether a Gaia system will function as an MDS is the First Time Wizard, where the Multi-Domain Server option is selected.
First-time configuration
After completing the initial Gaia configuration, access the Gaia Web Portal to run the First Time Wizard and convert this Gaia system into a Multi-Domain Server.
Below, you can see the available options. When creating the first MDS, keep “Primary Multi-Domain Server” selected, as it is a fundamental component. From this Primary MDS, you will later connect Secondary MDS servers and also the MDLS.
It is important to configure the Leading Interface. This is the physical interface that all Domains will use as their default routing exit point.
You may keep the default admin user or create a new administrator user.
After that, simply finish the wizard
Once the First Time Wizard is completed, Gaia will be available, and in the System Overview you will see the information indicating Check Point Multi-Domain Server.
On the Gaia of the MDS (Multi-Domain Server), there must be at least one interface that communicates with the network, allowing internet access if needed, or the proper configuration that enables the system to communicate with the security gateways.
After configured the MDS, you will access via SmartConsole client, MDS option will allow access to MDS domain controller, Global will allow access to the Global control plane.
You will create the DMS and DLS, is similar to have an SMS and one SMS dedicated to log server, but its virtualized DMS on MDS and DLS on MLMS.
An MDS environment uses two main databases:
1️⃣ Multi-Domain Server Database (mdsdb)
This database contains global infrastructure information, such as:
- MDS and Log Servers
- Domain Servers
- Domains
- Administrators and permissions
- GUI clients
- Security Gateways and installed applications
- All assigned Global Policy information
2️⃣ Global Domain Database
- Automatically created during MDS installation
- Acts as a shared/global domain
- Can receive objects and policies shared across multiple DMS environments
MDSM System Processes
Here’s a simplified view of the main processes running in an MDS environment.
MDS Processes
- FWM – Legacy main management process
- FWD – Audit log server process
- CPD – Core infrastructure communication
- CPCA – Certificate Authority management
- CPM – Handles Postgres DB tasks, SmartCenter, SmartEvent, Log Server
- PostgreSQL – Main database (port 5432)
- Solr – Logging database (port 8210, localhost)
- Indexer – Log indexing (dynamic high ports)
CPWD – Watchdog process
DMS Processes
Each DMS runs its own set of processes, such as:
- FWM
- FWD
- CPD
- CPCA
- SmartLog
- Indexer
Again: fully isolated per domain ✅
MDS Server – Data Flow (Simplified)
Here’s what happens behind the scenes when everything is working:
- SmartConsole connects to CPM (19009) and FWM (18190)
- Authentication flows between MDS and DMS via port 9009
- CPMI connects to the DMS FWM
- CPM validates and prepares the database for policy installation
- CPD exchanges status info with Gateways and DMS
- CPM queries status information
- FWD sends and receives logs per domain
- CPCA handles certificates (ICA)
PostgreSQL Database Location
If you’re troubleshooting or studying the system structure:
$CPDIR/database/postgresql
This is where the PostgreSQL database for MDS is stored.
Global Policies are policies created to define common rules across multiple Domains, avoiding the need to repeatedly create the same rules in each Domain’s Local Policy.
Some Commands:
Check Point MDS – Expert Mode Command Reference
Expert Mode Overview
In Expert mode, administrators can run standard Linux commands as well as Check Point–specific commands to manage and troubleshoot a Multi-Domain Server (MDS) environment.
Common Linux Commands
# df -h
Note:
If an MDLS is deployed, all Log Servers share the same disk of the Multi-Domain Log Server. Similarly, all Domains (DMS) within the MDS share the same disk on the MDS server, even though they are separate virtual instances.
# ls -lh
# mkdir
# free
# top
In the top command, it is common to see multiple log_indexer processes, because there is one per Domain (CMA). On the MDLS, there is typically one log_indexer per CLM (Log Manager).
# cd
# tail -f
Check Point Specific Commands
# cpview
The best tool on Gaia that allow you have a full vision for the system.
# cplic print
To see informations about license
# mdsstat
These commands are used to list Domains and to check the status of core MDS and DMS (CMA) processes, such as FWM, FWMHA, FWD, CPD, and CPCA.
> mdsconfig
Use mdsconfig menu configuration tool to reconfigure the MDS configuration after installation
Starting and Stopping Services
# cpstop DON’T WORK ON MDS
use mdsstop
# mdsstop
This command stops the entire Multi-Domain Server and all DMS instances (virtual Domains). Use with caution.
# mdsstart
Starts the entire MDS and all its DMS instances.
To stop or start a specific DMS (virtual Domain):
# mdsstop_customer <ip_address_cma>
# mdsstart_customer <ip_address_cma>
Switching Domain Context
To enter a specific Domain context from the CLI:
# mdsenv <domain-name or IP>
To verify the current Domain context:
echo $FWDIR
Check Point Jump Start: MDSM 1 – Lesson 1 – What is Multi-Domain Security Management Server
https://www.youtube.com/watch?v=edvVqKD_hYA&list=PLMAKXIJBvfAgSYXoCsh6pR6VOHpGKAkY9
The MDS ecosystem has evolved significantly from older versions to the current releases. Terminology and concepts have been updated over time, so it is important to pay attention to changes introduced in R81.20 and later versions.
Part 1 - The Architecture
Part 2 - Preparing the Lab
Part 9 - Application Control, URL Filtering and Content Awareness
Part 11 - Threat Prevention
Part 12 - Logs and Reporting
