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

Management API simple-gateway one-time-password

What is the intent of the "one-time-password" option for the set-simple-gateway API?  I had taken this to mean it was a way to set the SIC key for a gateway on the management server side.  However, if I building a new gateway, this doesn't cause the SIC exchange to occur via CPD, nor does it appear to occur during a subsequent policy-install.  Yes, after building the new gateway, did configure SIC in cpconfig first.

I was hoping this would be a way to automate a deployment in some manner to reduce the need to click those buttons in SmartConsole. 😞  I will be moving a customer's SmartCenter management to Azure and was hoping to use this API for the SIC reset.  More specifically, I was going to use the "cp_conf sic init <new-key> norestart" on the gateway to reset the SIC quietly, and combine this process with the API "set-simple-gateway name <foo> one-time-password <new-key>" and policy install.

Let me know if there's a way to do this without a trip to SmartConsole.

 

Thanks!

0 Kudos
1 Solution

Accepted Solutions
Joseph_Audet
Ambassador
Ambassador

Duane - I ran this through in my lab. The API call does what you want, but you missed the 'reset-sic' call first (equivalent to clicking it in Smart Console'. However, I could not get SIC to re-establish correctly on several tries with the 'norestart' option, had to restart services before the mgmt server was able to re-establish SIC. It appears without the services restarting the old SIC certificate is still presented in communications based on this error after I ran the reset-sic and set one-time-password options (these worked fine when I removed the norestart option):

mgmt_cli -r true test-sic-status name "DEMOGW7" --format json
{
"sic-message" : "SIC Status for DEMOGW7: Not Communicating. Peer SIC Certificate has been revoked. ** Try to reset SIC on the peer and re-establish the trust **",
"sic-status" : "not communicating",
"sic-name" : "CN=DEMOGW7,O=mgmt-sa1.lab.joeaudet.com.3cphmg"
}

What worked for me was this sequence:

  • GW:
    • cp_conf sic init abcd1234
  • MGMT:
    • mgmt_cli reset-sic name "DEMOGW7" --format json
    • mgmt_cli set simple-gateway name "DEMOGW7" one-time-password 'abcd1234' --format json
    • mgmt_cli test-sic-status name "DEMOGW7" --format json
    • mgmt_cli install-policy policy-package "Allow_All_Demo" access true targets.1 "DEMOGW7" --format json

Policy installed successfully, and able to confirm with the below command:

mgmt_cli -r true test-sic-status name "DEMOGW7" --format json
{
"sic-message" : "SIC Status for DEMOGW7: Communicating",
"sic-status" : "communicating",
"sic-name" : "CN=DEMOGW7,O=mgmt-sa1.lab.joeaudet.com.3cphmg"
}

Someone else may have some insight on if you can do it with the 'norestart' option but it didnt work for me. Tested with R81.20 mgmt and R81.10/20 GW versions.

Thanks

View solution in original post

3 Replies
Joseph_Audet
Ambassador
Ambassador

Duane - I ran this through in my lab. The API call does what you want, but you missed the 'reset-sic' call first (equivalent to clicking it in Smart Console'. However, I could not get SIC to re-establish correctly on several tries with the 'norestart' option, had to restart services before the mgmt server was able to re-establish SIC. It appears without the services restarting the old SIC certificate is still presented in communications based on this error after I ran the reset-sic and set one-time-password options (these worked fine when I removed the norestart option):

mgmt_cli -r true test-sic-status name "DEMOGW7" --format json
{
"sic-message" : "SIC Status for DEMOGW7: Not Communicating. Peer SIC Certificate has been revoked. ** Try to reset SIC on the peer and re-establish the trust **",
"sic-status" : "not communicating",
"sic-name" : "CN=DEMOGW7,O=mgmt-sa1.lab.joeaudet.com.3cphmg"
}

What worked for me was this sequence:

  • GW:
    • cp_conf sic init abcd1234
  • MGMT:
    • mgmt_cli reset-sic name "DEMOGW7" --format json
    • mgmt_cli set simple-gateway name "DEMOGW7" one-time-password 'abcd1234' --format json
    • mgmt_cli test-sic-status name "DEMOGW7" --format json
    • mgmt_cli install-policy policy-package "Allow_All_Demo" access true targets.1 "DEMOGW7" --format json

Policy installed successfully, and able to confirm with the below command:

mgmt_cli -r true test-sic-status name "DEMOGW7" --format json
{
"sic-message" : "SIC Status for DEMOGW7: Communicating",
"sic-status" : "communicating",
"sic-name" : "CN=DEMOGW7,O=mgmt-sa1.lab.joeaudet.com.3cphmg"
}

Someone else may have some insight on if you can do it with the 'norestart' option but it didnt work for me. Tested with R81.20 mgmt and R81.10/20 GW versions.

Thanks

Duane_Toler
Advisor

Sweet! Thanks for the time and effort on this!  I see now that this is new as of R81.20.  I did omit an important piece of info, accidentally;  I was doing this on R80.40 management, and I see it has no reset-sic API.  I'm working with my customers to start moving them to R81.20.  I typically prefer to wait for the first JHF (as a matter of policy), although I still have high expectations that R81.20 management is very solid from the beginning!

 

Thanks for confirming the new API does indeed do the right things.  I'm very eager to use it!

 

Duane_Toler
Advisor

Replying to myself, borderline necro-posting...

The steps from @Joseph_Audet are 100% correct.  I confirmed on my R81.20 management server. 

For CloudGuard R81.20 gateways, however, the new templates deploy an NSG (presumably for NSG flow logs?), but the default NSG doesn't allow inbound connections other than SSH.  This was blocking my initial attempts.  After adding a rule to allow traffic, it works.

EDIT: The NSG item was my issue; I was detaching the public IP and upgrading it to Standard SKU for a future Standard SKU front-end load-balancer for a single gateway deployment.  Using the azure_rm_networkinterface module pushed the config to the Azure API controller with implicit attribute of "create_with_security_group: true", which created a new NSG allowing only SSH and attached it to the interface.  This caused some issues. 🙂 I revised my playbook to add "create_with_security_group: '{{ vmName }}-nsg'" which associates the CloudGuard deployment-created NSG (I could have done "false", but to achieve NSG flow logs, an NSG must be assigned).  After that was corrected, the revised Ansible sequence below worked as-is, without reset-sic/test-sic-status; which is the desired, intended, and expected result.

My Ansible playbook sequence:

 

- name: Add gateway
  check_point.mgmt.cp_mgmt_simple-gateway:
    name: "{{ gw_item }}"
    one_time_password: "{{ ckp_sic_key }}"
    ... other parameters...

- name: Publish
  check_point.mgmt.cp_mgmt_publish:
    wait_for_task: true

- name: View SIC status
  debug:
    msg: "{{ gw_sic_status }}"

 

 

#ItWorksNow

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events