Configuring Users, Roles, and Security, Release 4.2.1

 
Updated March 13, 2026
PDF
Is this helpful? Feedback

New and changed information

The following table provides an overview of the significant changes up to this current release. The table does not provide an exhaustive list of all changes or of the new features up to this release.

Release Version Feature Description

Nexus Dashboard 4.2.1

Support for Microsoft Entra ID as an OIDC Identity Provider

Beginning with Nexus Dashboard 4.2.1, user authentication using Microsoft Azure (Entra ID) multi-factor authentication (MFA) domains are now supported. For more information, see Microsoft Entra ID multi-factor authentication (MFA)

Nexus Dashboard 4.2.1

Nexus Dashboard platform security & hardening enhancements

Beginning with Nexus Dashboard 4.2.1, security enhancements have been added for Nexus Dashboard.

For more information, see:
* SSH configuration
* Platform security and hardening enhancements

Nexus Dashboard 4.2.1

Enhanced password security features

You can now make these modifications related to password security for your Nexus Dashboard:

  • Set the minimum password length

  • Enable enforcement of strong password checks

  • Set the number of times that a current password can be reused

  • Set the duration after which a local password expires

For more information, see Violation action.

Nexus Dashboard 4.2.1

Ability to change login banner text

A super-admin user can now modify the text that appears in the lower left corner on the login page in the Nexus Dashboard.

For more information, see Login banner.

Roles and permissions

You can choose how the users logging into the Nexus Dashboard GUI are authenticated. This release supports local authentication as well as LDAP, RADIUS, and TACACS remote authentication servers. User roles and permissions are described in this section, remote authentication configuration is described in Remote authentication, and local user configuration is described in Users.

Cisco Nexus Dashboard allows user access according to roles defined by role-based access control (RBAC). Roles are used in both local and external authentication.

These sections describe the user roles available in Nexus Dashboard and their associated permissions within the platform. The same roles can be configured on a remote authentication server and the server can be used to authenticate the Nexus Dashboard users. Additional details about remote authentication are available in the Remote authentication section.

Roles and permissions in Nexus Dashboard 4.1.1

User role AV pair value Description

Super Administrator

super-admin

Users with this role have full access to all resources in every security domain. A user with this role can perform all operations on the Nexus Dashboard, including backup and restore processes.

Fabric Administrator

fabric-admin

Users with this role have permissions for full fabric management, including creation of network policies, interface configurations and software upgrades. Users with this role and the all security domain access can also add and delete fabrics, including ACI fabrics, to a Nexus Dashboard cluster. See Connecting Clusters for more information.

Designer

designer

Users with this role can make changes to the configuration (the intent) but cannot deploy those changes to the network fabrics.

Approver

approver

When change control is enabled, users with this role can perform operations related to the approval or denial of submitted configuration changes.

Observer

observer

Primarily a read-only user.

Support Engineer

support-engineer

Users with this role are able to perform tasks related to support, such as collecting tech support, creating backups, deploying templates, and general troubleshooting. When change control is enabled, users with this role can also deploy and revert policy changes that were approved. Users with this role are not able to make configuration changes.

Mapping roles from previous releases

Prior to Nexus Dashboard 4.2.1, there were roles provided at the Nexus Dashboard level and in the services running in Nexus Dashboard. These sections map those roles from the previous releases to the roles available in Nexus Dashboard 4.2.1.

note.svg

The Insights service did not support RBAC (any account that could log in to the Nexus Dashboard had full access to Insights), so there is no role-mapping information from previous releases for Insights.

Mapping Nexus Dashboard and Orchestrator roles

User Role in Previous Releases User Role in Nexus Dashboard 4.2.1

admin (read-only)

Observer

Administrator

Super Administrator

Approver

Approver

Dashboard User

Observer

Deployer

Support Engineer

Power-User

Super Administrator

Site Administrator

Fabric Administrator

Site Manager

Designer

Tenant Manager

Designer

User Manager

Super Administrator

Mapping Nexus Dashboard Fabric Controller roles

User Role in Previous Releases User Role in Nexus Dashboard 4.2.1

NDFC Access Admin

Fabric Administrator

NDFC Change Approver

Approver

NDFC Change Deployer

Support Engineer

NDFC Device Upgrade Admin

Fabric Administrator

NDFC Network Admin

Fabric Administrator

NDFC Network Operator

Observer

NDFC Network Stager

Designer

Choosing a default authentication domain

By default, the login screen will select the local domain for user authentication; you can manually change the domain at login time by selecting any of the available login domains from the dropdown menu.

Alternatively, you can set a different default login domain to the most commonly used as follows:

note.svg

The domain must already exist before you can set it as the default domain. Adding remote authentication domains is described in Remote Authentication.

  1. Choose the default login domain.

    1. From the main navigation menu, select Admin > Users and Security.

    2. Click the Authentication tab.

    3. In the top right of the Default authentication tile, click the Edit icon.

      The Edit default authentication page opens.

  2. In the Edit default authentication page that opens, choose the Login domain from the dropdown, then click Save.

Multi-factor authentication

You can configure your Nexus Dashboard to use multi-factor authentication (MFA) for user login.

When configuring multi-factor authentication:

Add Okta as a remote authentication provider

Before you begin

To add Okta as a remote authentication provider:

  1. Add an authentication domain.

    1. From the main navigation menu, select Admin > Users and Security.

    2. Click the Authentication tab.

    3. In the main pane, click Create login domain.

  2. In the Create login domain screen that opens, provide domain details.

    1. Provide the Name for the domain.

    2. (Optional) Provide its Description.

    3. From the Realm dropdown, select OIDC.

    4. In the Client ID field, enter the client ID you obtained from your Okta account.

    5. In the Client Secret field, enter the client secret you obtained from your Okta account.

    6. In the Issuer field, enter the URI you obtained from your Okta account.

    7. (Optional) Check the User Proxy option if you want to connect to Okta over a proxy.

    8. Leave the Scopes options unchecked.

      This release supports the openid scope only.

  3. Click Save to finish adding the domain.

Logging in to Nexus Dashboard using MFA

  1. Navigate to one of your Nexus Dashboard IPs as your typically would.

  2. From the Login Domain dropdown, select the OIDC domain that you created in Add Okta as a remote authentication provider.

    The Username and Password fields will not be displayed.

  3. Click Login.

    You will be redirected to the Okta login page.

  4. Log in using a user that was configured in Okta as described in Configure an Okta account as an MFA provider.

    A push notification will be sent to your Duo client.

  5. Approve the login using Duo.

    You will be redirected back to the Nexus Dashboard UI and logged in using the Okta user.

Configure an Okta account as an MFA provider

The following steps provide basic configuration required to enable MFA for Nexus Dashboard using Okta as a provider. Detailed Okta configurations are outside the scope of this document, see Okta documentation for all available options.

