- Products
- Learn
- Local User Groups
- Partners
- More
AI Security Masters E7:
How CPR Broke ChatGPT's Isolation and What It Means for You
Blueprint Architecture for Securing
The AI Factory & AI Data Center
Call For Papers
Your Expertise. Our Stage
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
Ink Dragon: A Major Nation-State Campaign
Watch HereCheckMates Go:
CheckMates Fest
Good morning!
I am trying to create a script to automate (Gaia) admin users creation in a cluster with 'cloning group feature enabled'. This cluster is composed of two gateways (fwext01 and fwext02). We have R81.10, take 66 on them.
When I run the script on fwext01, for example, these are the commands that are executed:
clish -s -f comandos.txt
(The content of 'comandos.txt' file is:)
set cloning-group-management on
add user adm_mickeymouse uid 0 homedir /home/adm_mickeymouse
set user adm_mickeymouse realname "Mickey Mouse"
set user adm_mickeymouse password-hash $6$PSTU$EvYhx6iMbZygtZamlZ8MRH0RfeVFGRMpnyfYyeGuXE5O6qq93VB77v.0kVFOEXeRC39gxZBidj4ccOTrGE48x2
set user adm_mickeymouse force-password-change yes
add rba user adm_mickeymouse roles adminRole
set user adm_mickeymouse shell /bin/bash
save config
set cloning-group-management off
The results of script execution on fwext01 is totally correct:
add user adm_mickeymouse uid 0 homedir /home/adm_mickeymouse
add rba user adm_mickeymouse roles adminRole
set user adm_mickeymouse gid 0 shell /bin/bash
set user adm_mickeymouse realname "Mickey Mouse"
set user adm_mickeymouse password-hash $6$PSTU$EvYhx6iMbZygtZamlZ8MRH0RfeVFGRMpnyfYyeGuXE5O6qq93VB77v.0kVFOEXeRC39gxZBidj4ccOTrGE48x2
But... When I look the configuration that was automatically reflected on fwext02 (via cloning group features), I realize that the password is not being replicated at all:
add user adm_mickeymouse uid 0 homedir /home/adm_mickeymouse
add rba user adm_mickeymouse roles adminRole
set user adm_mickeymouse gid 0 shell /bin/bash
set user adm_mickeymouse realname "Mickey Mouse"
set user adm_mickeymouse password-hash *
Could anyone please help us with this?
Thanks!
It was a bug and people from R&D developed a fix. Thanks.
Could you please elaborate on how you ae using cloning to replicate config on the second FW?
Hello _Val_
Since I am startig the comands execution with 'set cloning-group-management on', it was supposed that all the comands would be automatically replicated to the second FW, correct?
This expected replication is ocurring normally for all the commands inside 'comandos.txt' file. The only exception refers to the "set user adm_mickeymouse password-hash $6$PSTU$EvYh..." command. I mean, the hash config is not being replicated.
I realized that this is also happening even when I execute these commands (via clish) interactively.
But... When I create this user via Gaia GUI in FW1, the password is automatically and correctly replicated on FW2.
Thanks!
Oh I see. Is it for all users, or for this specific hash only?
If the latter, I would assume the hash is treated as a variable, since it starts with $. Otherwise, looks like a but to me. If it is a global issue, please raise a TAC case for it.
This is happening for any user I try to create. And it seems that is happening for any hash.
I tried to use MD5 ($1$) hash and the behavior was the same.
I also tried to use single and double quotes around the hash (to try to avoid the 'hash being treated as variable'). But the behavior is the same.
I´ll contact TAC staff.
Thanks anyway!
Understood. Please let us know what TAC finds out, when it is resolved. Meanwhile, you can use the same scripts on both members to define users, without cloning groups feature
Yes, it would be possible to run the scripts separately. But in order to do that I would have to remove "Users and Roles" from the Cloning Group Shared Features list. Otherwise, the system will not allow me to add the user. It warns me with the following message: "CLINFR0699 This command belongs to a cloning group synchronized feature and therefore cannot be executed in normal mode."
Yes, I will let you know what TAC finds out!
Thank you very much for your attention and help!
It was a bug and people from R&D developed a fix. Thanks.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 66 | |
| 19 | |
| 13 | |
| 12 | |
| 11 | |
| 9 | |
| 9 | |
| 7 | |
| 7 | |
| 7 |
Tue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementTue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFTue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY