Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Marc_Lampo
Contributor
Jump to solution

mgmt_cli without authentication ?

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 ?

0 Kudos
1 Solution

Accepted Solutions
Marc_Lampo
Contributor

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.

View solution in original post

7 Replies
PhoneBoy
Admin
Admin

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. 

0 Kudos
Ofir_Shikolski
Employee
Employee

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
Admin
Admin

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

Marc_Lampo
Contributor

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
Employee
Employee

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
Collaborator

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?

0 Kudos
Bill_Ng
Collaborator

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.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events