To configure Okta for Nexus Dashboard MFA:

  1. Log in to your Okta account.

    To create an account, browse to https://developer.okta.com.

  2. Create a new app integration.

    1. From the left navigation menu, select Applications > Applications.

    2. Click Create App Integration.

    3. For Sign-in method, select OIDC - OpenID Connect.

    4. For Application Type, select Web Application.

    5. Click Next.

    6. Provide App integration name, for example, nd-mfa.

      The following steps assume you used nd-mfa as the app integration name. If you choose a different name, replace nd-mfa where appropriate.

    7. For Sign-in redirect URIs, enter https://<nd-node1-ip>/oidccallback

      Replace the <nd-node1-ip> with your cluster node IP address, then click +Add URI to provide the URIs for all nodes in the cluster.

    8. For Controlled Access, choose Skip group assignment for now.

    9. Leave other fields at their default values and click Save.

  3. Add the required attributes to the default user.

    1. From the left navigation menu, select Directory > Profile Editor.

    2. Click the Okta User (default) profile.

    3. Click +Add Attribute.

    4. For Data type, choose string.

    5. For Display name, Variable name, and Description, enter CiscoAVPair.

    6. Ensure that Attribute required is unchecked.

    7. Leave other fields at default values and click Save and Add Another.

    8. For Data type, choose string.

    9. For Display name, Variable name, and Description, enter nduser.

    10. Ensure that Attribute required is unchecked.

    11. Leave other fields at default values and click Save.

  4. Add the required attributes to the nd-mfa user you created.

    1. From the left navigation menu, select Directory > Profile Editor.

    2. Click the nd-mfa User (default) profile.

    3. Click +Add Attribute.

    4. For Data type, choose string.

    5. For Display name, Variable name, and Description, enter CiscoAVPair.

    6. Ensure that Attribute required is checked.

    7. Leave other fields at default values and click Save and Add Another.

    8. For Data type, choose string.

    9. For Display name, Variable name, and Description, enter nduser.

    10. Ensure that Attribute required is checked.

    11. Leave other fields at default values and click Save.

  5. Map the attributes.

    1. From the left navigation menu, select Directory > Profile Editor.

    2. Click the nd-mfa User profile.

    3. In the Attributes area of the main page, click Mappings.

      The nd-mfa User Profile Mappings page opens.

      503662.jpg

    4. At the top of the nd-mfa User Profile Mappings page, click nd-mfa to Okta User.

    5. Select app.CiscoAVPair from the dropdown menu next to CiscoAVPair.

    6. Select app.nduser from the dropdown menu next to nduser.

    7. Click Save Mappings.

    8. Click Apply updates now.

  6. Create users.

    1. From the left navigation menu, select Directory > People.

    2. Click +Add person.

    3. Provide the user information.

    4. Click Save and Add Another to add another user or click Save to finish.

      You must add all users that you want to be able to log in to your Nexus Dashboard.

  7. Assign users to the app.

    1. From the left navigation menu, select Applications > Application.

    2. Click the application you created (nd-mfa).

    3. Select the Assignments tab.

    4. Choose Assign > Assign to People.

      The Assign nd-mfa to People page opens.

    5. In the Assign nd-mfa to People page, click Assign next to the user you want to be able to log in to your Nexus Dashboard.

    6. In the user details page that opens, provide a value for CiscoAVPair and nduser fields.

      The CiscoAVPair values are described in the Configure a remote authentication server, for example shell:domains=all/super-admin/.

      The nduser value will be used as the username for this user when logging in to your Nexus Dashboard.

    7. Click Save and Go Back.

    8. Assign another user or click Done to finish.

      You must add all users that you created in a previous step.

  8. Configure Claims for the app.

    1. From the left navigation menu, select Security > API.

    2. Click the default name.

    3. Select the Claims tab.

    4. Click +Add Claim to add the CiscoAVPair claim.

    5. In the Name field, enter CiscoAVPair.

    6. From the Include in token type dropdown, select ID Token.

      We recommend using ID Token, however Access Token is also supported.

    7. In the Value field, enter appuser.CiscoAVPair.

    8. Click Save.

    9. Click +Add Claim to add the nduser claim.

    10. In the Name field, enter nduser.

    11. From the Include in token type dropdown, select ID Token.

      You must create both claims in the same token, mixing ID Token and Access Token is not supported.

    12. In the Value field, enter appuser.nduser.

    13. Click Save.

  9. Gather the required Okta account information for adding it as authentication provider for your Nexus Dashboard.

    1. From the left navigation menu, select Security > API.

    2. Click the default name.

    3. Note down the Issuer value.

      503663.jpg

    4. From the left navigation menu, select Application > Applications.

    5. Click the application you created (nd-mfa).

    6. Note down the Client ID and Client Secret values.

      503664.jpg

Configure an MFA client

This release supports only Cisco Duo as MFA client.

The following steps provide basic configuration required to enable using Cisco Duo for Nexus Dashboard MFA. Detailed Duo configurations are outside the scope of this document, see Cisco Duo documentation for all available options.

To configure Duo:

  1. Log in to your Okta account.

  2. Add DUO as an MFA type.

    1. From the left navigation menu, select Security > Multifactor.

    2. In the Factor Types tab, select Duo Security.

      If you do not have the Duo Security option, you will need to open a support case with Okta from https://support.okta.com/help/s/opencase.

    3. In the Duo Security page, provide the required information.

      For more information on how to obtain integration key, secret key, and API hostname, see https://duo.com/docs/okta.

      Ensure that Duo Username Format is set to Email.

    4. Click Save.

  3. Create a Duo rule.

    1. From the left navigation menu, select Applications > Application.

    2. Click the application you created (nd-mfa).

    3. Select the Sign On tab.

    4. In the Sign On Policy area, click +Add Rule.

    5. Provide the name for the rule.

    6. In the Access area, enable Prompt for factor and select Every sign on.

    7. Specify other options as required by your use case.

    8. Click Save.

  4. Configure Okta and Duo integration.

    There are two ways you can allow the users you configured in Okta to use the Duo app for MFA — have the Duo admin add all the same users in Duo dashboard or have each individual user log in to Okta and self-enroll.

    To configure users in Duo dashboard:

    1. Log in to your Duo dashboard as admin user.

    2. From the left navigation menu, select Users.

    3. Click Add User and provide the details that match the user’s information in Okta.

    4. Repeat this step for all users you added in Okta.

    To self-enroll:

    1. Instruct every user you created in Configure an Okta account as an MFA provider to log in to Okta on their own using your specific Okta domain.

      You can determine the Okta domain to use by navigating to Application > Application, then clicking the nd-mfa application you created and copying the Okta domain URL:

      503665.jpg

    2. Once they’re logged in, they can navigate to the Settings page from the top right user menu.

    3. Choose Duo Security Setup and follow the instructions on the screen.

Microsoft Entra ID multi-factor authentication (MFA)

You can now configure Microsoft Entra ID multi-factor authentication (MFA) to enable users to log in with their Microsoft Entra ID credentials.

Nexus Dashboard uses the OpenID Connect (OIDC) authorization protocol to configure Microsoft Entra ID as an identity provider (IdP) for login and user authentication. Using the OIDC authentication protocol, Nexus Dashboard ensures secure handling of user credentials and provides a standardized way for identity verification across different applications.

Guidelines and limitations

  • These Microsoft Entra ID (Azure Portal) permissions are required:

    • Application Administrator role OR Cloud Application Administrator role

    • User Administrator role is required to create and configure app registrations and to create directory extension attributes

Add Microsoft Entra ID as a remote authentication provider

Before you begin

