- Preface
- New and Changed Information
- Overview of Cisco Unified Computing System
- Overview of Cisco UCS Manager
- Overview of Cisco UCS Manager GUI
- Configuring the Fabric Interconnects
- Configuring Ports and Port Channels
- Configuring Communication Services
- Configuring Authentication
- Configuring Organizations
- Configuring Role-Based Access Control
- Configuring DNS Servers
- Configuring System-Related Policies
- Managing Licenses
- Managing Virtual Interfaces
- Registering Cisco UCS Domains with Cisco UCS Central
- LAN Uplinks Manager
- VLANs
- Configuring LAN Pin Groups
- Configuring MAC Pools
- Configuring Quality of Service
- Configuring Network-Related Policies
- Configuring Upstream Disjoint Layer-2 Networks
- Configuring Named VSANs
- Configuring SAN Pin Groups
- Configuring WWN Pools
- Configuring Storage-Related Policies
- Configuring Fibre Channel Zoning
- Configuring Server-Related Pools
- Setting the Management IP Address
- Configuring Server-Related Policies
- Configuring Server Boot
- Deferring Deployment of Service Profile Updates
- Service Profiles
- Configuring Storage Profiles
- Managing Power in Cisco UCS
- Managing Time Zones
- Managing the Chassis
- Managing Blade Servers
- Managing Rack-Mount Servers
- Starting the KVM Console
- CIMC Session Management
- Managing the I/O Modules
- Backing Up and Restoring the Configuration
- Recovering a Lost Password
Cisco UCS Manager GUI Configuration Guide, Release 2.2
Bias-Free Language
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.
- Updated:
- April 16, 2018
Chapter: Configuring Authentication
- Authentication Services
- Guidelines and Recommendations for Remote Authentication Providers
- User Attributes in Remote Authentication Providers
- Two-Factor Authentication
- LDAP Group Rule
- Nested LDAP Groups
- Configuring LDAP Providers
- Configuring RADIUS Providers
- Configuring TACACS+ Providers
- Multiple Authentication Services Configuration
- Multiple Authentication Services
- Provider Groups
- Creating an LDAP Provider Group
- Deleting an LDAP Provider Group
- Creating a RADIUS Provider Group
- Deleting a RADIUS Provider Group
- Creating a TACACS+ Provider Group
- Deleting a TACACS+ Provider Group
- Authentication Domains
- Creating an Authentication Domain
- Selecting a Primary Authentication Service
Configuring Authentication
This chapter includes the following sections:
- Authentication Services
- Guidelines and Recommendations for Remote Authentication Providers
- User Attributes in Remote Authentication Providers
- Two-Factor Authentication
- LDAP Group Rule
- Nested LDAP Groups
- Configuring LDAP Providers
- Configuring RADIUS Providers
- Configuring TACACS+ Providers
- Multiple Authentication Services Configuration
- Selecting a Primary Authentication Service
Authentication Services
Cisco UCS supports the following two methods to authenticate user logins:
Guidelines and Recommendations for Remote Authentication Providers
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 Manager can communicate with the system. The following guidelines impact user authorization:
User Accounts in Remote Authentication Services
User accounts can exist locally in Cisco UCS Manager or in the remote authentication server.
You can view the temporary sessions for users who log in through remote authentication services from the Cisco UCS Manager GUI and from the Cisco UCS Manager CLI.
User Roles in Remote Authentication Services
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 Manager and that the names of those roles match the names used in Cisco UCS Manager. Based on the role policy, a user might not be allowed to log in, or is granted only read-only privileges.
User Attributes in Remote Authentication Providers
For RADIUS and TACACS+ configurations, you must configure a user attribute for Cisco UCS in each remote authentication provider through which users log in to Cisco UCS Manager. This user attribute holds the roles and locales assigned to each user.
 Note | This step is not required for LDAP configurations that use the LDAP Group Mapping to assign roles and locales. |
