Communication Services

You can use the following communication services to interface third-party applications with Cisco UCS:

Communication Service

Description

CIM XML

This service is disabled by default and is only available in read-only mode. The default port is 5988.

This common information model is one of the standards defined by the Distributed Management Task Force.

HTTP

This service is enabled on port 80 by default.

You must enable either HTTP or HTTPS to run Cisco UCS Manager GUI. If you select HTTP, all data is exchanged in clear text mode.

For security purposes, we recommend that you enable HTTPS and disable HTTP.

By default, Cisco UCS redirects any attempt to communicate via HTTP to the HTTPS equivalent. We recommend that you do not change this behavior.

Note

If you are upgrading to Cisco UCS, version 1.4(1), this does not happen by default. If you want to redirect any attempt to communicate via HTTP to an HTTPS equivalent, you should enable Redirect HTTP to HTTPS in Cisco UCS Manager.

HTTPS

This service is enabled on port 443 by default.

With HTTPS, all data is exchanged in encrypted mode through a secure server.

For security purposes, we recommend that you only use HTTPS and either disable or redirect HTTP communications.

SMASH CLP

This service is enabled for read-only access and supports a limited subset of the protocols, such as the show command. You cannot disable it.

This shell service is one of the standards defined by the Distributed Management Task Force.

SNMP

This service is disabled by default. If enabled, the default port is 161. You must configure the community and at least one SNMP trap.

Enable this service only if your system includes integration with an SNMP server.

SSH

This service is enabled on port 22. You cannot disable it, nor can you change the default port.

(Optional)In the Redirect HTTP to HTTPS field, click the enabled radio button.

You must also configure and enable HTTPS to enable redirection of HTTP logins to the HTTPS login. Once enabled, you cannot disable the redirection until you have disabled HTTPS.

Note

If you redirect HTTP to HTTPS, you cannot use HTTP to access Cisco UCS Manager GUI. Redirection disables HTTP as it automatically redirects to HTTPS.

Step 7

Click Save Changes.

Configuring HTTPS

Certificates, Key Rings, and Trusted Points

HTTPS uses components of the Public Key Infrastructure (PKI) to establish secure communications between two devices, such as a client's browser and Cisco UCS Manager.

Encryption Keys and Key Rings

Each PKI device holds a pair of asymmetric Rivest-Shamir-Adleman (RSA) encryption keys, one kept private and one made public, stored in an internal key ring. A message encrypted with either key can be decrypted with the other key. To send an encrypted message, the sender encrypts the message with the receiver's public key, and the receiver decrypts the message using its own private key. A sender can also prove its ownership of a public key by encrypting (also called 'signing') a known message with its own private key. If a receiver can successfully decrypt the message using the public key in question, the sender's possession of the corresponding private key is proven. Encryption keys can vary in length, with typical lengths from 512 bits to 2048 bits. In general, a longer key is more secure than a shorter key. Cisco UCS Manager provides a default key ring with an initial 1024-bit key pair, and allows you to create additional key rings.

The default key ring certificate must be manually regenerated if the cluster name changes or the certificate expires.

This operation is only available in the UCS Manager CLI.

Certificates

To prepare for secure communications, two devices first exchange their digital certificates. A certificate is a file containing a device's public key along with signed information about the device's identity. To merely support encrypted communications, a device can generate its own key pair and its own self-signed certificate. When a remote user connects to a device that presents a self-signed certificate, the user has no easy method to verify the identity of the device, and the user's browser will initially display an authentication warning. By default, Cisco UCS Manager contains a built-in self-signed certificate containing the public key from the default key ring.

Trusted Points

To provide stronger authentication for Cisco UCS Manager, you can obtain and install a third-party certificate from a trusted source, or trusted point, that affirms the identity of your device. The third-party certificate is signed by the issuing trusted point, which can be a root certificate authority (CA) or an intermediate CA or trust anchor that is part of a trust chain that leads to a root CA. To obtain a new certificate, you must generate a certificate request through Cisco UCS Manager and submit the request to a trusted point.

Copy the text of the certificate request out of the Request field and save in a file.

Step 9

Send the file with the certificate request to the trust anchor or certificate authority.

What to Do Next

Create a trusted point and set the certificate chain for the certificate of trust received from the trust anchor.

Creating a Trusted Point

Procedure

Step 1

In the Navigation pane, click the Admin tab.

Step 2

On the Admin tab, expand All > Key Management.

Step 3

Right-click Key Management and choose Create Trusted Point.

Step 4

In the Create Trusted Point dialog box, complete the following fields:

Name

Description

Name field

The name of the trusted point.

This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and . (period), and you cannot change this name after the object has been saved.

Certificate Chain field

The certificate information for this trusted point.

Important:

The certificate must be in Base64 encoded X.509 (CER) format.

Step 5

Click OK.

What to Do Next

When you receive the certificate from the trust anchor or certificate authority, import it into the key ring.

Importing a Certificate into a Key Ring

Procedure

Step 1

In the Navigation pane, click the Admin tab.

Step 2

On the Admin tab, expand All > Key Management.

Step 3

Click the key ring into which you want to import the certificate.

Step 4

In the Work pane, click the General tab.

Step 5

In the Certificate area, complete the following fields:

From the Trusted Point drop-down list, select the trusted point for the trust anchor that granted this certificate.

In the Certificate field, paste the text from the certificate you received from the trust anchor or certificate authority. Important:

The certificate must be in Base64 encoded X.509 (CER) format.