Follow these steps to add Microsoft Entra as a remote authentication provider.

  1. Add a proxy server.

    1. Navigate to Admin > System Settings > General.

    2. In the Proxy configuration area, click Edit.

    3. Click + Add proxy server in the proxy configuration page.

    4. From the Type drop-down list, choose HTTP.

    5. In the Server field, provide the full address for the proxy server, including the port if required.

      For example, http://proxy.company.com:80.

    6. Click Save.

    7. Click + Add proxy server to add a secondary proxy server.

    8. From the Type drop-down list, choose HTTPS.

    9. In the Server field, provide the full address for the proxy server, including the port if required.

      For example, http://proxy.company.com:80.

    10. Click Save.

  2. Add an authentication domain.

    1. From the main navigation menu, choose Admin > Users and Security.

    2. Click the Authentication tab.

    3. Click Create login domain.

    4. In the Create login domain page, provide domain details.

    5. Provide the Name for the domain, for example, Entra.

    6. (Optional) Provide a Description of the domain.

    7. Click the Realm drop-down list, choose Microsoft Entra Id.

    8. In the Client ID field, enter the client ID you obtained from your Microsoft Entra account.

    9. In the Client Secret field, enter the client secret you obtained from your Microsoft Entra account.

    10. In the Issuer field, enter the URL you obtained from your Microsoft Entra account. You can retrieve this from the Overview > Endpoint page from the Azure portal using the app registration used for Entra ID. You can copy and paste the OpenID Connect metadata document endpoint and remove the '.well-known/openid-configuration' from the URL.

    11. Check the User Proxy option if you want to connect to Microsoft Entra over a proxy.

    12. Leave the Scopes options unchecked.

    13. Click Save to save the domain information and return to the Admin > Users and Security > Authentication page.

      You should see an entry for the domain you created. For example, if you used "Entra" as your domain name, you will see a domain listed by this name in the Name column of the table.

  3. Click the domain name listed in the Name column to view the details and verify all the information is correct.

  4. Click Refresh on the Admin > Users and Security > Authentication page.

Logging in to Nexus Dashboard using MFA

Follow these steps to login to Nexus Dashboard using MFA.

  1. Navigate to one of your Nexus Dashboard IPs as you typically would.

  2. From the Login Domain drop-down list, choose the Microsoft Entra Id domain that you created in Add Microsoft Entra ID as a remote authentication provider.

    The Username and Password fields will not be displayed.

  3. Click Login.

    You will be redirected to the Microsoft Entra login page.

  4. In the Pick an account dialog box, choose an ND account you created.

  5. Enter a password for this account.

  6. Click Sign in.

    A push notification will be sent to your Duo client.

  7. Approve the login using Duo client.

    You will be redirected back to the Nexus Dashboard UI and logged in using the Microsoft Entra user.

Configure identity provider details

The following sections provide details on the configuration required to enable MFA for Nexus Dashboard using Microsoft Entra ID as an identity provider.

Register your application

Follow these steps to register your application.

  1. Navigate to the Azure Portal https://portal.azure.com and sign in with your admin account.

  2. Navigate to Azure Active Directory > App registrations > + New registration

  3. Configure these settings.

    • Name: Nexus-Dashboard-OIDC (or your preferred name)

    • Supported account types: Select Accounts in this organizational directory only (Single tenant)

    • Redirect URI:

    • Platform: Web

    • URI: https://<ND_IP_OR_HOSTNAME>/oidccallback

      Example: https://198.51.100.1/oidccallback

  4. Click Register.

note.svg

After registration, you must save Application (client) ID, Directory (tenant) ID, and the Object ID information from the overview page.

Create client secret

Follow these steps to create a client secret.

  1. In your app registration, navigate to Manage > Certificates & secrets > Client secrets > + New client secret

  2. Add a description and expiry date:

    • Description: ND-OIDC-Secret

    • Expires: Choose an appropriate expiration time (6 months, 12 months, or 24 months)

  3. Click Add

  4. Save the Secret Value

note.svg

Copy the Secret Value immediately and store it securely.

Configure API permissions

Follow these steps to configure the API permissions.

  1. Navigate to the API permissions > + Add a permission page.

  2. Choose Microsoft Graph > Delegated permissions.

  3. Search for the User and add these from the search result.

    • User.Read (should already be there)

    • User.ReadWrite.All (needed for user attribute updates)

  4. Click Add permissions.

  5. Grant Admin Consent.

  6. Click "Grant admin consent for [Your Organization]".

  7. Click Yes to confirm.

  8. Verify all permissions show “Granted for [Your Organization]”.

Configure application manifest

Follow these steps to configure application manifest.

  1. Edit Manifest. Navigate to the Manifest in your app registration.

  2. Enable mapped claims.

    1. Find the line: "acceptMappedClaims": null and change it to "acceptMappedClaims": true.

      For example:

      "api": {

    "acceptMappedClaims": true,

    "knownClientApplications": [],

    "requestedAccessTokenVersion": null,

    "oauth2PermissionScopes": [],

    "preAuthorizedApplications": []

}

  3. Click Save at the top to save the Manifest.

Configure directory extension attributes

Directory extension attributes are custom attributes that store the user’s Nexus Dashboard username and role information.

Create Extension Attributes via Azure CLI

  1. Open Azure Cloud Shell

    • In Azure Portal, click the Cloud Shell icon (>_) at the top

    • Or go to: https://shell.azure.com

    • Choose Bash environment

  2. Get Application Object ID Replace YOUR_CLIENT_ID with your Application (client) ID:

    az rest --method GET \

  --uri "https://graph.microsoft.com/v1.0/applications?$filter=appId eq 'YOUR_CLIENT_ID'"

Example:

az rest --method GET \

  --uri "https://graph.microsoft.com/v1.0/applications?$filter=appId eq 'cf6303f8-3220-4351-99a7-727fcc92acc8'"

    • From the response, note the "id" field (this is the Object ID).

Create 'nduser' extension attribute

Replace YOUR_OBJECT_ID with the Object ID from the previous step:

az rest --method POST \

  --uri "https://graph.microsoft.com/v1.0/applications/YOUR_OBJECT_ID/extensionProperties" \

  --headers "Content-Type=application/json" \

  --body '{

    "name": "nduser",

   "dataType": "String",

    "targetObjects": ["User"]

  }'
note.svg

Note down the returned "name" field (for example extension_cf6303f83220435199a7727fcc92acc8_nduser)

Create CiscoAVPair extension attribute

az rest --method POST \

  --uri "https://graph.microsoft.com/v1.0/applications/YOUR_OBJECT_ID/extensionProperties" \

  --headers "Content-Type=application/json" \

  --body '{

    "name": "CiscoAVPair",

    "dataType": "String",

    "targetObjects": ["User"]

  }'
note.svg

The returned "name" field (For example, extension_cf6303f83220435199a7727fcc92acc8_CiscoAVPair)

Verify extension attributes

az rest --method GET \

 --uri "https://graph.microsoft.com/v1.0/applications/YOUR_OBJECT_ID/extensionProperties"

You should see both nduser and CiscoAVPair attributes.

Assign extension attributes

You can assign extension attributes and set the values for different user roles.

note.svg

You must have a user administrator role to perform this task.

Follow these steps to assign extension attributes.

  1. Get User Object ID. Replace username with the user’s display name or UPN:

    az rest --method GET \
   --uri "https://graph.microsoft.com/v1.0/users?$filter=displayName eq 'username'"
    Example:
az rest --method GET \
  --uri "https://graph.microsoft.com/v1.0/users?\$filter=displayName eq 'john.doe'"
    note.svg

    Note the "id" field from the response (user’s Object ID)

  2. Set User Attributes Replace:

    1. USER_OBJECT_ID with the user’s Object ID

    2. YOUR_CLIENT_ID_NO_DASHES with your Client ID (remove all dashes)

    3. username with the desired ND username

    4. ROLE with the appropriate role

az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/users/USER_OBJECT_ID" \
  --headers "Content-Type=application/json" \
  --body '{
    "extension_YOUR_CLIENT_ID_NO_DASHES_nduser": "username",
    "extension_YOUR_CLIENT_ID_NO_DASHES_CiscoAVPair": "shell:domains=all/ROLE"
  }'

Example for an Observer:

az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/users/95cc90b7-be2d-43b2-973e-47a7bce6c9bc" \
  --headers "Content-Type=application/json" \
  --body '{
    "extension_cf6303f83220435199a7727fcc92acc8_nduser": "john.doe",
    "extension_cf6303f83220435199a7727fcc92acc8_CiscoAVPair": "shell:domains=all/observer"
  }'

