What is an OS security policy in NSP?

OS security password management

The use of an OS security policy provides the ability for the NSP to continue to manage a model-driven NE when anti-theft mode is enabled. The OS security policy defines the password the NSP uses to unlock the NE for NSP management when the NE is locked by anti-theft protection.

The OS security password can be configured using CLI on the NE, or configured using NSP and pushed to the NE.

If a password is configured on the NE prior to discovery, the password configured in the OS security policy in the NSP UI must match the password configured on the NE to discover the NE.

If the NE is locked at the time it is discovered by the NSP, successful discovery unlocks the NE.

Caution: NSP 25.4 or later artifacts with adaptation for anti-theft must be installed in the NSP deployment before anti-theft is enabled on the NEs. Management of classic NEs in anti-theft mode is not supported in NSP.

Applying the policy to the NE

An OS security policy can be included with a unified discovery rule. The anti-theft password provided by the OS security policy is applied to all compatible NEs that are discovered by the unified discovery rule. If the discovery rule includes devices that are not compatible with anti-theft or do not have anti-theft enabled, the OS security policy has no effect on the NE.

When anti-theft is enabled on an NE the NE immediately locks, requiring the password to unlock and continue to manage the NE. Therefore, an OS security policy must be associated to the discovery rule before anti-theft mode is enabled on the NE.

Click on an OS security policy in the Network Security, OS Security Policies view to see the discovery rules that use the policy and the included NEs, that is, the NEs for which the password in the policy applies.

See Pathway: manage OS security for the high-level process.

Troubleshooting

If an anti-theft error has occurred, check the MDM server and MDM Tomcat logs for details on the root cause.

Table 7-1, OS Security and Anti-theft troubleshooting describes some failure scenarios and provides troubleshooting information.

Table 7-1: OS Security and Anti-theft troubleshooting

Problem

Relevant message in logs

Alarm

Solution

In rare cases, after an NE reboot caused by OS security password or anti-theft operations, a mismatch of the anti-theft or OS security status may occur between NE and the NSP.

Re-discover the NE in force mode using the RESTCONF API.

See Device Administration and Mediation RESTCONF APIs on the Network Developer Portal

When assigning an OS security policy to a discovery rule, if there are already NEs managed that support anti-theft, updating the OS security policy fails.

Can not change the os policy while managed nodes support Anti Theft in RESTCONF response or mdm-tomcat log

  1. Unmanage all NEs associated with the discovery rule that support anti-theft

  2. Associate an OS security policy with the discovery rule.

  3. Manage the NEs again.

If the discovery rule already has an OS security policy associated with it and you want to attach a new OS security policy, you need to delete the discovery rule, create a new one and add the new OS security policy and NEs.

The OS security policy cannot be changed if one is already attached to the discovery rule.

If the NE is locked, deploying a device configuration template to the NE fails.

Verify that NEs are unlocked, reachable, and have the correct OS security policy associated before updating any configuration.

Problems encountered when unlocking the NE

Password mismatch 

Failed to process RPC request to NE: Operation failed - incorrect password entered

in mdm-server log

Error while unlocking anti-theft mode: password is incorrect or Netconf Error. Check MDM server logs for details.

  • If the operation failed because of a network connectivity issue, unlock the NE from NSP after the networking issue is fixed; see “How do I unlock an NE?” in the NSP Device Management Guide.

  • If the operation failed on all NEs associated to the same OS security policy:

    1. Update the current OS security password with the "Change password only" option on the security policy edit form; see How do I edit or delete an OS Security policy?

    2. Unlock the NE; see “How do I unlock an NE?” in the NSP Device Management Guide.

  • If the operation failed on subset of NEs associated with the same os-security policy, update the OS security password on the affected NEs using CLI.

No OS security password is attached to the unified discovery rule

No OS policy attached to the discovery rule

in mdm-tomcat or mdm-server logs

No OS policy attached to the discovery rule. Attach the OS policy and force rediscover.

Attach the OS policy and perform a force rediscover operation in the API.

An OS security password is attached to the unified discovery rule, but can’t be found by NSP

Attach the OS policy and perform a force rediscover operation in the Device Administration API.

Problems encountered when pushing a password

The NE is not associated with an OS security policy

Can not find the password to be pushed to node ID; Please make sure the node is associated with a security policy  in RESTCONF

OS password is not configured on node ID; Please configure OS password first in mdm-tomcat log

Associate an OS security policy to the discovery rule the NE belongs to.

Password specified in RPC is the same as the password on the NE.

"The new password (from the os policy) is the same as what is currently configured on node from RESTCONF

  1. Update the OS security password using NSP, see How do I edit or delete an OS Security policy?

  2. Trigger a password push; see “How do I push the OS password to NEs?” in the NSP Device Management Guide.

Failed to push new password when the previous push failed.

Push os password is in progress or failed on node from RESTCONF

  • If the previous push failure was caused by network connectivity issues, fix the issue and trigger password push again; see “How do I push the OS password to NEs?” in the NSP Device Management Guide.

  • If the previous push failure was caused by mismatch of CLI OS security password, update the mismatched password on the NE and trigger password push again.

Failed to push new password because the previous push is still in progress.

Push os password is in progress or failed on node from RESTCONF

Wait until the current password push process is complete before triggering password push operation again.

Password mismatch

Operation failed - current-password incorrect from mdm-server log

Error while pushing OS password : current password is incorrect or Netconf Error. Check MDM server logs for details.

  • If the operation failed on all NEs associated to the same os-security policy:

    1. Update the current OS security password with the "Change password only" option on the security policy edit form; see How do I edit or delete an OS Security policy?

    2. Update the policy again with the “Change password and create a scheduled operation to push it to the NEs” option with a new OS security password.

  • If the operation failed on subset of NEs associated with the same OS security policy:

    1. Update the OS security password on the affected NEs using CLI.

    2. Trigger a password push again; see “How do I push the OS password to NEs?” in the NSP Device Management Guide.

Problems encountered when updating anti-theft mode

Push anti-theft mode to NE without an OS security password configured on the NE

OS password is not configured on node ID Please Configure os password first from RESTCONF

  1. Trigger a password push; see “How do I push the OS password to NEs?” in the NSP Device Management Guide.

  2. Turn on anti-theft mode; see “How do I enable or disable anti-theft mode?” in the NSP Device Management Guide.

Failed to enable or disable anti-theft due to password mismatch

Operation failed - incorrect password entered in mdm-server log

Error while pushing Anti Theft mode : current password is incorrect or Netconf Error. Check MDM server logs for details.

Anti-theft mode is already set to the mode specified in RPC.

Anti-theft mode is already set to mode on node ID from RESTCONF