Can a Permission Profile allow 'Manage Administrators' without 'Install Policy' rights?"

[todd]

Hi CheckMate Community,

Due to auditor requirement, I am attempting to create a customized Permission Profile (Profile_SecOps_Approver) in SmartConsole for an administrator who needs to manage other administrator accounts, but should not have the ability to install policies on Security Gateways.

However, under Management Permissions, the "Manage Administrators" checkbox remains greyed out (with a lightbulb icon), even when set to Customized in the Overview section.

1. Is it architecturally possible in Check Point SMS to separate Manage Administrators rights from full Policy Write/Install permissions?

2. If this is blocked by design to prevent privilege escalation, what is the recommended best practice for segregating Admin Identity Management from Gateway Deployment duties?

Thanks!

Todd

[Tomer_Noy · Accepted solution]

It seems that today the ability to manage admins and permission profiles is tied to having "Read/Write All" (not "Customized") permissions.

This is to avoid misleading a customer into thinking that such an admin cannot modify the DB, but in effect they can create a new profile & user for themselves and do anything.

If you need this separation for Audit purposes, you can leverage the extensibility of SmartTasks. You can create a "Before Policy Installation" task and provide a script or web hook that will check the admin name or his permission profile, and block the operation. You can also have a similar task in "Before Publish" and check the changes in the session to see if all changed objects were of type Administrators or Users, and block the publish if other objects were touched.

Just make sure to write your script carefully, since you may be unable to push policy if you have a bug that affects all admins.
In case of emergency, a superuser can disable the SmartTask.

[jorgeluiznim · Accepted solution]

Hi @todd ,

@Tomer_Noy 's answer is the definitive one here — it's by design, and worth understanding why, because that rationale is also your answer to the auditor: anyone who can manage administrators and permission profiles can create a profile and account for themselves with any rights. So a "Manage Administrators without Install Policy" profile would give the appearance of separation without the substance. That's a stronger audit position than a control that looks separated but isn't.

Framed for an audit conversation, you have three layers to work with:

1. Preventive (technical) — the SmartTask approach Tomer described. Two useful details when you build it: the Web Request action posts the trigger data as JSON to your endpoint, and for a "Before" trigger your endpoint replies HTTP 200 with a JSON body containing result (and optionally message) to allow or abort the operation. So you can genuinely block a publish/install, and return a message the admin sees.

Practical safety, on top of Tomer's warning: test it against a narrow scope first, keep a documented break-glass superuser account, and make sure your endpoint fails open or closed deliberately — decide in advance what should happen if the webhook is unreachable, because that's the scenario that bites people.

2. Detective (accountability) — every administrator action is recorded in the management audit logs (Logs & Monitor). For many audit frameworks, when preventive segregation isn't architecturally available, a documented detective control — audit logging, alerting on policy installs by the identity-management admin, and periodic review — is an accepted compensating control. Pair that with the SmartTask and you have both layers.

3. Process/architecture — the option worth considering if the auditor wants true separation of duties: take administrator provisioning out of interactive SmartConsole entirely and drive it through the Management API from your IAM/PAM platform. The privileged credential lives in the PAM vault with approval workflow, just-in-time elevation and session recording, so the segregation of duties is enforced in the process layer where auditors usually expect to see it. To be clear, this doesn't bypass the design — the API identity still holds equivalent permissions — but it moves the control to an auditable, approval-gated workflow instead of a standing human privilege. That distinction is usually what satisfies the finding.

Also worth having in place regardless: 2FA for administrators and trusted-client/login restrictions on the management.

Hope this helps!

Best regards,
Jorge Dias Junior

[Tomer_Noy]

Great explanation!

One more idea - you can use SAML authentication for your SmartConsole admins with your preferred IDP (EntraID, Okta, ...).
This also makes it easier to implement 2FA.

This way the admins & association to roles are actually managed in your Identity Provider, and you don't need to grant the person who manages the identities any direct access to SmartConsole.

[todd]

Hi @Tomer_Noy @jorgeluiznim 

Thank you all for the detail explanation. This is really helpful.

Let me try to use SmartTasks to achieve that. SmartTasks is a new to me.

Thank you!

Todd

[jorgeluiznim]

Hi @todd ,

Thank you for coming back and letting us know! We're glad to hear our explanation was helpful.

We also really appreciate you taking the time to share that it worked out. Feedback like this is very important to the community it helps us know we're on the right track and that our suggestions are making a difference.

Thanks again, and good luck with SmartTasks! Feel free to reach out if you have any other questions.

[todd]

Hi @Tomer_Noy @jorgeluiznim ,

Thank you for your suggestion.

I have finished testing SmartTask in my lab, and the test results met my expectations.

Although users can disable SmartTask to bypass , this practice provides a new insight into how SmartTask operates."

I am not familiar with scripting, so I had AI write the scripts for me.

[jorgeluiznim]

Hi @todd ,

Thank you so much for coming back and sharing this update! Feedback like this is hugely important for the CheckMates community. It shows what actually works in real-world scenarios and helps all of us learn, grow, and support each other more and more. I'm really glad the SmartTask approach met your expectations and helped solve the requirement!

And hey, don't worry at all about using AI to generate those scripts! Full disclosure: I use AI all the time too! Being from Brazil and not having English as my native language, AI is my best wingman. It helps me translate and structure my technical thoughts so I can keep contributing and helping everyone here in the community.

As long as we practice "conscious AI usage" and keep a break-glass superuser handy just in case the AI gets a little too creative with its code, it's an incredible tool to boost our work!

Thanks again for testing it out and closing the loop with the community. Wish you all the best, and feel free to reach out anytime!

Best regards,
Jorge Dias Junior