Example for a Super Admin:

az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/users/fe3e5ae2-cae7-45fa-b169-a398442cb309" \
  --headers "Content-Type=application/json" \
  --body '{
    "extension_cf6303f83220435199a7727fcc92acc8_nduser": "admin.user",
    "extension_cf6303f83220435199a7727fcc92acc8_CiscoAVPair": "shell:domains=all/super-admin"
  }'

Example for Mixed Roles:

az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/users/a3ef6357-7f75-450c-b0e1-9fb5e76b2583" \
  --headers "Content-Type=application/json" \
  --body '{
    "extension_cf6303f83220435199a7727fcc92acc8_nduser": "mixed.user",
    "extension_cf6303f83220435199a7727fcc92acc8_CiscoAVPair": "shell:domains=all/observer|approver|fabric-admin"
  }'

Verify User Attributes

az rest --method GET \
  --uri "https://graph.microsoft.com/v1.0/users/USER_OBJECT_ID?\$select=displayName,userPrincipalName,extension_YOUR_CLIENT_ID_NO_DASHES_nduser,extension_YOUR_CLIENT_ID_NO_DASHES_CiscoAVPair"

You should see the nduser and CiscoAVPair values in the response

Configure claims mapping

  1. Navigate to your Enterprise Application.

    1. Azure Portal > Azure Active Directory > Enterprise applications

    2. Search for your application and choose your application. For example, Nexus-Dashboard-OIDC.

  2. Access Single Sign-On settings

    1. In the left menu, click Single sign-on.

    2. Under Attributes & Claims, click Edit.

  3. Add new claims

    1. Add CiscoAVPair claim.

      1. Click + Add new claim.

        • Name: CiscoAVPair .

        • Source: Choose Directory schema extension . A popup will appear with "Select Application" message.

      2. In the search box, enter your application name, for example, Nexus-Dashboard-OIDC.

      3. Choose your application, for example, Nexus-Dashboard-EntraID-Dev. This application should have your Client ID.

      4. Click Select. A popup appears with a message that says, "Add Extension Attributes". You will see a list of available extension attributes:

        user.CiscoAVPair (extension_cf6303f8…)
        user.nduser (extension_cf6303f8…)

      5. Choose user.CiscoAVPair.

      6. Click Add. The Schema extension attribute field will be populated with the full extension name

      7. Click Save.

    2. Add nduser claim:

    3. Click + Add new claim

      • Name: nduser

      • Source: Select Directory schema extension. A popup will appear with a message that says, "Select Application".

    4. Search for your application and select it. For example, *Nexus-Dashboard-EntraID-Dev *.

    5. Click Select.

    6. In the “Add Extension Attributes” popup, choose user.nduser

    7. Click Add. The Schema extension attribute field will be populated

    8. Click Save.

  4. Verify claims configuration.

    1. You should now see two additional claims in the list:

      • Claim name: CiscoAVPair, Type: JWT, Value: user.ciscoavpair (extensi…​)

      • Claim name: nduser, Type: JWT, Value: user.nduser (extension_cf…​)

note.svg

You may see an information banner: “OIDC Applications require custom signing keys to customize claims.” If you encounter issues, expand Advanced settings and ensure acceptMappedClaims is enabled.

Multi-cluster primary as an authentication domain

In Nexus Dashboard, you can configure the primary cluster as the authentication domain to support role-based access control (RBAC) across clusters, eliminating the need for a an external authentication provider, such as a AAA remote authentication server. Local users (with observer role) configured on the primary cluster can login as remote users from any clusters with a login domain in Multi-cluster realm type. For more information, see Log in using a multi-cluster domain.

note.svg

A cluster can have only one multi-cluster authentication login domain of the Multi-cluster realm type.

You can create a multi-cluster login domain in Nexus Dashboard during onboarding. You can check the Enable multi-cluster authentication domain check box and provide a name for the multi-cluster login domain. For more information on creating multi-cluster login domain, see Onboard multi-cluster and enable primary cluster to act as an authentication domain.

Guidelines and limitations

  • When you enable a multi-cluster domain and provide a login name during creation (greenfield), the login domain is created for both primary and secondary clusters.

  • If you enable the multi-cluster domain during a subsequent onboarding, the login domain is created in the primary cluster and only on the new secondary cluster being onboarded. You must manually create the domain for all other secondary clusters.

  • If a multi-cluster domain login already exists during onboarding, attempting to create it using the Enable multi-cluster authentication domain check box will result in no action.

  • Upgrades from previous Nexus Dashboard releases require manually creating a multi-cluster domain login. For example, if you are upgrading from Nexus Dashboard 3.2 to 4.2.1, you can manually create a multi-cluster domain login to use this feature. For more information, see Enable primary cluster to act as an authentication domain and create multi-cluster login domain manually

  • Disabling the multi-cluster domain login on a secondary cluster affects only that cluster, while disabling it on the primary cluster affects all clusters.

Onboard multi-cluster and enable primary cluster to act as an authentication domain

Follow these steps to onboard multi-cluster and enable primary cluster to act as an authentication domain.

  1. Log in to the Nexus Dashboard of the cluster to designate it as the primary cluster.

  2. Add the second cluster.

  3. Navigate to Admin > System Settings.

  4. Click Multi-cluster connectivity.

  5. Click Connect Cluster.

  6. In Select type, choose Nexus Dashboard.

  7. Click Next.

  8. In the Remote cluster settings page, enter these field values:

    1. Hostname IP Address

    2. Username

    3. Password

    4. Login domain

  9. Check the Enable multi-cluster authentication domain check box.

  10. Enter a name for Multi-cluster login domain name, for example, MulticlusterAuth.

  11. Click Next to connect the clusters.

Enable primary cluster to act as an authentication domain and create multi-cluster login domain manually

Follow these steps to enable primary cluster to act as an authentication domain and create multi-cluster login domain manually.

  1. From the main navigation menu, choose Admin > Users and Security.

  2. Click the Authentication tab.

  3. Check the check box next to the multi-cluster domain you created.

  4. Choose Actions > Create login domain.

  5. In the Create login domain, provide domain details.

    1. Provide the Name for the domain.

    2. (Optional) Add a description for the domain Description.

    3. From the Realm drop-down list, choose Multi-cluster realm type.

  6. Check the Enable multi-cluster authentication domain check box.

  7. Click Save

    You can use the Actions drop-down list to perform these actions.

    • Choose Actions > Set as default to set the multi-cluster domain as the default authentication provider.

    • Choose Actions > Edit to make changes to the login domain information.

    • Choose Actions > Delete to delete the multi-cluster domain.

Log in using a multi-cluster domain

Follow these steps to log in using a multi-cluster domain.

  1. Navigate to one of your Nexus Dashboard IP addresses.

  2. Enter your username and password in the Username and Password fields.

  3. From the Login Domain drop-down list, choose multi-cluster domain name you created. For example, Multi-cluster domain.

  4. Click Login.

Users

The Users page allows you to view and manage all users that have access to the Nexus Dashboard.

The Local tab displays all local users while the Remote tab displays users that are configured on the remote authentication servers you have added as described in the Remote authentication section.

Guidelines and limitations: Users

  • The default local observer user cannot be deleted.

  • Single sign-on (SSO) between the Nexus Dashboard, fabrics, and applications is available for remote users only. For more information on configuring remote users, see Remote authentication.

  • When an administrator adds a local user as described in Add local users, the administrator must provide a password for that local user. When that local user then logs into the Nexus Dashboard for the first time, they will be asked to change their password again at that initial login stage. This is default behavior that is not configurable.

  • When configuring local users, note that all local user configurations are case sensitive.

