mgmt_cli without authentication ?

[Marc_Lampo]

With dbedit it is possible to start operations without authenticating : dbedit -local ... does not require to enter adminname and password.

mgmt_cli always needs a login phase to start the session.

For scripts (like run from cron) this means that adminname and credentials must somehow be available to the script.

Consequently, if the developer or sysadmin keeps a backup of the script, there is not only the functionality of the script, but also the credentials to gain access to the management server.

Personally, I would prefer to let the script focus on the functionality, and not hold credentials that might be changed independently (making the script fail on the next run after restore) or get lost in unauthorized hands who then might abuse them via the GUI ...

Would it make sense to formulate a feature request ?

- allow unauthenticated API access if connecting from/to 127.0.0.1 (like dbedit -local now)

- extend permission profile to state : API login only

    (if API is only accessible on 127.0.0.1 - the default - the account cannot be abused via GUI)

- extend permission profile to hold : source IP from where this administrator can connect

    (if we could specify 127.0.0.1 there, abuse via GUI gets harder - it would need ssh port forwarding
     and hence that admin would already need a Gaia login account to the management server)

- both if the above : "API login only" + "allowed source IP"

Your thoughts on this ?

[PhoneBoy]

SmartConsole would also appear to be an API client (versus using mgmt_cli or similar), so restricting to API-only may not necessarily be possible.

While I understand the convenience of dbedit -local (I've personally used it on occasion), I recall that the feature logged requests as "admin" or something similarly generic.

There is not an easy way to strongly associate these activities with a specific user.

In terms of creating your scripts, keep in mind each mgmt_cli command after authentication needs a session ID passed, which you get from executing the correct login commands.

You could separate the "authentication" function and the "task" functions into separate scripts. 

[Ofir_Shikolski]

https://community.checkpoint.com/people/ubialik‌

1. "allow unauthenticated API access if connecting from/to 127.0.0.1 (like dbedit -local now)" 

You can use mgmt_cli -r true

'

[--root, -r] {true|false}
When running on the management server, use this flag with value set to 'true' to login as Super User administrator.

'

2. "extend permission profile to state : API login only"

I think that will be nice idea , +1 

3. "extend permission profile to hold" 

I think that will be nice idea , +1 

[PhoneBoy]

I had forgotten about the -r true option, nice one

[Marc_Lampo · Accepted solution]

Thanks for this one as well !

Actually, it is : mgmt_cli login -r true  ("login" as argument still needed)

And, by the way, also not documented in the on-line documentation.

[Ofir_Shikolski]

I found it here https://community.checkpoint.com/message/1151  

# login as root without providing credentials

mgmt_cli login --root true > id.txt

[Bill_Ng]

I have been using mgmt_cli login --root true > id.txt in my scripts.  For each script it has a separate id.txt file.  Now the scripts are failing with Error: Failed to login to the management server.  I can use that command with a separate user account and it works there.  Seems like the root authentication is broken.  I restarted managment server, api server, cpstop, cpstart.  Those didn't help.  Any idea why this just started happening?

[Bill_Ng]

We figured out what was going on.  My script wasn't logging out of the sessions and I hit the 150 session limit.  I have since added the logout to the script.  I had to remove the inactive sessions as well.