Tip

If the fields in an area are not displayed, click the Expand icon to the right of the heading.

Step 6

Click Save Changes.

What to Do Next

Configure your HTTPS service with the key ring.

Configuring HTTPS

Caution

After you complete the HTTPS configuration, including changing the port and key ring to be used by HTTPS, all current HTTP and HTTPS sessions are closed without warning as soon as you save or commit the transaction.

The HTTPS area expands to display the available configuration options.

Step 5

Complete the following fields:

Name

Description

Admin State field

This can be one of the following:

Enabled

Disabled

If Admin State is enabled, Cisco UCS Manager GUI displays the rest of the fields in this section.

Port field

The port to use for HTTPS connections.

Specify an integer between 1 and 65535. This service is enabled on port 443 by default.

Key Ring drop-down list

The key ring for HTTPS connections.

Cipher Suite Mode field

The level of Cipher Suite security used by the Cisco UCS domain. This can be one of the following:

High Strength

Medium Strength

Low Strength

Custom—Allows you to specify a user-defined Cipher Suite specification string.

Cipher Suite field

If you select Custom in the Cipher Suite Mode field, specify the user-defined Cipher Suite specification string in this field.

The Cipher Suite specification string can contain up to 256 characters and must conform to the OpenSSL Cipher Suite specifications. You cannot use any spaces or special characters except ! (exclamation point), + (plus sign), - (hyphen), and : (colon). For details, see http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite.

Configuring SNMP

Information about SNMP

The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.

SNMP Functional Overview

The SNMP framework consists of three parts:

An SNMP manager—The system used to control and monitor the activities of network devices using SNMP.

An SNMP agent—The software component within Cisco UCS, the managed device, that maintains the data for Cisco UCS and reports the data, as needed, to the SNMP manager. Cisco UCS includes the agent and a collection of MIBs. To enable the SNMP agent and create the relationship between the manager and agent, enable and configure SNMP in Cisco UCS Manager.

A managed information base (MIB)—The collection of managed objects on the SNMP agent. Cisco UCS release 1.4(1) and higher support a larger number of MIBs than earlier releases.

Cisco UCS supports SNMPv1, SNMPv2c and SNMPv3. Both SNMPv1 and SNMPv2c use a community-based form of security. SNMP is defined in the following:

SNMP Notifications

A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events.

Cisco UCS Manager generates SNMP notifications as either traps or informs. Traps are less reliable than informs because the SNMP manager does not send any acknowledgment when it receives a trap, and Cisco UCS Manager cannot determine if the trap was received. An SNMP manager that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the Cisco UCS Manager does not receive the PDU, it can send the inform request again.

SNMP Security Levels and Privileges

SNMPv1, SNMPv2c, and SNMPv3 each represent a different security model. The security model combines with the selected security level to determine the security mechanism applied when the SNMP message is processed.

The security level determines the privileges required to view the message associated with an SNMP trap. The privilege level determines whether the message needs to be protected from disclosure or authenticated. The supported security level depends upon which security model is implemented. SNMP security levels support one or more of the following privileges:

noAuthNoPriv—No authentication or encryption

authNoPriv—Authentication but no encryption

authPriv—Authentication and encryption

SNMPv3 provides for both security models and security levels. A security model is an authentication strategy that is set up for a user and the role in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level determines which security mechanism is employed when handling an SNMP packet.

Supported Combinations of SNMP Security Models and Levels

The following table identifies what the combinations of security models and levels mean.

Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Provides Data Encryption Standard (DES) 56-bit encryption in addition to authentication based on the Cipher Block Chaining (CBC) DES (DES-56) standard.

SNMPv3 Security Features

SNMPv3 provides secure access to devices by a combination of authenticating and encrypting frames over the network. SNMPv3 authorizes management operations only by configured users and encrypts SNMP messages. The SNMPv3 User-Based Security Model (USM) refers to SNMP message-level security and offers the following services:

Message integrity—Ensures that messages have not been altered or destroyed in an unauthorized manner and that data sequences have not been altered to an extent greater than can occur non-maliciously.

Message origin authentication—Ensures that the claimed identity of the user on whose behalf received data was originated is confirmed.

Message confidentiality and encryption—Ensures that information is not made available or disclosed to unauthorized individuals, entities, or processes.

Authentication Protocols for SNMPv3 Users

Cisco UCS supports the following authentication protocols for SNMPv3 users:

HMAC-MD5-96 (MD5)

HMAC-SHA-96 (SHA)

AES Privacy Protocol for SNMPv3 Users

Cisco UCS uses Advanced Encryption Standard (AES) as one of the privacy protocols for SNMPv3 message encryption and conforms with RFC 3826.

The privacy password, or priv option, offers a choice of DES or 128-bit AES encryption for SNMP security encryption. If you enable AES-128 configuration and include a privacy password for an SNMPv3 user, Cisco UCS Manager uses the privacy password to generate a 128-bit AES key. The AES privacy password can have a minimum of eight characters. If the passphrases are specified in clear text, you can specify a maximum of 64 characters.

Enabling SNMP and Configuring SNMP Properties

SNMP messages from a Cisco UCS domain display the fabric interconnect name rather than the system name.

The IP address of the SNMP host to which Cisco UCS Manager should send the trap.

Community/Username field

The SNMP v1 or v2c community name or the SNMP v3 username Cisco UCS Manager includes when it sends the trap to the SNMP host. This must be the same as the community or username that is configured for the SNMP service.