Add local users

  1. Create a new local user.

    1. From the main navigation menu, select Admin > Users and Security.

    2. Click the Users tab.

    3. In the main pane, click Create local user.

  2. In the Create local user screen that opens, provide user details.

    1. Provide the User ID that will be used for logging in.

    2. Provide and confirm the initial Password.

      note.svg

      As described in Guidelines and limitations: Users, when the local user that is being created in these procedures first logs into the Nexus Dashboard, they will be asked to change their password again at that initial login stage.

    3. Provide the First Name, Last Name, and Email for the user.

    4. Determine if you want to set the Remote user authentication field to Enabled or Disabled.

      Remote user authentication is used for signing into Nexus Dashboard when using identity providers that cannot provide authorization claims. If you choose Enabled for this Remote user authentication field, the local user ID can’t be used to directly log in to the Nexus Dashboard.

    5. Provide the Remote ID claim information.

    6. Click + Add Security Domain and Roles.

    7. In the Security Domain Name field, choose the security domain to associate with this user.

    8. In the Role field, choose the role to associate with this user.

      You can select one or more roles for each user. The available roles and their permissions are described in Roles and permissions.

      For all of the user roles you select, you can choose to enable read-only or read-write access. In case of read-only access, the user will be able to view the objects and settings allowed by their user Role but unable to make any changes to them.

    9. Choose the tenant domain to associate with this local user in the Tenant domain field, if applicable.

      The Tenant domain field is displayed if the tenant or tenant group functionality that is introduced in Nexus Dashboard release 4.2.1 is enabled. For more information, see Configuring Tenants and Tenant Domains.

    10. Click Create to save the user.

Edit local users

  1. Open user details screen.

    1. From the main navigation menu, select Admin > Users and Security.

    2. Click the Users tab.

    3. In the main pane, click on the user’s name.

    4. In the details pane that opens, click the Details icon.

  2. In the <user-name> details screen that opens, click the Edit icon.

  3. In the Edit User screen that opens, update the settings as necessary.

    note.svg

    If you choose the Reset password option for this local user, a password security workflow is enforced, similar to the one described in Add local users, where this local user will be asked to change their password again at that initial login stage when they first log into the Nexus Dashboard. The Reset password option is only valid when editing a local user.

View remote user information

To view remote users:

  1. From the main navigation menu, select Admin > Users and Security.

  2. Choose Users > Remote.

    If you use remote authentication for TACACS or RADIUS, those remote users will appear on this page after their first login to Nexus Dashboard with their remote credentials.

Remote authentication

Cisco Nexus Dashboard supports a number of remote authentication providers, including LDAP, TACACS, and Radius.

When configuring external authentication servers:

  • You must configure each user on the remote authentication servers.

  • All LDAP configurations are case sensitive.

    For example, if you have OU=Cisco Users on the LDAP server and OU=cisco users on the Nexus Dashboard, the authentication will not work.

  • For LDAP configurations, we recommend using CiscoAVPair as the attribute string. If, for any reason, you are unable to use an Object ID 1.3.6.1.4.1.9.22.1, an additional Object IDs 1.3.6.1.4.1.9.2742.1-5 can also be used in the LDAP server.

    Alternatively, instead of configuring the Cisco AVPair values for each user, you can create LDAP group maps in the Nexus Dashboard.

  • Single sign-on (SSO) between the Nexus Dashboard, fabrics, and applications is available for remote users only.

  • When using SSO to cross-launch into an APIC fabric from your Nexus Dashboard’s Fabrics page, the AV pairs defined for the Nexus Dashboard user are also used when logging into the APIC.

    For example, a user defined as observer for the Nexus Dashboard cluster will also have admin privileges in the APIC.

Configure a remote authentication server

When configuring the remote authentication server for the Nexus Dashboard users, you must add a custom attribute-value (AV) pair, specifying the username and the roles assigned to them.

The user roles and their permissions are the same as for the local users you would configure directly in the Nexus Dashboard GUI as described in Roles and permissions. See Roles and permissions in Nexus Dashboard 4.1.1 for a list of the Nexus Dashboard user roles and the AV pair you would use to define the roles on a remote authentication server, such as LDAP.

A typical string includes the domain, followed by the read-only roles using the slash (/) character; individual roles are separated by the pipe (|) character:

shell:domains=<domain1>/<Role1>|<Role2>,<domain2>/<Role2>|<Role3>

For example, the following string illustrates how to assign the Observer role to a user in all domains, and the Fabric Administrator role in domain_A:

shell:domains=all/observer,domain_A/fabric-admin

Add LDAP as the remote authentication provider

Before you begin

  • You must have at least one user already configured on the LDAP server as described in Configure a remote authentication server.

    You will need to use an existing user for end-to-end verification of LDAP configuration settings.

To add an LDAP remote authentication provider:

  1. Add an authentication domain.

    1. From the main navigation menu, select Admin > Users and Security.

    2. Click the Authentication tab.

    3. In the main pane, click Create login domain.

  2. In the Create login domain screen that opens, provide domain details.

    1. Provide the Name for the domain.

    2. (Optional) Provide its Description.

    3. From the Realm dropdown, select LDAP.

    4. Then click +Add Provider to add a remote authentication server.

      The Add Provider page opens.

  3. Provide the remote authentication server details.

    1. Provide the Hostname or IP Address of the server.

    2. (Optional) Provide the Description of the server.

    3. Provide the Port number.

      The default port is 389 for LDAP.

    4. Provide the Base DN and Bind DN.

      The Base DN and Bind DN depend on how your LDAP server is configured. You can get the Base DN and Bind DN values from the distinguished name of the user created on the LDAP server.

      Base DN is the point from which the server will search for users. For example, DC=nd,DC=local.

      Bind DN is the credentials used to authenticate against the server. For example, CN=observer, CN=Users,DC=nd,DC=local.

    5. Provide and confirm the Key.

      This is the password for your Bind DN user. Anonymous bind is not supported, so you must provide a valid value in these fields.

    6. Specify the Timeout and number of Retries for connecting to the authentication server.

    7. Provide the LDAP Attribute field for determining group membership and roles.

      The following two options are supported:

      • ciscoAVPair (default) — used for LDAP servers configured with Cisco AVPair attributes for user roles.

      • memberOf — used for LDAP servers configured with LDAP group maps. Adding a group map is described in a following step.

    8. (Optional) Enable SSL for LDAP communication.

      If you enable SSL, you must also provide the SSL Certificate and the SSL Certificate Validation type:

      • Permissive: Accept a certificate signed by any certificate authority (CA) and use it for encryption.

      • Strict: Verify the entire certificate chain before using it.

    9. Choose Default or Custom in the Filter Type field.

      If you choose Custom LDAP filter, a sample of a working syntax is (cn={username}).

    10. (Optional) Enable Server Monitoring.

      If you choose to enable monitoring, you must also provide the Username and Password for it.

    11. In the Validation fields, provide a Username and Password of a user already configured on the LDAP server you are adding.

      Nexus Dashboard will use this user to verify the end-to-end authentication to ensure that the settings you provided are valid.

    12. Click Save to complete provider configuration.

    13. Repeat this step for any additional LDAP authentication servers you want to use with this domain.

  4. (Optional) Enable and configure LDAP Group Map Rules.

    If you want to authenticate your LDAP users using Cisco AV pair strings, skip this step.

    1. In the LDAP Auth Choice, select LDAP Group Map Rules.

    2. Click Add LDAP Group Map Rule.

      The Add LDAP Group Map Rule page opens.

    3. Provide the Group DN for the group.

      The format depends on your LDAP tree. For example: DN=xxx,OU=xxx,DC=xxx and so on.

    4. Select one or more Roles for the group.

    5. Click Save to save the group configuration.

    6. Repeat this step for any additional LDAP groups.

  5. Click Save to finish adding the domain.