When a user logs in, Cisco UCS Manager 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.
Sample OID for LDAP User Attribute
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
Two-Factor Authentication
Cisco UCS Manager uses two-factor authentication for remote user logins, which adds a level of security to account logins. Two-factor authentication login requires a username, a token, and a password combination in the password field. You can provide a PIN, a certificate, or a token.
Two-factor authentication uses authentication applications that maintain token servers to generate one-time tokens for users during the login process and store passwords in the AAA server. Requests are sent to the token server to retrieve a vendor-specific attribute. Cisco UCS Manager expects the token server to integrate with the AAA server, therefore it forwards the request to the AAA server. The password and token are validated at the same time by the AAA server. Users must enter the token and password sequence in the same order as it is configured in the AAA server.
Two-factor authentication is supported by associating RADIUS or TACACS+ provider groups with designated authentication domains and enabling two-factor authentication for those domains. Two-factor authentication does not support IPM and is not supported when the authentication realm is set to LDAP, local, or none.
Web Session Refresh and Web Session Timeout Period
The Web Session Refresh Period is the maximum amount of time allowed between refresh requests for a Cisco UCS Manager GUI web session. The Web Session Timeout is the maximum amount of time that can elapse after the last refresh request before a Cisco UCS Manager GUI web session becomes inactive.
You can increase the Web Session Refresh Period to a value greater than 60 seconds up 172800 seconds to avoid frequent session timeouts that requires regenerating and re-entering a token and password multiple times. The default value is 7200 seconds when two-factor authentication is enabled, and is 600 seconds when two-factor authentication is not enabled.
You can specify a value between 300 and 172800 for the Web Session Timeout Period. The default is 8000 seconds when two-factor authentication is enabled, and 7200 seconds when two-factor authentication is not enabled.
LDAP Group Rule
The LDAP group rule determines whether Cisco UCS should use LDAP groups when assigning user roles and locales to a remote user.
Nested LDAP Groups
You can add an LDAP group as a member of another group and nest groups to consolidate member accounts and to reduce the replication of traffic. Cisco UCS Manager release 2.1(2) and higher enables you to search LDAP groups that are nested within another group defined in an LDAP group map.
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. |
By default, user rights are inherited when you nest an LDAP group within another group. For example, if you make Group_1 a member of Group_2, the users in Group_1 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.
You do not always need to create subgroups in a group map in Cisco UCS Manager.
Configuring LDAP Providers
Configuring Properties for LDAP Providers
The properties that you configure in this task are the default settings for all provider connections of this type defined in Cisco UCS Manager. If an individual provider includes a setting for any of these properties, Cisco UCS uses that setting and ignores the default setting.
If you are using Active Directory as your LDAP server, create a user account in the Active Directory server to bind with Cisco UCS. Give this account a non-expiring password.
What to Do Next
Create an LDAP provider.
Creating an LDAP Provider
Cisco UCS Manager supports a maximum of 16 LDAP providers.
If you are using Active Directory as your LDAP server, create a user account in the Active Directory server to bind with Cisco UCS. Give this account a non-expiring password.
-
In the LDAP server, perform one of the following configurations:
-
Configure LDAP groups. LDAP groups contain user role and locale information.
-
Configure users with the attribute that holds the user role and locale information for Cisco UCS Manager. You can choose whether to extend the LDAP schema for this attribute. If you do not want to extend the schema, use an existing LDAP attribute to hold the Cisco UCS user roles and locales. If you prefer to extend the schema, create a custom attribute, such as the CiscoAVPair attribute.
The Cisco LDAP implementation requires a unicode type attribute.
If you choose to create the CiscoAVPair custom attribute, use the following attribute ID: 1.3.6.1.4.1.9.287247.1
-
For a cluster configuration, add the management port IPv4 or IPv6 addresses for both fabric interconnects. This configuration ensures that remote users can continue to log in if the first fabric interconnect fails and the system fails over to the second fabric interconnect. All login requests are sourced from these IP addresses, not the virtual IPv4 or IPv6 address used by Cisco UCS Manager.
-
-
If you want to use secure communications, create a trusted point containing the certificate of the root certificate authority (CA) of the LDAP server in Cisco UCS Manager.
-
If you need to change the LDAP providers or add or delete them, change the authentication realm for the domain to local, make the changes to the providers, then change the domain authentication realm back to LDAP.
-
If you want to use the special characters listed in the following table for defining the attributes of an Active Directory bind distinguished name, you must replace the special character with an escape, by using a backslash (\) followed by the corresponding hexadecimal value of the character.
|
Special Character |
Description |
Hexadecimal Value |
|---|---|---|
|
, |
comma |
0x2C |
|
+ |
plus sign |
0x2B |
|
" |
double quote |
0x22 |
|
\ |
backslash |
0x5C |
|
< |
left angle bracket |
0x3C |
|
> |
right angle bracket |
0x3E |
|
; |
semicolon |
0x3B |
|
LF |
line feed |
0x0A |
|
CR |
carriage return |
0x0D |
|
= |
equals sign |
0x3D |
|
/ |
forwards slash |
0x2F |
https://msdn.microsoft.com/en-us/library/aa366101 provides more details on replacing special characters with its escape and hexadecimal equivalent.
LDAP remote usernames that include special characters cannot log in to systems that are running versions 2.2(3a) and later. The user cannot log in because of the Nexus OS limitations where special characters, !,%,^, are not supported in the username.
| Step 1 | In the Navigation pane, click Admin. |
| Step 2 | Expand . |
| Step 3 | In the Work pane, click the General tab. |
| Step 4 | In the Actions area, click Create LDAP Provider. |
| Step 5 | On the
Create
LDAP Provider page of the wizard, complete all fields with
appropriate LDAP service information.
|
| Step 6 | On the
LDAP
Group Rule page of the wizard, complete all fields with appropriate
LDAP group rule information.
|
What to Do Next
For implementations involving a single LDAP database, select LDAP as the authentication service.
For implementations involving multiple LDAP databases, configure an LDAP provider group.
Changing the LDAP Group Rule for an LDAP Provider
| Step 1 | In the Navigation pane, click Admin. | ||||||||||||
| Step 2 | Expand . | ||||||||||||
| Step 3 | Expand LDAP Providers and choose the LDAP provider for which you want to change the group rule. | ||||||||||||
| Step 4 | In the Work pane, click the General tab. | ||||||||||||
| Step 5 |
In the LDAP Group Rules area, complete the following fields:
| ||||||||||||
| Step 6 | Click Save Changes. |
Deleting an LDAP Provider
LDAP Group Mapping
LDAP group mapping eliminates having to define role or locale information in the LDAP user object. UCSM can use group membership information to assign a role or locale to an LDAP user during login for organizations using LDAP groups to restrict access to LDAP databases.
When a user logs in to Cisco UCS Manager, the LDAP group map pulls information about the user's role and locale. If the role and locale criteria match the information in the policy, access is granted. Cisco UCS Manager supports a maximum of 28, 128, or 160 LDAP group maps depending on the release version.
Note | Cisco UCS Manager Release 3.1(1) supports a maximum of 128 LDAP group maps, and Release 3.1(2) and later releases support a maximum of 160 LDAP group maps. |
The role and locale definitions that you configure locally in the Cisco UCS Manager do not update automatically based on changes to an LDAP directory. When deleting or renaming LDAP groups in an LDAP directory, you must also update the Cisco UCS Manager with the change.
Note | Cisco UCS Manager includes out-of-the-box user roles, but does not include any locales. Mapping an LDAP provider group to a locale requires that you create a custom locale. |
Creating an LDAP Group Map
| Step 1 | In the Navigation pane, click Admin. | ||
| Step 2 | Expand . | ||
| Step 3 | Right-click LDAP Group Maps and choose Create LDAP Group Map. | ||
| Step 4 | In the
Create
LDAP Group Map dialog box, specify all LDAP group map information,
as appropriate.
|
What to Do Next
Set the LDAP group rule.
Deleting an LDAP Group Map
Configuring RADIUS Providers
Configuring Properties for RADIUS Providers
The properties that you configure in this task are the default settings for all provider connections of this type defined in Cisco UCS Manager. If an individual provider includes a setting for any of these properties, Cisco UCS uses that setting and ignores the default setting.
Note | RADIUS authentication uses Password Authentication Protocol (PAP). |
What to Do Next
Create a RADIUS provider.
Creating a RADIUS Provider
Cisco UCS Manager supports a maximum of 16 RADIUS providers.
Perform the following configuration in the RADIUS server:
-
Configure users with the attribute that holds the user role and locale information for Cisco UCS Manager. You can choose whether to extend the RADIUS schema for this attribute. If you do not want to extend the schema, use an existing RADIUS attribute to hold the Cisco UCS user roles and locales. If you prefer to extend the schema, create a custom attribute, such as the cisco-avpair attribute.
The vendor ID for the Cisco RADIUS implementation is 009 and the vendor ID for the attribute is 001.
The following syntax example shows how to specify multiples user roles and locales if you choose to create the cisco-avpair attribute: shell:roles="admin,aaa" shell:locales="L1,abc". Use a comma "," as the delimiter to separate multiple values.
-
For a cluster configuration, add the management port IPv4 or IPv6 addresses for both fabric interconnects. This configuration ensures that remote users can continue to log in if the first fabric interconnect fails and the system fails over to the second fabric interconnect. All login requests are sourced from these IP addresses, not the virtual IP address used by Cisco UCS Manager.
| Step 1 | In the Navigation pane, click Admin. | ||
| Step 2 | Expand . | ||
| Step 3 | In the
Create
RADIUS Provider dialog box, specify all appropriate RADIUS service
information.
| ||
| Step 4 | Click Save Changes. |
What to Do Next
For implementations involving a single RADIUS database, select RADIUS as the primary authentication service.
For implementations involving multiple RADIUS databases, configure a RADIUS provider group.
Deleting a RADIUS Provider
Configuring TACACS+ Providers
Configuring Properties for TACACS+ Providers
The properties that you configure in this task are the default settings for all provider connections of this type defined in Cisco UCS Manager. If an individual provider includes a setting for any of these properties, Cisco UCS uses that setting and ignores the default setting.
What to Do Next
Create a TACACS+ provider.
Creating a TACACS+ Provider
Cisco UCS Manager supports a maximum of 16 TACACS+ providers.
Perform the following configuration in the TACACS+ server:
-
Create the cisco-av-pair attribute. You cannot use an existing TACACS+ attribute.
The cisco-av-pair name is the string that provides the attribute ID for the TACACS+ provider.
The following syntax example shows how to specify multiples user roles and locales when you create the cisco-av-pair attribute: cisco-av-pair=shell:roles="admin aaa" shell:locales*"L1 abc". Using an asterisk (*) in the cisco-av-pair attribute syntax flags the locale as optional, preventing authentication failures for other Cisco devices that use the same authorization profile. Use a space as the delimiter to separate multiple values.
-
For a cluster configuration, add the management port IPv4 or IPv6 addresses for both fabric interconnects. This configuration ensures that remote users can continue to log in if the first fabric interconnect fails and the system fails over to the second fabric interconnect. All login requests are sourced from these IP addresses, not the virtual IP address used by Cisco UCS Manager.
What to Do Next
For implementations involving a single TACACS+ database, select TACACS+ as the primary authentication service.
For implementations involving multiple TACACS+ databases, configure a TACACS+ provider group.
Deleting a TACACS+ Provider
Multiple Authentication Services Configuration
Multiple Authentication Services
You can configure Cisco UCS to use multiple authentication services by configuring the following features:
Provider Groups
A provider group is a set of providers that the Cisco UCS accesses during the authentication process. All of the providers within a provider group are accessed in the order that the Cisco UCS provider uses to authenticate users. If all of the configured servers are unavailable or unreachable, Cisco UCS Manager automatically falls back to the local authentication method using the local username and password.
Cisco UCS Manager allows you to create a maximum of 16 provider groups, with a maximum of eight providers allowed per group.
Creating an LDAP Provider Group
Creating an LDAP provider group allows you to authenticate using multiple LDAP databases.
Create one or more LDAP providers.
| Step 1 | In the Navigation pane, click Admin. | ||
| Step 2 | Expand . | ||
| Step 3 | Right-click
LDAP
Provider Groups and choose
Create
LDAP Provider Group.
| ||
| Step 4 | In the Create LDAP Provider Group dialog box, specify all of the appropriate LDAP provider group information. |
What to Do Next
Configure an authentication domain or select a default authentication service.
Deleting an LDAP Provider Group
Remove the provider group from an authentication configuration.
Creating a RADIUS Provider Group
Creating a RADIUS provider group allows you to authenticate using multiple RADIUS databases.
Create one or more RADIUS providers.
What to Do Next
Configure an authentication domain or select a default authentication service.
Deleting a RADIUS Provider Group
You cannot delete a provider group if another authentication configuration is using that provider group.
Creating a TACACS+ Provider Group
Creating a TACACS+ provider group allows you to authenticate using multiple TACACS+ databases.
Create one or more TACACS+ providers.
Deleting a TACACS+ Provider Group
You cannot delete a provider group if another authentication configuration is using that provider group.
Authentication Domains
The Cisco UCS Manager uses Authentication Domains to leverage multiple authentication systems. You can specify and configure each authentication domain during login; otherwise, Cisco UCS Manager uses the default authentication service configuration.
You can create up to eight authentication domains. Each authentication domain is associated with a provider group and a realm in the Cisco UCS Manager. The Cisco UCS Manager uses all servers within the realm if you do not specify a provider group.
Creating an Authentication Domain
| Step 1 | In the Navigation pane, click Admin. | ||||||||||||||||||||
| Step 2 | Expand . | ||||||||||||||||||||
| Step 3 | Right-click Authentication Domains and choose Create a Domain. | ||||||||||||||||||||
| Step 4 | In the
Create a
Domain dialog box, complete the following fields:
| ||||||||||||||||||||
| Step 5 | Click OK. |
Selecting a Primary Authentication Service
Selecting the Console Authentication Service
If the system uses a remote authentication service, create a provider for that authentication service. If the system uses only local authentication through Cisco UCS, you do not need to create a provider first.
| Step 1 | In the Navigation pane, click Admin. | ||||||||||
| Step 2 | Expand . | ||||||||||
| Step 3 | Click Native Authentication. | ||||||||||
| Step 4 | In the Work pane, click the General tab. | ||||||||||
| Step 5 | In the
Console
Authentication area, complete the following fields:
| ||||||||||
| Step 6 | Click Save Changes. |
Selecting the Default Authentication Service
If the system uses a remote authentication service, create a provider for that authentication service. If the system uses only local authentication through Cisco UCS, you do not need to create a provider first.
| Step 1 | In the Navigation pane, click Admin. | ||||||||||||||||
| Step 2 | Expand . | ||||||||||||||||
| Step 3 | Click Native Authentication. | ||||||||||||||||
| Step 4 | In the Work pane, click the General tab. | ||||||||||||||||
| Step 5 | In the
Default
Authentication area, complete the following fields:
| ||||||||||||||||
| Step 6 | Click Save Changes. |
Role Policy for Remote Users
By default, if user roles are not configured in Cisco UCS Manager read-only access is granted to all users logging in to Cisco UCS Manager from a remote server using the LDAP, RADIUS, or TACACS protocols. For security reasons, it might be desirable to restrict access to those users matching an established user role in Cisco UCS Manager.
- assign-default-role
-
Does not restrict user access to Cisco UCS Manager based on user roles. Read-only access is granted to all users unless other user roles have been defined in Cisco UCS Manager.
This is the default behavior.
- no-login
-
Restricts user access to Cisco UCS Manager based on user roles. If user roles have not been assigned for the remote authentication system, access is denied.
Configuring the Role Policy for Remote Users
| Step 1 | In the Navigation pane, click Admin. |
| Step 2 | Expand . |
| Step 3 | Click Native Authentication. |
| Step 4 | In the Work pane, click the General tab. |
| Step 5 | In the Role Policy for Remote Users field, click one of the following radio buttons to determine what happens when a user attempts to log in and the remote authentication provider does not supply a user role with the authentication information: |
| Step 6 | Click Save Changes. |
Feedback