The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter includes the following sections:
From Cisco UCS Central you can configure LDAP, RADIUS, and TACACS+ for a registered UCS domain authentication.
Note | Only LDAP can be used for remote authentication. |
If a system is configured for one of the supported remote authentication services, you must create a provider for that service to ensure that Cisco UCS Central can communicate with it. In addition, you need to be aware of the following guidelines that impact user authorization:
User accounts can exist locally in Cisco UCS Central or in the remote authentication server. The temporary sessions for users who log in through remote authentication services can be viewed through Cisco UCS Central GUI or Cisco UCS Central CLI.
If you create user accounts in the remote authentication server, you must ensure that the accounts include the roles those users require for working in Cisco UCS Central and that the names of those roles match the names used in Cisco UCS Central. Depending on the role policy, a user may not be allowed to log in or granted only read-only privileges.
Cisco UCS Central uses LDAP for remote authentication, but excludes RADIUS and TACACS+ authentication in this release. However, RADIUS, TACACS+ and LDAP authentication are supported in locally managed Cisco UCS domains.
When a user logs in, Cisco UCS Central does the following:
Queries the remote authentication service.
Validates the user.
If the user is validated, checks for the roles and locales assigned to that user.
The following is a sample OID for a custom CiscoAVPair attribute:
CN=CiscoAVPair,CN=Schema, CN=Configuration,CN=X objectClass: top objectClass: attributeSchema cn: CiscoAVPair distinguishedName: CN=CiscoAVPair,CN=Schema,CN=Configuration,CN=X instanceType: 0x4 uSNCreated: 26318654 attributeID: 1.3.6.1.4.1.9.287247.1 attributeSyntax: 2.5.5.12 isSingleValued: TRUE showInAdvancedViewOnly: TRUE adminDisplayName: CiscoAVPair adminDescription: UCS User Authorization Field oMSyntax: 64 lDAPDisplayName: CiscoAVPair name: CiscoAVPair objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,CN=X
You can configure remote users, assign roles and locales from Cisco UCS Central the same way as you can create LDAP users from Cisco UCS Manager. You should always create the LDAP provider from Cisco UCS Central Domain Group root.
You can define up to 28 LDAP provider group maps and nest them up to as many levels as the Active Directory supports for nesting in Cisco UCS Central. When you assign a provider to a nested group, even if the provider is a member of a different LDAP group, they become authenticated member of the parent nested group. During authentication, all the providers within a provider group are tried in order. If all the configured LDAP servers are unavailable or unreachable, Cisco UCS Central automatically falls back to the local authentication method using the local username and password.
For organizations that already use LDAP groups to restrict access to LDAP databases, group membership information can be used by Cisco UCS domains to assign a role or locale to an LDAP user during login. This eliminates the need to define role or a locale information in the LDAP user object when Cisco UCS Central is deployed.
Cisco UCS Central uses LDAP group rule to determine LDAP groups when assigning user roles and locales to a remote user. When a user logs in, Cisco UCS Central retrieves information about the user's role and locale from the LDAP group map. If the role and locale criteria match the information in the policy, Cisco UCS Central provides access to the user.
Role and locale definitions are configured locally in Cisco UCS Central and do not update automatically based on changes to an LDAP directory. If you delete or rename LDAP groups in the LDAP directory, make sure to update the changes in Cisco UCS Central.
You can configure an LDAP group map to include any of the following combinations of roles and locales:
Example: If you want to configure authentication for an LDAP group representing a group of server administrators at a specific location, you can include user roles such as server-profile and server-equipment to the LDAP group. If you want to restrict access to server administrators at a specific location, you can specify locales with specific site names.
Note | Cisco UCS Central includes many out-of-the-box user roles but does not include any locales. So you have to create a custom locale to map an LDAP provider group to a locale. |
You can search LDAP groups that are nested within another group defined in an LDAP group map. With this capability, you need not create subgroups in a group map in Cisco UCS Central.
Note | Nested LDAP search support is supported only for Microsoft Active Directory servers. The supported versions are Microsoft Windows 2003 SP3, Microsoft Windows 2008 R2, and Microsoft Windows 2012. |
Note | When you create nested LDAP group in MS-AD, if you use special characters in the name, make sure to configure the characters with \\( , \\). Following is an example of creating a nested LDAP group using the Cisco UCS Central CLI: create ldap-group CN=test1\\(\\),CN=Users,DC=ucsm,DC=qasam-lab,DC=in |
Using the LDAP nesting feature, you can add an LDAP group as a member of another group and nest groups to consolidate member accounts and reduce the replication of traffic.
By default, user rights are inherited when an LDAP group is nested within another group. For example, if you make Group_1 a member of Group_2, the users in Group_1 will have the same permissions as the members of Group_2. You can then search users that are members of Group_1 by choosing only Group_2 in the LDAP group map, instead of having to search Group_1 and Group_2 separately.
Cisco UCS Central uses LDAP for native authentication, but excludes RADIUS and TACACS+ authentication. However, RADIUS, TACACS+ and LDAP remote authentication are supported for Cisco UCS domains, from the Cisco UCS Central Domain Group root.
After creating an authentication domain, you can edit the authentication information as required.
Cisco UCS Central supports global SNMP policies enabling or disabling, defining SNMP traps and SNMP users (with regular and privacy passwords, authentication types of md5 or sha, and encryption types DES and AES-128). Registered Cisco UCS domains choosing to define SNMP policies globally within that client's policy resolution control will defer all SNMP policies to its registration with Cisco UCS Central.
The SNMP Agent functionality provides the ability to remotely monitor the Cisco UCS Central. You can also change the Cisco UCS Central host IP, and then restart the SNMP agent on the new IP. SNMP is run on both the active and standby Cisco UCS Central servers and the configuration is persisted on both. Cisco UCS Central offers read-only access to only the operating system managed information base (MIB).Through the Cisco UCS Central CLI you can configure the community strings for SNMP v1, v2c, and create and delete the SNMPv3 users.
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 Central, the managed device, that maintains the data for Cisco UCS Central and reports the data, as needed, to the SNMP manager. Cisco UCS Central 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 Central.
A managed information base (MIB)—The collection of managed objects on the SNMP agent. Cisco UCS Central supports only the OS MIBs.
RFC 3410 (http://tools.ietf.org/html/rfc3410)
RFC 3411 (http://tools.ietf.org/html/rfc3411)
RFC 3412 (http://tools.ietf.org/html/rfc3412)
RFC 3413 (http://tools.ietf.org/html/rfc3413)
RFC 3414 (http://tools.ietf.org/html/rfc3414)
RFC 3415 (http://tools.ietf.org/html/rfc3415)
RFC 3416 (http://tools.ietf.org/html/rfc3416)
RFC 3417 (http://tools.ietf.org/html/rfc3417)
RFC 3418 (http://tools.ietf.org/html/rfc3418)
RFC 3584 (http://tools.ietf.org/html/rfc3584)
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 Central generates SNMP notifications as traps. Traps are less reliable because the SNMP manager does not send any acknowledgment when it receives a trap, and Cisco UCS Central cannot determine if the trap was received.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.
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.
Model |
Level |
Authentication |
Encryption |
What Happens |
---|---|---|---|---|
v1 |
noAuthNoPriv |
Community string |
No |
Uses a community string match for authentication. |
v2c |
noAuthNoPriv |
Community string |
No |
Uses a community string match for authentication. |
v3 |
noAuthNoPriv |
Username |
No |
Uses a username match for authentication. |
v3 |
authNoPriv |
HMAC-MD5 or HMAC-SHA |
No |
Provides authentication based on the Hash-Based Message Authentication Code (HMAC) Message Digest 5 (MD5) algorithm or the HMAC Secure Hash Algorithm (SHA). |
v3 |
authPriv |
HMAC-MD5 or HMAC-SHA |
DES |
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. |
Support for MIBs
Cisco UCS Central supports read-only access to OS MIBs. No set operations are available for the MIBs. The following MIBs are supported by Cisco UCS Central:
IP-MIB
IF-MIB
DISMAN-EVENT-MIB
SNMP MIB-2 snmp
Note | Cisco UCS Central does not provide support for IPV6 andCisco UCS Central MIBs. |
Create SNMP traps and users.
After creating an SNMP trap, you can edit the SNMP trap information as required.
Create an SNMP user.
After creating an SNMP user, you can edit the SNMP user information as required.