Add Radius or TACACS as the remote authentication provider

note.svg

Beginning with Nexus Dashboard release 3.2.2m and later, the Message-Authenticator attribute is included in RADIUS Access-Accept, Access-Reject, and Access-Request packets sent to the RADIUS server. Due to this enforced behavior, the RADIUS server may require configuration changes to properly process the Message-Authenticator attribute. It is mandatory for the RADIUS server to enforce receiving this attribute. For additional security context, see Blast-RADIUS (CVE-2024-3596) Protocol Spoofing Mitigation.

Before you begin

  • You must have at least one user already configured on the remote authentication server as described in Configure a remote authentication server.

    You will need to use an existing user for end-to-end verification of the provider configuration settings.

To add a RADIUS or TACACS+ remote authentication provider:

  1. Add an authentication domain.

    1. From the main navigation menu, select Admin > Users and Security.

    2. Click the Authentication tab.

    3. In the main pane, click Create login domain.

  2. In the Create login domain screen that opens, provide domain details.

    1. Provide the Name for the domain.

    2. (Optional) Provide its Description.

    3. From the Realm dropdown, select RADIUS or TACACS+.

    4. Then click +Add Provider to add a remote authentication server.

      The Add Provider page opens.

  3. Provide the remote authentication server details.

    1. Provide the Hostame or IP Address of the server.

    2. (Optional) Provide the Description of the server.

    3. Choose Authorization Protocol used by the server.

      You can choose PAP, CHAP, or MS-CHAP.

    4. Provide the Port number.

      The default port is 1812 for RADIUS and 49 for TACACS

    5. Provide and confirm the Key.

      This is the password used for connecting to the provider server.

    6. (Optional) Choose whether you want to enable Server Monitoring.

      If you choose to enable monitoring, you must also provide the Username and Password for it.

    7. In the Validation fields, provide a Username and Password of a user already configured on the remote server you are adding.

      Nexus Dashboard will use this user to verify the end-to-end authentication to ensure that the settings you provided are valid.

    8. Click Save to complete provider configuration.

    9. Repeat this step for any additional remote authentication servers.

  4. Click Save to finish adding the domain.

Edit remote authentication domains

If you want to make changes to a domain that you have created:

  1. From the main navigation menu, select Admin > Users and Security.

  2. Click the Authentication tab.

  3. From the Actions menu for the domain, select Edit Login Domain.

    You cannot change the name and the type of the authentication domain, but you can make changes to the description and provider configuration.

    note.svg

    If you make any changes to the login domain, including simply updating the description, you must re-enter the key for all existing providers.

Delete remote authentication domains

  1. From the main navigation menu, select Admin > Users and Security.

  2. Click the Authentication tab.

  3. From the Actions menu for the domain, select Delete Login Domain.

  4. In the Confirm Delete prompt, click OK to confirm.

AAA remote authentication passthrough

The authentication, authorization, and accounting (AAA) remote authentication passthrough feature allows authentication for remote users and eliminates the need to update user credentials manually. When the AAA remote authentication passthrough feature is enabled, it automatically saves discovery and device credentials for remote users after successful login. This feature enhances the workflow for managing fabrics and switches, as users no longer need to change credentials every time a password is changed or updated in the remote server.

Network administrators can enable the AAA remote passthrough feature in the Nexus Dashboard Admin > System Settings > Fabric Management. See Enable AAA remote passthrough for more information.

Discovery and device credentials

When a SAN fabric is created or discovered, information on Fabric Name, Seed Switch IP, username, and password are added to Nexus Dashboard. The username and password information entered at this time are called the SAN Discovery Credentials.

note.svg

You can only have one discovery credential for a fabric.

The Nexus Dashboard discovery feature uses the discovery credentials entered at the time of fabric creation to get the latest state of switches and update the inventory information every 5 minutes.

For SAN devices, the device credentials are automatically saved after a user discovers a SAN fabric. Users who don’t discover a SAN fabric will need to manually enter credentials in the Nexus Dashboard Manage > Device credentials. The Nexus Dashboard will use the device credentials whenever the user tries to push the SAN configuration changes to the switches. Each user will have their own device credential for a fabric.

note.svg

Certain switches with new organizationally unique IDs (OUIs) are not discovered during the Nexus Dashboard initial SAN discovery process. You can enter the OUI of the switch followed by 'Cisco m' in the Add New OUIs for Discovering Switch, End Device with Format field in Discovery. For example, for a switch with an OUI, 0x70a983, you can enter the value '0x70a983 Cisco m' in the Add New OUIs for Discovering Switch, End Device with Format field and save this information.

Enable AAA remote passthrough

The AAA remote passthrough feature is disabled by default.

Before enabling this feature, ensure that the Nexus Dashboard and switches are configured with the same remote authentication server.

Follow these steps to enable the AAA remote passthrough:

  1. Navigate to Admin > System Settings > Fabric Management > Management.

  2. Check the Enable AAA Passthrough of device credentials checkbox.

  3. Click Save to close the Switch bootstrap page.

  4. Choose Discovery in Advance settings and check the Enable AAA Passthrough feature checkbox.

  5. Choose a value for the auth privacy type in the AAA Passthrough Authentication / Privacy field.

  6. Click Save.

Security

The Security page allows you to view and manage certificates used by Nexus Dashboard. To access the Security page, navigate to Admin > Users and Security > Security.

Use these tabs to configure security in this page:

Platform security and hardening enhancements

Beginning with Nexus Dashboard 4.2.1, security on Nexus Dashboard has been enhanced.

These include:

  • stronger password checks and password expiry

  • user lockout after repeated failed login attempts

  • host list to access management interface

  • SSH enhancements such as idle timeout configuration and enabling or disabling SSH, and

  • audit log enhancements.

Requirement for strong passwords

  • A new security enhancement is now implemented where local users are required to change their password in these situations:

    • When the local user logs into Nexus Dashboard for the first time after they are added to the system

    • If the configuration information for the local user is edited and the Reset password option is enabled through this process:

      • Navigate to Admin > Users and Security > Users.

      • Choose the local user and click Actions > Edit local user.

      • Enable Reset password and click Save.

  • Nexus Dashboard enforces the following enhanced password checks:

    • The username and password cannot be the same.

    • The username cannot be part of the password. This is case insensitive. For example, if the username is Johndoe, then a password like !johnDoe1 is not accepted as it contains the username.

    • The password must include a combination of at least 3 lower case letters, upper case letters, numbers, and special characters. However, the same character cannot be used more than four times in a consecutively.

      Four or more consecutive characters in the English alphabet or the QWERTY keyboard cannot be used in the password. This check for consecutive characters is applicable for both directions (left to right and right to left) in the English alphabet and the English keyboard.

    • The last five passwords cannot be reused. This number can be configured from Violation action > Reuse restriction limit.

      For more information, see the Violation action section in Exploring Your Nexus Dashboard.

  • You can also modify these settings related to password security for Nexus Dashboard:

    • Set the minimum password length

    • Enable enforcement of stricter password checks

    • Set the duration after which a local password expires

User lockout

You can also configure the number of consecutive failed login attempts and the user lockout time. By default, only the Nexus Dashboard GUI user admin and the SSH rescue-user are unlocked after the lockout time.

All other users who are locked out must be unblocked manually. This setting can be modified to allow all GUI users to be unblocked after the timeout.

However, the SSH rescue-user can not be unblocked manually. This user can only be unlocked after the lockout duration expires.

For more information, see the Violation action section in Exploring Your Nexus Dashboard.

