Manage System Access and Security

This section contains the following topics:

Manage Certificates

What is a Certificate?

A certificate is an electronic document that identifies an individual, a server, a company, or another entity, and associates that entity with a public key. When a certificate is created with a public key, a matching private key is also generated. In TLS, the public key is used to encrypt data being sent to the entity and the private key is used to decrypt. A certificate is signed by an issuer or a "parent" certificate (Certificate Authority) - i.e. signed by the parent's private key. Certificates can also be self-signed. In a TLS exchange, a hierarchy of certificates is used to verify the validity of the certificate's issuer. This hierarchy is called a trust-chain and consists of 3 types of entities: a root CA certificate (self-signed), possibly multiple levels of intermediate CA certificates, and a server (or client) certificate (end-entity). The intermediate certificates act as a “link of trust” linking the server certificates to the CA’s root certificate and providing additional layers of security. Starting from the root certificate's private key, the private key for each certificate in the trust chain signs and issues the next certificate in the chain until finally signing an end entity certificate. The end-entity certificate is the last certificate in the chain and is used as a client or server certificate. For more details about these protocols, see X.509 Certificates and HTTPS.

How are Certificates Used in Crosswork?

Communication between Crosswork applications and devices as well as between various Crosswork components are secured using the TLS protocol. TLS uses X.509 certificates to securely authenticate devices and encrypt data to ensure its integrity from source to destination. Crosswork uses a mix of generated and client uploaded certificates. Uploaded certificates can be purchased from Certificate authorities (CA) or can be self-signed. For example, the Cisco Crosswork VM-hosted web server and the client browser-based user interface communicate with each other using Crosswork generated X.509 certificates exchanged over TLS.

The Crosswork Cert Manager is a proxy for multiple microservices and services within the distributed framework and manages all the Crosswork certificates. The Certificate Management UI (Administration > Certificate Management) allows you to view, upload, and modify certificates. The following figure displays the default certificates provided by Cisco Crosswork.

Figure 1. Certificate Management UI

Certificate Types and Usage

The following figure shows how Crosswork uses certificates for various communication channels.

Figure 2. Certificates in Cisco Crosswork
Certificate Types and Usage

These certificates are classified into various roles with different properties depending on their use case as shown in the following table.

Role

UI Name

Description

Server

Client

Allowed operations

Default Expiry

Allowed Expiry

Crosswork (CW) Internal TLS

CW- Internal- Communication

  • Generated and provided by Crosswork.

  • This trust-chain is available in the UI (including the server and client leaf certificatess) and are created by Crosswork during initialization. They are used for interprocess communications between Crosswork and CDG as well as communication between internal Crosswork components.

  • Allows mutual and server authentication.

CW

  • CDG

  • CW

Download

5 years

—

CW Web Server

CW-Web-Certificate

Server Authentication

  • Generated and provided by Crosswork.

  • Provides communication between the user browser and Crosswork.

  • Allows server authentication.

CW Web Server

User Browser or API Client

  • Upload

  • Download

5 years

30 day - 5 years

ZTP SUDI

 CW-ZTP-Device-SUDI

  • A public Cisco certificate that is provided as part of Crosswork.

  • Provides ZTP protocol communication channel between the ZTP application and device.

  • Allows server authentication.

CW ZTP

Device

  • Upload

  • Download

100 days

30 day - User defined

Secure ZTP Provisioning

CW-ZTP-Owner

  • Generated and provided by Crosswork.

  • Forwarded by ZTP to devices and used for second layer of encryption.

CW ZTP

Device

  • Upload

  • Download

5

30 day - User defined

Device Syslog

 CW-Device-Syslog

  • Generated and provided by Crosswork.

  • Provides Syslog telemetry communications between devices and CDG.

  • Allows server authentication.

CDG

Device

Download

5 years

—

Device gNMI Communication

—

Provides GNMI telemetry communications between devices and CDG.

CDG

Device

  • Upload

  • Download

Not Applicable

30 day - User defined

Server Syslog

Not Applicable

  • Allows syslog events and logs from Crosswork to an external Syslog server.

  • Allows server authentication.

External Syslog Server

Crosswork

  • Upload

    Note 

    You can upload multiple certificates associated with different servers.

  • Download

—

30 - User defined

External Destination

—

Exports telemetry data from CDG to external destinations (Kafka or GRPC).

External Destinations (Kafka or GRPC)

CDG

  • Upload

    Note 

    You can upload multiple certificates associated with different destinations.

  • Download

—

30 - User defined

There are two category roles in Crosswork:

  • Roles which allow you to upload or download trust chains only

  • Roles that allow upload or download of both the the trust chain and an intermediate certificate and key

Add a New Certificate

You can add certificates for the following roles:

  • External Destination: Certificates uploaded for this role are used to secure communication between CDG and external destinations like Kafka servers. To enable mutual authentication, the user uploads a CA Certificate Trustchain that will be common to both CDG and the external server. This trust chain contains a root CA certificate and any number of optional intermediate CA certificates. The last intermediate certificate in the chain and its corresponding private key is uploaded separately in the UI using Intermediate key, Intermediate certificate, and optionally Passphrase (if one was used for generating the intermediate key). Crosswork will internally create a client certificate using this intermediate key for the CDGs that will connect to the external destination. The destination (for example: Kafka) server certificate trust needs to be derived from the same root CA certificate.

  • Syslog Server Communication: The user uploads the trust chain of the Syslog server certificate. This trust chain is used by Crosswork to authenticate the Syslog server. Once this trust chain is uploaded and propagated within Crosswork, the user can add the syslog server (Administration > Settings > Syslog Server Configuration) and associate the certificate to enable TLS. For more informaton, see Configure a Syslog Server.

  • Devices gNMI communication: The user uploads a bundle of trust chains used by CDG to authenticate the devices connecting to it. This trust chain and the device gNMI certificate must also be configured on the device. The trust chain file that is uploaded can contain multiple hierarchies of trust certificates as needed to allow all the devices in the network to connect. For more information, see Configure gNMI Certificate.

  • Secure LDAP Communication: The user uploads the trust chain of the secure LDAP certificate. This trust chain is used by Crosswork to authenticate the secure LDAP server. Once this trust chain is uploaded and propagated within Crosswork, the user can add the LDAP server (see Manage LDAP Servers) and associate the certificate.