Host list to access management interface

Designated IP addresses can be added, removed, and updated in the Nexus Dashboard for administrative terminals. This IP address restriction for management access applies to HTTPS, SSH and Rest APIs.

You can configure a designated list of host IP addresses, the allowed list of hosts, to access the webserver. The SSH user can be accessed through the management IP address.

You can add, remove, or update the list of hosts in the Nexus Dashboard from Admin > Users and the Security > Security menu. This list of hosts can access the webserver and SSH rescue-user on the Nexus Dashboard. By default, all hosts have access privileges, while the configured allowed list restricts access only to configured hosts. The webserver and SSH rescue-user allowed lists are configured independently.

note.svg

This allowed list of hosts is not available to data center interfaces as it may directly interfere with the basic functionality of the system and the management of managed devices.

Webserver security configuration

The Security configuration page allows you to configure authentication session timeouts and security certificates used by your Nexus Dashboard cluster.

Before you begin

  • You must have the keys and certificates you plan to use with Nexus Dashboard already generated.

    Typically, this includes the following files:

    • Private key (nd.key)

    • Certificate Authority’s (CA) public certificate (ca.crt)

    • CA-signed certificate (nd.crt)

    For information about generating these files for self-signed certificates, see the "Generating a private key and self-signed certificate" section in Managing Certificates in your Nexus Dashboard.

  • We recommend creating a configuration backup of your Nexus Dashboard cluster before making changes to the security configurations.

    For more information about backups, see "Backup and Restore" in Backing Up and Restoring Your Nexus Dashboard.

To edit security configuration:

  1. Edit security configuration.

    1. From the main navigation menu, select Admin > Users and Security.

    2. Click the Security tab.

    3. In the main pane, click the Security configuration tab.

    4. In the main pane, click the Edit icon.

  2. In the Edit security configuration screen that opens, update one or more fields as required:

    note.svg

    You need to paste the information in the following fields since uploading the keys and certificate files is not supported.

    1. Update the Session timeout.

      Specifies the duration for all HTTP sessions (GUI and API) with the default duration set to 20 minutes.

    2. In the Domain name field, provide your domain.

    3. Check the box in the Minimum TSL version: TLSV1.3 field if you want to set the minimum SSL version to TLSV1.3.

      The minimum SSL version is set to TLSV1.2 by default. Checking this box to set the minimum version to TLSV1.3 will reject all clients using a TLSV1.2 connection request.

    4. To disable Qualtrics integration from the browser at a system wide level, check the box in the Enforce strict content security policy field.

    5. Click the SSL Ciphers field and select any additional cipher suites you want to enable from the dropdown or click the x icon on an existing cipher suite to remove it.

      Cipher suites define agorithms (such as key exchange, bulk encryption, and message authentication code) used to secure a network connection. This field allows you to customize which cipher suites your Nexus Dashboard cluster will use for network communication and disable any undesired suites, such as the less secure TLS1.2 and TLS1.3.

  1. In the Key field, provide your private key.

  2. In the RSA Certificate field, provide the CA-signed or self-signed certificate.

  3. In the Root Certificate field, provide the CA’s public certificate.

  4. (Optional) If your CA provided an Intermediate Certificate, provide it in the Intermediate Certificate field.

  5. Click Save to save the changes. Add Allowed Subnet content is not added in the Webserver security configuration tab.

    After you save your changes, the GUI will reload using the new settings.

SSH configuration

The SSH configuration page shows:

  • the session idle timeout which can be pre-configured in Nexus Dashboard to 1800 seconds. SSH sessions connected to the management interface (SSH rescue-user) exceeding this idle timeout duration will be terminated.

  • the option to enable or disable SSH on the management interface on Nexus Dashboard. SSH cannot be disabled for the data center interfaces.

    • The service port 22 on the management interface is closed when the SSH service is disabled.

Follow these steps to edit the information provided in the SSH configuration page.

  1. From the main navigation menu, select Admin > Users and Security.

  2. Click the Security tab.

  3. In the main pane, click the SSH configuration tab.

    The current settings for these login actions are displayed in the Management and Data interfaces SSH configurations area.

    • Data center interface SSH configuration

      • Ciphers

      • Host key algorithms

      • MACs

      • Key Exchange algorithms

    • Management interface SSH configuration

      • Session timeout (seconds)

      • Ciphers

      • Host key algorithms

      • SSH connection

      • MACs

    • Key Exchange algorithms

  4. If you want to change any of the above settings, click Edit.

  5. To configure allowed subnet, click Add allowed subnet and specify the IPv4 or IPv6 address and mask.

  6. Click Save.

Violation action

The Violation action page shows the number of unsuccessful attempted login actions. The login actions that you configure through the Violation action page apply to actions and users that are configured through the Webserver security configuration and SSH configuration pages.

To edit the information that is provided in the Violation action page:

  1. From the main navigation menu, select Admin > Users and Security.

  2. Click the Security tab.

  3. In the main pane, click the Violation action tab.

    The current settings for these login actions are displayed in the Login action area.

    • Maximum failed login attempts

    • Duration unlock

    • Lock duration for general user

    • Lock duration for UI admin user and SSH rescue user

    • Minimum password length

    • Strong password check

    • Reuse restriction limit

    • Password expiry duration

  4. If you want to change the settings for any of these login actions, click Edit.

    The Login action page appears.

  5. Change the settings in any of these login actions, if necessary.

    Field Description

    Maximum login attempts

    Set the maximum number of login attempts in the Count field until the violation action is triggered.

    The default entry is 0, which represents unlimited login attempts.

    Number of failed attempts before user is locked out

    Set the violation action if the maximum number of login attempts is reached in the Lock for a configured duration field, where a locked login is unlocked after a certain duration or through a default admin user-assisted unlock. The default admin user and SSH rescue user is subjected to a duration-based unlock only.

    • OFF (the default setting): With this setting, only the admin user and SSH rescue user has a duration-based unlock.

      • In the Lock duration for UI admin user and SSH rescue user area, set the amount of time, in seconds, minutes, or hours, that a login block will take place for an admin user and SSH rescue user when the number of maximum login attempts has been surpassed. Default entry for this field is 300 seconds.

        When the violation action is triggered based on the maximum number of login attempts set in the Maximum login attempts area, the admin user and SSH rescue user has a duration-based unlock, where they are locked out for the duration set in the Lock duration for UI admin user and SSH rescue user.

      • All users other than the admin/SSH rescue user (in other words, general users) do not have a duration-based unlock and must be unlocked manually only by users with a super-admin role. Users with roles other than a super-admin role cannot unlock users that are locked out.

    • ON: With this setting, both the admin/SSH rescue user and any other (general) users have a duration-based unlock.

      • In the Lock duration for UI admin user and SSH rescue user area, set the amount of time, in seconds, minutes, or hours, that a login block will take place for an admin user and SSH rescue user when the number of maximum login attempts has been surpassed. Default entry for this field is 300 seconds.

        When the violation action is triggered based on the maximum number of login attempts set in the Maximum login attempts area, the admin user and SSH rescue user has a duration-based unlock, where they are locked out for the duration set in the Lock duration for UI admin user and SSH rescue user.

      • In the Lock duration for general user area, set the amount of time, in seconds, minutes, or hours, that a login block will take place for a general user when the number of maximum login attempts has been surpassed. Default entry for this field is 1200 seconds.

        When the violation action is triggered based on the maximum number of login attempts set in the Maximum login attempts area, the general user has a duration-based unlock, where they are locked out for the duration set in the Lock duration for general user.

    Minimum password length

    Set the minimum password length in the Length field. Default entry is 8.

    Strong password check

    Set the strong password check enforcement.

    • Disabled (the default setting): Strong password check enforcement is not enforced.

    • Enabled: Strong password check enforcement is enforced.

    Reuse restriction limit

    Prevents the reuse of a certain number of last-used passwords.

    Enter the number of last-used passwords that can be reused in the Count field.

    • A reuse limitation of 1 only blocks reusing the current password.

    • Default entry is 5.

    Password expiry

    Specifies the time duration in days after which a local user password expires, which requires the user to change the password before logging in.

    Enter a value in the Password expiry duration (days) field. A value of 0 indicates that the password expiry is not enabled. Default entry is 0.

  6. Click Save.

Security domains

A restricted security domain allows an administrator to prevent a group of users from viewing or modifying any objects created by a group of users in a different security domain, even when users in both groups have the same assigned privileges.

For example, an administrator in restricted security domain (domain1) will not be able to see fabrics, services, cluster or user configurations in another security domain (domain2).

Note that a user will always have read-only visibility to system-created configurations for which the user has proper privileges. A user in a restricted security domain can be given a broad level of privileges within that domain without the concern that the user could inadvertently affect another group’s physical environment.

To create a security domain:

  1. Create a new security domain.

    1. From the main navigation menu, select Admin > Users and Security.

    2. Click the Security tab.

    3. In the main pane, click the Security domains tab.

    4. In the main pane, click Create security domain.

  2. In the Create security domain screen that opens, provide the domain details.

    1. Provide the Name for the domain.

    2. (Optional) Provide a description for the domain.

    3. Click Save to save the domain.

JWT keys

To create a JWT key:

  1. From the main navigation menu, select Admin > Users and Security.

  2. Click the Security tab.

  3. In the main pane, click the JWT keys tab.

  4. Click Create JWT key.

    The Create JWT key page appears.

  5. Enter a service name for the JWT key in the Service name field.

  6. Enter a JWT API key in the JWT API key field.

  7. Enter a JWT public key in the JWT public key field.

  8. Enter the remote ID claim information in the Remote ID claim field.

  9. Click Create.

Credentials store

You can add an external Credentials store that allows you to store and retrieve network credentials from an external vault, such as the CyberArk vault, instead of a local storage system.

To add a credentials store:

  1. From the main navigation menu, select Admin > Users and Security.

  2. Click the Security tab.

  3. In the main pane, click the Credentials store tab.

  4. Click Add credential store.

    The Edit credential store page appears.

  5. In the Store type field, choose a store type, such as CyberArk.

  6. Enter the necessary information in the remaining fields, depending on the choice that you made in the Store type field.

    For example, if you chose CyberArk in the Store type field, make the necessary choices in the following fields:

    • In the CyberArk CCP URL field, enter the CyberArk Central Credential Provider (CCP) URL.

      For more information, see Central Credential Provider (CCP).

    • In the Certificate name field, choose the appropriate certificate from the dropdown list.

      The Certificate name field lists the certificates that you configured in Admin > Certificate Management.

      note.svg

      Ensure that the system certificate you configured is mapped to the CyberArk feature to use the certificate name here.

      For more information on system certificates, see Managing Certificates in your Nexus Dashboard.

  7. Click Resync/Save.

    note.svg

    If there is a password change in CyberArk, whether automatically or manually, Nexus Dashboard will require approximately 10 minutes to reflect the updated password. To retrieve the updated password, navigate to the Credential Store and perform a Resync.

Validate peer certificates

You can import a fabric controller’s Certificate Authority (CA) root certificate chain into Nexus Dashboard. This allows you to verify that the certificates of hosts to which your Nexus Dashboard connects (such as fabric controllers) are valid and are signed by a trusted Certificate Authority (CA) when you add the fabrics.

Export a certificate chain from Cisco APIC

  1. Log in to your Cisco APIC.

  2. Check which key ring is being used for management access:

    503127.jpg

    1. In the top navigation bar, choose Fabric > Fabric Policies.

    2. In the left navigation menu, choose Policies > Pod> Management Access.

    3. In the main pane, note the name in the Admin KeyRing field.

      In the above example, the default key ring is being used. However, if you created a custom key ring with a custom certificate chain, the name of that key ring would be listed in the Admin KeyRing field.

      Custom security configuration for Cisco APIC is described in detail in Cisco APIC Security Configuration Guide for your release.

  3. Export the certificate used by the key ring:

    503967.jpg

    1. In the top navigation bar, choose Admin > AAA.

    2. In the left navigation menu, choose Security.

    3. In the main pane, choose the Key Rings tab.

    4. Click the name of the key ring you found in the previous step and copy the Certificate.

      The above example shows the default key ring from the previous step. However, if you had a custom key ring configured, choose the CA certificate chain used to create the key ring.

      You must include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- in the text you copy, for example:

      -----BEGIN CERTIFICATE-----
MIIDQzCCAiugAwIBAgIUWrvhVTKdEKTbLc7vB+oiqXQz3HcwDQYJKoZIhvcNAQEN
[...]
-----END CERTIFICATE-----

Import certificates into Nexus Dashboard

  1. Log in to your Nexus Dashboard where you plan to onboard the fabrics.

  2. Import the certificate into Nexus Dashboard.

    1. Log in to your Nexus Dashboard where you will onboard the fabrics.

    2. From the main navigation menu, select Admin > Certificate Management.

    3. Click the CA Certificates tab.

    4. Click Add CA certificate, provide a unique name for the certificate, and paste the certificate chain you copied from your fabric’s controller.

  3. Proceed with adding the fabric as you typically would, but enable the Verify Peer Certificate option.

    Note that if you enable the Verify Peer Certificate option but don’t import the valid certificate, fabric onboarding will fail.

    Adding fabrics is described in Creating Fabrics and Fabric Groups.

Login banner

A super-admin user can modify the text that appears in the lower left corner on the login page. This can be done to announce planned outages, to share important system messages, or to show a legal disclaimer.

login-banner.jpg

To modify the text that appears when you log into your Nexus Dashboard:

  1. From the main navigation menu, click Admin > Users and Security.

  2. Click Login banner.

    The text that currently appears when you log into your Nexus Dashboard is shown in the Login banner area.

  3. Click Edit.

  4. Change the text that is currently used in the login banner, then click Save.

You will now see the new login banner text the next time you log into your Nexus Dashboard.

Add a proxy server

In certain deployment scenarios, you may have to access the Internet through a proxy.

Note that Nexus Dashboard uses two main route tables — one for the Management network and one for the Data network — and by default, it will use the routing table of the originating IP address. In other words, Nexus Dashboard will attempt to reach the proxy from the routing table of the POD/Service that is trying to use the proxy.

For example, if you configure a proxy and establish Intersight connectivity from your Nexus Dashboard and then attempt to configure the AppDynamics integration from the Insights service running in the cluster, you may get an error stating that the AppDynamics host is not reachable. This happens because the proxy is only accessible from the management interface, so in such cases you also need to add a management network route for the proxy IP address.

To add a proxy server:

  1. Navigate to Admin > System Settings > General.

  2. In the Proxy configuration area, click Edit.

  3. Click + Add HTTP Server in the proxy configuration window.

  4. From the Type dropdown, select the type of traffic that you want to be proxied.

  5. In the Server field, provide the full address for the proxy server, including the port if required.

    For example http://proxy.company.com:80.

  6. If the server requires login credentials, provide the Username and Password.

  7. (Optional) Click + Add Ignore Host to provide any hosts that will ignore the proxy.

    You can add one or more hosts with which the cluster will communicate directly bypassing the proxy.

Copyright

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

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.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

© 2017-2026 Cisco Systems, Inc. All rights reserved.

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
https://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883

Need help?