Note

Cisco Crosswork does not receive a web certificate directly. It accepts an intermediate CA and intermediate Key to create a new web certificate, and apply it to the Web Gateway.

If you prefer to upload your own ZTP (Zero Touch Provisioning Concepts) and web certificates (instead of using the default certificates provided within Cisco Crosswork), use the Edit function (see Edit Certificates.

Before you begin

  • For information on certificate types and usage, see Certificate Types and Usage.

  • All certificates that are uploaded must be in Privacy Enhanced Mail (PEM) format. Note where these certificates are in the system so that you can navigate to them easily.

  • Trust chain files that are uploaded may contain the entire hierarchy (root CA and intermediate certificates) in the same file. In some cases, multiple chains are also allowed in the same file.

  • Intermediate Keys need to be either PKCS1 or PKCS8 format.

  • A data destination must be configured prior to adding a new certificate for an external destination. For more information, see Add or Edit a Data Destination.

Procedure

Step 1

From the main menu, choose Administration > Certificate Management and click Add icon.

Step 2

Enter a unique name for the certificate.
Step 3

From the Certificate Role drop-down menu, select the purpose for which the certificate is to be used. For more information, see Manage Certificates.

Step 4

Click Browse, and navigate to the certificate trustchain.

Step 5

In the case of an External Destination certificate, you must select one or more destinations and provide the CA certificate trustchain, intermediate certificate and intermediate key. The passphrase field is optional and is used to create the intermediate key (if applicable).

Step 6

Click Save.

Note 

Once uploaded, the Crosswork Cert manager accepts, validates, and generates the server certificate. Upon successful validation, an alarm ("Crosswork Web Server Restart") will indicates that the certificate is about to be applied. The Certificate Management UI then logs out automatically and applies the certificate to the Web Gateway. The new certificate can be checked by clicking the lock <Not Secure>/<secure> icon next to the https://<crosswork_ip>:30603.

Edit Certificates

You can edit a certificate to add or remove connection destinations, upload, and replace expired or misconfigured certificates. User provided certificates and ZTP and web certificates can be edited. Other system certificates that are provided by Cisco Crosswork cannot be modified and will not be available for selection.

You can also “remove” a certificate by following this procedure to replace the certificate or by disabling security (disable Enable Secure Communication option) for any assigned destinations (see Add or Edit a Data Destination). Permanently deleting a certificate from the Cisco Crosswork system is not supported.


Note
For information about ZTP certificates, see the following:

Procedure

Step 1

From the main menu, choose Administration > Certificate Management. and check the certificate that you want to modify.

Step 2

Click on the certificate that you want to modify and select Update Certificate.

Step 3

Update the necessary options.

Note 

While updating a CW Web Server Certificate, provide relevant values for the following fields:

  • Crosswork Web CA: Trust chain file (in PEM format) containing the root CA certificate and zero or more intermediate certificates.

  • Crosswork Web Intermediate: An intermediate CA certificate signed with the root CA certificate.

  • Crosswork Web Intermediate Key: The key associated with the intermediate CA certificate.

  • Crosswork Web Passphrase: This is an optional field.

Upon successful validation, the Certificate Management UI logs out automatically and applies the certificate to the Web Gateway.
Step 4

Click Save.

Download Certificates

To export certificates, do the following:

Procedure

Step 1

From the main menu, choose Administration > Certificate Management.

Step 2

Click Details icon for the certificate you want to download.

Figure 3. Export Certificates
Export Certificates
Step 3

To separately download the root certificate, intermediate certificate, and the private key, click Export icon. To download the certificates and private key all at once, click Export All.

Renew Certificates

Certificates are valid for 1 year before they expire. The below procedure needs to be executed sequentially on each node (hybrid and worker) in the cluster. After renewing the certificates in one node, ensure that the pods are healthy before proceeding to the next node.


Note

When renewing certificates before expiry, it is recommended to perform this activity during a maintenance window as the cluster is in an operational state.

To renew a certificate, perform the following:

Procedure

Step 1

In the node, run command to move to root user.

sudo -i

You will be prompted to enter your password. Enter the cw-admin user password.

Step 2

Verify if the certificate date has expired. 

kubeadm alpha certs check-expiration

The following image is a sample of the output:

Figure 4. Certificate expiration sample output
Step 3

Make a backup of the certificates and conf files.

mkdir $HOME/Old-K8-Certs
mkdir $HOME/Old-K8-Certs/pki
cp -p /etc/kubernetes/pki/*.* $HOME/Old-K8-Certs/pki
cp -p /etc/kubernetes/*.conf $HOME/Old-K8-Certs   
~#
Step 4

Run command to renew the certificate.

kubeadm alpha certs renew all
Step 5

Repeat step 2 to verify the creation of new certificates.

Step 6

Run command to restart the kubelet. 

systemctl stop kubelet
Note 

The restart occurs on all the nodes and the refreshed certificates don’t take effect until the kubelet and kube-apiserver are restarted. It is recommended to stop any operations from the applications from running when the restart occurs.

Ensure that kube-apiserver is not running. If it is still running, kill it. It will be restarted when kubelet is restarted. 

ps -ef | grep kube-apiserver
systemctl daemon-reload&&systemctl start kubelet

The node will first move to degraded state, and then to down state.

Note 
he syslog may continue to show traffic even after the node has moved to down state. 
10-90-147-67-hybrid kernel: [1897091.695393] ll header: 00000000: ff ff ff ff ff ff fa 51 56 a2 9c 7c 08 0
10-90-147-67-hybrid kernel: [1897091.695414] IPv4: martian source 169.254.1.1 from 10.244.215.17, on dev calieff0340c649
10-90-147-67-hybrid kernel: [1897091.695416] ll header: 00000000: ff ff ff ff ff ff 72 e8 75 10 bb 64 08 06
Step 7

Verify if all the pods are healthy and running. 

kubectl get pods -A -o wide

It also verifies the running pods on the hybrid node that you have restarted.

Step 8

Verify if the certificate has been renewed.

Step 9

If the issue is still seen, change the conf file.

sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > /etc/kubernetes/kubelet.conf

Repeat the above steps for each node in your cluster.

Manage Licenses

Cisco Smart Licensing is a flexible licensing model that provides you with an easier, faster, and more consistent way to purchase and manage software across the Cisco portfolio and across your organization. And it’s secure – you control what users can access. With Smart Licensing you get:

  • Easy Activation: Smart Licensing establishes a pool of software licenses that can be used across the entire organization—no more PAKs (Product Activation Keys).

  • Unified Management: My Cisco Entitlements (MCE) provides a complete view into all of your Cisco products and services in an easy-to-use portal, so you always know what you have and what you are using.

  • License Flexibility: Your software is not node-locked to your hardware, so you can easily use and transfer licenses as needed.

To use Smart Licensing, you must first set up a Smart Account on Cisco Software Central (software.cisco.com). A Cisco Smart Account provides the repository for Smart enabled products and enables you to activate Cisco licenses, monitor license usage and track Cisco purchases. The Cisco Smart Software Manager (CSSM) enables you to manage all your Cisco Smart software licenses from one centralized website. With Cisco Smart Software Manager, you may create and manage multiple virtual accounts within your Smart Account to manage licenses. For a more detailed overview on Cisco Licensing, go to cisco.com/go/licensingguide.

From the main menu, select Administration > Smart Licensing Registration to display the Smart Software Licensing window. Using this window, you can register your Cisco Crosswork application, edit the transport settings, renew the license, and de-register your application.

Prerequisites for Smart Licensing Registration

You should have:

  • A Cisco Smart Account.

  • Purchased licenses for the Cisco Crosswork application.

Configure Transport Settings

You can configure the transport settings to decide how Cisco Crosswork communicates with the Cisco servers.

  • Direct: The application directly connects with Cisco Smart Software Manager (CSSM).

  • Transport Gateway: The application communicates via a Transport Gateway or CSSM on-prem, which replicates the cloud-based user experience but keeps all communication on premises.


    Note

    For more information on the CSSM on-prem option, see the Smart Software Manager guide.

  • HTTP/HTTPS Gateway: The application connects via an intermediate proxy server. This is applicable only for Direct mode.


Note

Transport Settings cannot be changed while the Cisco Crosswork is in Registered mode. You have to de-register to change them.

Procedure

Step 1

In the Smart Software Licensing window, the Transport Settings display the current transport mode selected. To modify, click View/Edit.

The Transport Settings dialog box is displayed.

Step 2

Select the relevant transport mode and make relevant entries in the fields provided.

Step 3

Click Save.

Register Cisco Crosswork Application

To enable licensed features, the Cisco Crosswork application must be registered to CSSM using a registration ID token. Once registered, an Identity Certificate is saved securely in the Smart Account and used for all ongoing communications. The certificate is valid for one year and will be renewed automatically after six months to ensure continuous operation.


Note

For information on generating the registration token, please refer to the support resources provided in the Smart Software Manager webpage.

Procedure

Step 1

From the main menu, select Administration > Smart Licensing Registration to display the Smart Software Licensing window. The registration status

The registration status and license authorization status will be Unregistered and Evaluation mode respectively.

Figure 5. Smart Software Licensing Unregistered Example
Step 2

In the Smart Software Licensing window, click Register.

The Smart Software Licensing Product Registration dialog box is displayed.

Step 3

In the Product Instance Registration Token field, enter the registration token generated from your Smart Account. Make sure the token ID is accurate and within validity period. For more information, see https://www.cisco.com/c/en_in/products/software/smart-accounts/software-licensing.html.

Step 4

(Optional) If you are re-registering the application, check the Re-register this product registration if it is already registered checkbox.

Note 

After a backup restore or disaster restore operation, you must manually re-register the Cisco Crosswork VM to CSSM. This is applicable in case of a Cisco Crosswork VM that has been already registered while taking the backup which is used in the restore operations.

Step 5

Click Register. It may take a few minutes to process the registration. If successful, the 'Product Registration completed successfully' message is displayed.

The registration status and license authorization status will be updated as Registered and Authorized respectively.

Note 

  • If you encounter a registration error (for example, "Communication send error" or "Invalid response from licensing cloud"), please wait for some time and retry the registration. If the error persists after multiple attempts, please contact the Cisco Customer Experience team.

  • If you encounter a communication timeout error during registration, click OK in the error dialog box and the application will reattempt the registration.

  • In some cases, after successful registration, the page may need to be refreshed manually to see the updated status.

Manually Perform Licensing Actions

The renewal of registration and authorization are automatically enabled for Cisco Crosswork, by default. However, in the event of a communication failure between the application and the Cisco server, these actions can be manually initiated. You can use the Actions drop-down button to manually renew, re-register and de-register the application.


Note

In the case of the Cisco Optimization Engine smart license, the node count is tracked during the initial onboarding of devices and during the registration and entitlement of the license. Any further changes to node count are synced with the Smart Licensing server after every 24 hours GMT. If you prefer not to wait, you can reregister the application license to update the node count immediately.

Procedure

Step 1

In the Smart License window, click Actions drop-down button and select the relevant option for the following quick actions.

  1. Actions > Renew Authorization: To renew the authorization manually if the automatic renewal service fails at the end of 30 days.

  2. Actions > Renew Registration: To renew the registration manually if the automatic renewal service fails at the end of 6 months.

  3. Actions > Re-register: Re-register the application, for example, on account of the expiry of registration tokens.

  4. Actions > De-register: De-register the application, for example, when the transport settings need to be changed.

    Note 

    Once de-registered, the application will be moved to Evaluation mode (if evaluation period is available), or Evaluation Expired mode. For more information, see License Authorization Statuses.

Step 2

The selected action is executed successfully.

License Authorization Statuses

Based on the registration status of your Cisco Crosswork application, you can see the following License Authorization Statuses.

Table 1. License Authorization Statuses

Registration Status

License Authorization Status

Description

Unregistered

Evaluation mode

A 90-day evaluation period during which the licensed features of the application can be freely used. This state is initiated when you use the application for the first time.

Evaluation Expired

The application has not been successfully registered at the end of the evaluation period. During this state, the application features are disabled, and you must register to continue using the application.

Registered Expired

The application is unable to contact the CSSM before the expiration of Identity Certificates and has returned to the unregistered state. The application resumes the remaining evaluation period, if available. At this stage, new registration ID token is required to reregister the application.

Registered

Authorized (In Compliance)

The application has been fully authorized to use the reserved licensed features. The authorization is automatically renewed every 30 days.

Out of Compliance

The associated Virtual Account does not have enough licenses to reserve for the application’s current feature use. You must renew the entitlement/usage limit registered with the token to continue using the application.

Authorization Expired

The application is unable to communicate with the CSSM for 90 days or more, and the authorization has expired.

Manage Users

As a best practice, administrators should create separate accounts for all users. Prepare a list of the people who will use Cisco Crosswork. Decide on their user names and preliminary passwords, and create user profiles for them. During the creation of a user account, you assign a user role to determine the functionality to which the user will have access. If you will be using user roles other than "admin", create the user roles before you add your users (see Create User Roles).

Procedure

Step 1

From the main menu, select Administration > Users and Roles > Users tab. From this window, you can add a new user, edit the settings for an existing user, and delete a user.

Step 2

To add a new user:

  1. Click Add icon and enter the required user details.

  2. Click Save.

Step 3

To edit a user:

  1. Click the checkbox next to the User and click Edit icon.

  2. After making changes, click Save.

Step 4

To delete a user:

  1. Click the checkbox next to the User and click Delete icon.

  2. In the Confirm Deletion window, click Delete.

Step 5

To view audit log for a user:

  1. Click the icon under the Actions column, and select Audit Log.

    The Audit Log window is displayed for the selected user name. For more information on the Audit Logs, see View Audit Log.

Administrative Users Created During Installation

During installation, Crosswork creates two special administrative IDs:

  1. The virtual machine administrator, with the username cw-admin, and the default password admin. Data center administrators use this ID to log in to and troubleshoot the VM hosting the Crosswork server.

  2. The Cisco Crosswork administrator, with the username admin and the default password admin. Product administrators use this ID to log in to and configure the user interface, and to perform special operations, such as creating new user IDs.

The default password for both administrative user IDs must be changed the first time they are used. You can also change the Cisco Crosswork administrator password using the following methods:

  • Log in as the admin user and edit the admin user password .

  • Enter the following command: admin(config)# username admin <password>

User Roles, Functional Categories and Permissions

The Roles window lets users with the appropriate privileges define custom user roles. As with the default admin role, a custom user role consists of:

  • A unique name, such as “Operator” or “admin”.

  • One or more selected, named functional categories, which control whether or not a user with that role has access to the APIs needed to perform specific Cisco Crosswork functions controlled by that API.

  • One or more selected permissions, which control the scope of what a user with that role can do in the functional category.

For a user role to have access to a functional category, that category and its underlying API must show as selected on the Roles page for that role. If the user role shows a functional category as unselected, then users with this role assigned will have no access to that functional area at all.

Some functional categories group multiple APIs under one category name. For example: The “AAA” category controls access to the Password Change, Remote Authentication Servers Integration, and Users and Role Management APIs. With this type of category, you can deny access to some of the APIs by leaving them unselected, while providing access to other APIs under the category by selecting them . For example: If you want to create an “Operator” role who is able to change his own password, but not see or change the settings for your installation’s integration with remote AAA servers, or create new users and roles, you would select the “AAA” category name, but uncheck the “Remote Authentication Server Integration API” and “Users and Role Management API” checkboxes.

For each role with a selected category, the Roles page also lets you define permissions to each underlying functional API:

  • Read permission lets the user see and interact with the objects controlled by that API, but not change or delete them.

  • Write permission lets the user see and change the objects controlled by that API, but not delete them.

  • Delete permission gives the user role delete privileges over the objects controlled by that API. It is useful to remember that delete permission does not override basic limitations set by the Crosswork platform and it applications.

Although you can mix permissions as you wish:

  • If you select an API for user access, you must provide at least “Read” permission to that API.

  • When you select an API for user access, Cisco Crosswork assumes that you want the user to have all permissions on that API, and will select all three permissions for you, automatically.

  • If you uncheck all of the permissions, including “Read”, Cisco Crosswork will assume that you want to deny access to the API, and unselect it for you.

Best Practices:

Cisco recommends that you follow these best practices when creating custom user roles:

  • Restrict Delete permissions in roles for admin users with explicit administrative responsibility for maintenance and management of the Crosswork deployment as a whole.

  • Roles for developers working with all the Cisco Crosswork APIs will need the same permissions as admin users.

  • Apply at least Read and Write permissions in roles for users who are actively engaged in managing the network using Cisco Crosswork.

  • Give read-only access to roles for users who only need to see Cisco Crosswork data to help their work as system architects or planners.

The following table describes some sample custom user roles you should consider creating:

Table 2. Sample custom user roles

Role

Description

Categories/API

Privileges

Operator

Active network manager, triggers Playbooks in response to KPI alerts

All

Read, Write

Monitor

Monitors alerts only

Health Insights, Inventory, Topology

Read only

API Integrator

All

All

All

Note

Admin role needs to include permissions for Read, Write, and Delete, while read-write roles need to include both Read and Write permissions. Using Zero Touch Provisioning features requires access to all ZTP APIs.

Create User Roles

Local users with administrator privileges can create new users as needed (see Manage Users).

Users created in this way can perform only the functions or tasks that are associated with the user role they are assigned.

The local admin role enables access to all functionality. It is created during installation and cannot be changed or deleted. However, its privileges can be assigned to new local users. Only local users can create or update user roles; TACACS users cannot.

Follow the steps below to create a new user role.

Procedure
Step 1

From the main menu, choose Administration > Users and Roles > Roles tab.

The Roles window has a Roles table on the left side and a corresponding admin table on the right side which shows the grouping of user permissions for the selected role.

Step 2

On the Roles table, click Add icon to display a new role entry in the table.

Step 3

Enter a unique name for the new role.

Step 4

Define the user role's privilege settings:

  1. Check the check box for every API that users with this role can access. The APIs are grouped logically based their corresponding application.

  2. For each API, define whether the user role has Read, Write, and Delete permission by checking the appropriate check box. You can also select an entire API group (such as AAA), and all the APIs under the group will be selected with Read,Write and Delete permissions pre-selected.

Step 5

Click Save to create the new role.

To assign the new user role to one or more user IDs, edit the Role setting for the user IDs (see Edit User Roles).

Clone User Roles

Cloning an existing user role is the same as creating a new user role, except that you need not set privileges for it. If you like, you can let the cloned user role inherit all the privileges of the original user role.

Cloning user roles is a handy way to create and assign many new user roles quickly. Following the steps below, you can clone an existing role multiple times. Defining the cloned user role's privileges is an optional step; you are only required to give the cloned role a new name. If you like, you can assign it a name that indicates the role you want a group of users to perform. You can then edit the user IDs of that group of users to assign them their new role (see Manage Users). Later, you can edit the roles themselves to give users the privileges you want (see Edit User Roles).

Procedure
Step 1

From the main menu, choose Administration > Users and Roles > Roles tab.

Step 2

Click on an existing role.

Step 3

Click User Role Clone to create a new duplicate entry in the Roles table with all the permissions of the original role.

Step 4

Enter a unique name for the cloned role.

Step 5

(Optional) Define the role's settings:

  1. Check the check box for every API that the cloned role can access.

  2. For each API, define whether the clone role has Read, Write, and Delete permission by checking the appropriate check box. You can also select an entire API group (such as AAA), and all the APIs under the group will be selected with Read,Write and Delete permissions pre-selected.

Step 6

Click Save to create the newly cloned role.

Edit User Roles

Users with administrator privileges can quickly change the privileges of any user role other than the default admin role.

Procedure
Step 1

From the main menu, choose Administration > Users and Roles > Roles tab.

Step 2

In the Roles table, click on an existing role to select it. The Admin table on the right side displays the permission settings for the selected role.

Step 3

Define the role's settings:

  1. Check the check box for every API that the role can access.

  2. For each API, define whether the role has Read, Write, and Delete permission by checking the appropriate check box. You can also select an entire API group (such as AAA), and all the APIs under the group will be selected with Read,Write and Delete permissions pre-selected.

Step 4

When you are finished, click Save.

Delete User Roles

Users with administrator privileges can delete any user role that is not the default admin user role or that is not currently assigned to a user ID. If you want to delete a role that is currently assigned to one or more user IDs, you must first edit those user IDs to assign them to a different user role.

Procedure
Step 1

From the main menu, choose Administration > Users and Roles > Roles tab.

Step 2

Click on the role you want to delete.

Step 3

Click Delete icon.

Step 4

Click Delete to confirm that you want to delete the user role.

Manage Active Sessions

As an administrator, you can monitor and manage the active sessions in the Cisco Crosswork UI, and perform the following actions:

  • Terminate a user session

  • View user audit log


Note

  • Non-admin users with permission to terminate can terminate their own sessions.

  • Non-admin users with read-only permission can only collect the audit log for their sessions.

  • Non-admin users without read permissions cannot view the Active Sessions window.

Procedure

Step 1

From the main menu, choose Administration > Users and Roles > Active Sessions.

The Active Sessions tab displays all the active sessions in the Cisco Crosswork with details such as user name, login time, and login method.

Step 2

To terminate a user session, click the icon under the Actions column, and select Terminate Session. A dialog box is displayed to confirm your action. Select Terminate to terminate the session.

Note 

You are recommended to use caution while terminating a session. A user whose session is terminated will not receive any prior warning and will lose any unsaved work.

Step 3

To view audit log for a user, click the icon under the Actions column, and select Audit Log.

The Audit Log window is displayed for the selected user name. For more information on the Audit Logs, see View Audit Log.

Set Up User Authentication (TACACS+ and LDAP)

In addition to supporting local users, Cisco Crosswork supports TACACS+ and LDAP users through integration with the TACACS+ and LDAP servers. The integration process has the following steps:

  • Configure the TACACS+ and LDAP server.

  • Create the roles that are referenced by the TACACS+ and LDAP users.

  • Configure AAA settings.


Note

  • The AAA server page works in bulk update mode wherein all the servers are updated in a single request. It is advised to give write permission for "Remote Authentication Servers Integration api" only to users who have the relevant authorization to delete the servers.

  • A user with only Read and Write permissions (without 'Delete' permission) can delete the AAA server details from Cisco Crosswork since delete operations are part of 'Write' permissions. For more information, see Create User Roles.

  • While making changes to AAA servers (create/edit/delete), you are recommended to wait for few minutes between each change. Frequent AAA changes without adequate intervals can result in external login failures.

Manage TACACS+ Servers

Crosswork supports the use of TACACS+ servers to authenticate users.


Caution

Please note that any operation you do following the instructions in this section will affect all new logins to the Crosswork user interface. To minimize session interruption, Cisco recommends that you perform all your TACACS+ changes and submit them in a single session.

Before you begin

You must create the required user role in TACACS+ server, before configuring the same in Cisco Crosswork. You can integrate Crosswork with an application such as Cisco ISE (Identity Service Engine) to authenticate using the TACACS+ protocols. To avail this service, you must configure Crosswork as a client in Cisco ISE. For more information, see the Cisco Identity Services Engine Administrator Guide.

Procedure

Step 1

From the main menu, select Administration > AAA > Servers > TACACS+ tab. From this window, you can add, edit settings, and delete a new TACACS+ server.

Step 2

To add a new TACACS+ server:

  1. Click the Add icon icon.

  2. Enter the required TACACS+ server information.

    Note 

    • You can specify a unique priority value to assign precedence in the authentication request.

    • For Crosswork to communicate with the external authentication server, the Shared Secret parameter you enter on this page must match with the shared secret value configured on the TACACS+ server.

  3. Select the authentication type.

    • PAP: Password-based authentication is the protocol where two entities share a password in advance and use the password as the basis of authentication.

    • CHAP: Challenge-Handshake Authentication Protocol requires that both the client and server know the plain text of the secret, although it is never sent over the network. CHAP provides greater security than Password Authentication Protocol (PAP).

  4. After you enter all the relevant details, click Add.

    Note 

    The Policy ID field corresponds to the user role that you created in the TACACS+ server. If you try to login to Cisco Crosswork as a TACACS+ user before creating the required user role, you will get the error message: "Key not authorized: no matching policy". If this occurs, close the browser. Login as a local admin user and create the missing user roles in the TACACS+ server, and login back to Crosswork using the TACACS+ user credentials.

  5. Click Save All Changes. You will be prompted with a warning message about restarting the server to update the changes. Click Save Changes to confirm.

Step 3

To edit a TACACS+ server:

  1. Click the checkbox next to the TACACS+ server and click Edit icon.

  2. After making changes, click Update.

Step 4

To delete a TACACS+ server:

  1. Click the checkbox next to the TACACS+ server and click Delete icon. The Delete server-IP-address dialog box opens.

  2. Click Delete to confirm.

Manage LDAP Servers

Lightweight Directory Access Protocol (LDAP) is a server protocol used to access and manage directory information. Crosswork supports the use of LDAP servers (OpenLDAP, Active Directory, and secure LDAP) to authenticate users. It manages directories over IP networks and runs directly over TCP/IP using simple string formats for data transfer.

To use secure LDAP protocol, you must add Secure LDAP Communication certificate before adding the LDAP server. For more details on adding certificates, see Add a New Certificate.


Caution

Please note that any operation you do following the instructions in this section will affect all new logins to the Crosswork user interface. To minimize session interruption, Cisco recommends that you perform all your LDAP server changes and submit them in a single session.

Procedure

Step 1

From the main menu, select Administration > AAA > Servers > LDAP tab. Using this window, you can add, edit settings, and delete a new LDAP server.

Step 2

To add a new LDAP server:

  1. Click the Add icon icon.

  2. Enter the required LDAP server details.

    Note 

    • Like TACACS+ server, you can specify a unique priority value to assign precedence in the authentication request.

    • To add a secure LDAP server, enable the Secure Connection toggle button and select the relevant secure LDAP certicate from the Certificate drop-down list.

    • The Policy ID field corresponds to the user role that you created in the LDAP server. If you try to login to Cisco Crosswork as a LDAP user before creating the required user role, you will get the error message: "Login failed, policy not found. Please contact the Network Administrator for assistance.". To avoid this error, ensure to create the relevant user roles in the LDAP server, before setting up a new LDAP server in Crosswork.

  3. Click Add.

  4. Click Save All Changes. You will be prompted with a warning message about restarting the server to update the changes. Click Save Changes to confirm.

Step 3

To edit a LDAP server:

  1. Click the checkbox next to the LDAP server and click Edit icon.

  2. After making changes, click Update.

Step 4

To delete a LDAP server:

  1. Click the checkbox next to the LDAP server and click Delete icon.

  2. Click Delete to confirm.

Configure AAA Settings

Users with relevant AAA permissions can configure the AAA settings.

Procedure

Step 1

From the main menu, choose Administration > AAA > Settings.

Step 2

Select the relevant setting for Fallback to Local. By default, Crosswork prefers external authentication servers over local database authentication.

Note 

Admin users are always authenticated locally.

Step 3

Select the relevant value for the Logout All Idle Users After field. Any user who remains idle beyond the specified limit will be automatically logged out.

Note 

The default timeout value is 30 minutes. If the timeout value is adjusted, the page will refresh to apply the change.

Step 4

Enter a relevant value for the Number of Parallel Sessions.

Note 

Crosswork supports between 5 to 200 parallel session for concurrent users. If the number of parallel sessions are exceeded, an error is displayed while logging in to Crosswork.

Step 5

Select the relevant settings for the Local Password Policy. Certain password settings are enabled by default and cannot be disabled (for example, Change password on first login).

Note 

Any changes in the password policy is enforced only the next time when the users change their password. Existing passwords are not checked for compliance during login.

Note 

Local Password Policy allows administrators to configure the number of unsuccessful login attempts a user can make before they are locked out of Cisco Crosswork, and the lockout duration. Users can attempt to login with the correct credentials once the wait time is over.

Security Hardening Overview

Security hardening entails making adjustments to ensure that the following components optimize their security mechanisms:

  • Cisco Crosswork infrastructure

  • Cisco Crosswork storage system (local or external)

Hardening Cisco Crosswork security requires completion of the following tasks:

  • Shutting down insecure and unused ports

  • Configuring network firewalls

  • Hardening the Cisco Crosswork infrastructure, as needed

Although your primary source of information is your Cisco representative, who can provide server hardening guidance specific to your deployment, you can also follow the steps in this section to secure Cisco Crosswork.

Authentication Throttling

Cisco Crosswork throttles the login attempts after a failed login attempt to avoid password guessing and other related abuse scenarios. After a failed login attempt for a username, all authentication attempts for that username would be blocked for 3 seconds. The throttling is applicable to all supported authentication schemes such as TACACS, LDAP and the default local authentication.

Core Security Concepts

If you are an administrator and are looking to optimize the security of your Cisco Crosswork product, you should have a good understanding of the following security concepts.

HTTPS

Hypertext Transfer Protocol Secure (HTTPS) uses Secure Sockets Layer (SSL) or its subsequent standardization, Transport Layer Security (TLS), to encrypt the data transmitted over a channel. Several vulnerabilities have been found in SSL, so Cisco Crosswork now supports TLS only.


Note
TLS is loosely referred to as SSL often, so we will also follow this convention.

SSL employs a mix of privacy, authentication, and data integrity to secure the transmission of data between a client and a server. To enable these security mechanisms, SSL relies upon certificates, private-public key exchange pairs, and Diffie-Hellman key agreement parameters.

X.509 Certificates

X.509 certificates and private-public key pairs are a form of digital identification for user authentication and the verification of a communication partner’s identity. Certificate Authorities (CAs), such as VeriSign and Thawte, issue certificates to identify an entity (either a server or a client). A client or server certificate includes the name of the issuing authority and digital signature, the serial number, the name of the client or server that the certificate was issued for, the public key, and the certificate's expiration date. A CA uses one or more signing certificates to create SSL certificates. Each signing certificate has a matching private key that is used to create the CA signature. The CA makes signed certificates (with the public key embedded) readily available, enabling anyone to use them to verify that an SSL certificate was actually signed by a specific CA.

In general, setting up certificates in both High Availability (HA) and non-HA environments involves the following steps:

  1. Generating an identity certificate for a server.

  2. Installing the identity certificate on the server.

  3. Installing the corresponding root certificate on your client or browser.

The specific tasks you need to complete will vary depending on your environment.

Note the following:

  • The start-stop sequencing of servers needs to be done carefully in HA environments.

  • Non-HA environments, where a virtual IP address is configured, require the completion of a more complicated certificate request process.

1-Way SSL Authentication

This authentication method is used when a client needs assurance that it is connecting to the right server (and not an intermediary server), making it suitable for public resources like online banking websites. Authentication begins when a client requests access to a resource on a server. The server on which the resource resides then sends its server certificate (also known as an SSL or x.509 certificate) to the client in order to verify its identity. The client then verifies the server certificate against another trusted object: a server root certificate, which must be installed on the client or browser. After the server has been verified, an encrypted (and therefore secure) communication channel is established. At this point, the Cisco Crosswork server prompts for the entry of a valid username and password in an HTML form. Entering user credentials after an SSL connection is established protects them from being intercepted by an unauthorized party. Finally, after the username and password have been accepted, access is granted to the resource residing on the server.


Note
A client might need to store multiple server certificates to enable interaction with multiple servers.

To determine whether you need to install a root certificate on your client, look for a lock icon in your browser’s URL field. If you see this icon, this generally indicates that the necessary root certificate has already been installed. This is usually the case for server certificates signed by one of the bigger Certifying Authorities (CAs), because root certificates from these CAs are included with popular browsers.

If your client does not recognize the CA that signed a server certificate, it will indicate that the connection is not secure. This is not necessarily a bad thing. It just indicates that the identity of the server you want to connect has not been verified. At this point, you can do one of two things: First, youYou can install the necessary root certificate on your client or browser. A lock icon in your browser’s URL field will indicate the certificate was installed successfully. And second, you can install a self-signed certificate on your client. Unlike a root certificate, which is signed by a trusted CA, a self-signed certificate is signed by the person or entity that created it. While you can use a self-signed certificate to create an encrypted channel, understand that it carries an inherent amount of risk because the identity of the server you are connected with has not been verified.

Disable Insecure Ports and Services

As a general policy, any ports that are not needed should be disabled. You need to first know which ports are enabled, and then decide which of these ports can be safely disabled without disrupting the normal functioning of Cisco Crosswork. You can do this by listing the ports that are open and comparing it with a list of ports needed for Cisco Crosswork.

To view a list of all open listening ports:

Procedure

Step 1

Log in as a Linux CLI admin user and enter the netstat -aln command.

The netstat -aln command displays the server's currently open (enabled) TCP/UDP ports, the status of other services the system is using, and other security-related configuration information. The command returns output similar to the following:

[root@vm ~]# netstat -aln
Active Internet connections (servers and established)
Proto  Recv-Q   Send-Q   Local Address            Foreign Address         State
tcp    0        0        0.0.0.0:111              0.0.0.0:*               LISTEN
tcp    0        0        127.0.0.1:8080           0.0.0.0:*               LISTEN
tcp    0        0        0.0.0.0:22               0.0.0.0:*               LISTEN
tcp    0        0        127.0.0.1:25             0.0.0.0:*               LISTEN
tcp    0        0        127.0.0.1:10248          0.0.0.0:*               LISTEN
tcp    0        0        127.0.0.1:10249          0.0.0.0:*               LISTEN
tcp    0        0        192.168.125.114:40764    192.168.125.114:2379    ESTABLISHED
tcp    0        0        192.168.125.114:48714    192.168.125.114:10250   CLOSE_WAIT
tcp    0        0        192.168.125.114:40798    192.168.125.114:2379    ESTABLISHED
tcp    0        0        127.0.0.1:33392          127.0.0.1:8080          TIME_WAIT
tcp    0        0        192.168.125.114:40814    192.168.125.114:2379    ESTABLISHED
tcp    0        0        192.168.125.114:40780    192.168.125.114:2379    ESTABLISHED
tcp    0        0        127.0.0.1:8080           127.0.0.1:44276         ESTABLISHED
tcp    0        0        192.168.125.114:40836    192.168.125.114:2379    ESTABLISHED
tcp    0        0        192.168.125.114:40768    192.168.125.114:2379    ESTABLISHED
tcp    0        0        127.0.0.1:59434          127.0.0.1:8080          ESTABLISHED
tcp    0        0        192.168.125.114:40818    192.168.125.114:2379    ESTABLISHED
tcp    0        0        192.168.125.114:22       192.168.125.1:45837     ESTABLISHED
tcp    0        0        127.0.0.1:8080           127.0.0.1:48174         ESTABLISHED
tcp    0        0        127.0.0.1:49150          127.0.0.1:8080          ESTABLISHED
tcp    0        0        192.168.125.114:40816    192.168.125.114:2379    ESTABLISHED
tcp    0        0        192.168.125.114:55444    192.168.125.114:2379    ESTABLISHED
Step 2

Check the for the table of ports used by Cisco Crosswork, and see if your ports are listed in that table. That table will help you understand which services are using the ports, and which services you do not need—and thus can be safely disabled. In this case, safe means you can safely disable the port without any adverse effects to the product.

Note 
If you are not sure whether you should disable a port or service, contact your Cisco representative.  
Step 3

If you have firewalls in your network, configure the firewalls to only allow traffic that is needed for Cisco Crosswork to operate.

Harden Your Storage

We recommend that you secure all storage elements that will participate in your Cisco Crosswork installation, such as the database, backup servers, and so on.

  • If you are using external storage, contact your storage vendor and your Cisco representative.

  • If you are using internal storage, contact your Cisco representative.

  • If you ever uninstall or remove Cisco Crosswork, make sure that all VM-related files that might contain sensitive data are digitally shredded (as opposed to simply deleted). Contact your Cisco representative for more information.

Configure System Settings

Administrator users can configure the following system settings:

Configure a Syslog Server

Crosswork allows external syslog consumers to:

  • Register on Crosswork and receive system events as syslogs.

  • Define and filter which kind of events should be forwarded as a syslog, per consumer.

  • Define the rate of which syslogs are forwarded to the consumer.


Note

After the Syslog TLS server certificate is added, wait for 5-10 minutes before configuring the syslog server.

Before you begin

Ensure that you have uploaded the Syslog TLS server certificate. For more information, see Add a New Certificate.

Procedure

Step 1

From the main menu, choose Administration > Settings > System Settings tab.

Step 2

Under Server, click the Syslog Configuration option.

Step 3

Click Add icon.

Step 4

Enter Syslog configuration details. For more information, click Field Help icon next to each option.

Use the Criteria option to define scope and range of which kind of events should be forwarded as a syslog. For example: (EventSeverity<2 or EventSeverity>=5) and OriginAppId=capp-infra and EventCategory=1

The expression will send events as a syslog only if the event originates from the Infrastructure Platform, the category is the system, and the severity is either less than 2 or is equal or above 5.

Caution 

Expressions are freeform and not validated.
Step 5

Click Save.

Configure a Trap Server

Follow the procedure below to manage Trap Servers from the Settings window:

Procedure

Step 1

From the main menu, choose Administration > Settings > System Settings tab.

Step 2

Under Server, click the Trap servers option.

Step 3

Click Add icon.

Step 4

Enter Trap server details. For more information, click Field Help icon next to each option.

Use the Criteria option to define scope and range of which kind of events should be forwarded as a trap.

Click Events and Alarms examples for more information on the attributes used to raise an event.

Step 5

After entering all the relevant information, click Add.

Enable Layered Service Architecture (LSA)

This procedure is applicable only when you have opted for Cisco NSO LSA deployment to add arbitrarily many device nodes for improved memory and provisioning throughput.

Procedure

Step 1

From the main menu, select Administration > Settings > System Settings > Layered Service Architecture.

Enabling Layered Service Architecture
Step 2

Select Enable.

Step 3

Select the method to spread the devices across multiple NSO instances:

  • Round Robin - Even distribution of devices to RFS nodes in a cyclical manner (for example, Device 1 to RFS1, Device 2 to RFS2, and so on).

  • Capacity - The number of devices are assigned to each RFS instance based on its total capacity.

  • User Defined - Devices are assigned to the NSO providers specified for the device in the device settings. For more information, see Add Devices Through the UI.

Step 4

Click Save.

Note 
Once you have saved the settings, you cannot disable it without removing all the NSO providers.

Set the Pre-Login Disclaimer

Many organizations require that their systems display a disclaimer message in a banner before users log in. The banner may remind authorized users of their obligations when using the system, or provide warnings to unauthorized users. You can enable such a banner for Crosswork users, and customize the disclaimer message as needed.

Procedure

Step 1

From the main menu, choose Administration > Settings > System Settings tab.

Step 2

Under Notifications, click the Pre-Login Disclaimer option.

Step 3

To enable the disclaimer and customize the banner:

  1. Check the Enabled checkbox.

  2. Customize the banner Title, the Icon, and the Disclaimer Text as needed.

  3. Optional: While editing the disclaimer, you can

    Click Preview to see how your changes will look when displayed before the Crosswork login prompt.

    Click Discard Changes to revert to the last saved version of the banner.

    Click Reset to revert to the original, default version of the banner.

  4. When you are satisfied with your changes, click Save to save them and enable display of the custom disclaimer to all users.

Step 4

To turn off the disclaimer display: Select Administration > Settings > System Settings > Pre-Login Disclaimer, then uncheck the Enabled checkbox.

Manage File Server Settings

Cisco Crosswork provides secure file transfer services (FTP and SFTP) for Crosswork applications that need them. They are disabled by default.


Note

This feature is currently only supported for the EPNM application. For more information about the enabling scenarios, please refer to the EPNM user documentation.

Procedure

Step 1

To enable FTP server:

  1. From the main menu, choose Administration > Settings > System Settings > File Servers

  2. Under FTP, select on the Enable radio button.

  3. Click Save to save your settings.

Step 2

To enable SFTP server:

  1. From the main menu, choose Administration > Settings > System Settings > File Servers

  2. Drag the Enable Server Upload slider to On position.

    Caution 

    SFTP supports upload option that allows write access to the Cisco Crosswork storage from the outside. You are recommended to use caution while enabling the upload, and it should be disabled as soon as it is no longer needed.

  3. Click Save to save your settings.