PDF

Remote users

Want to summarize with AI?

Log in

Describes users who authenticate through external authentication providers instead of local user configuration.


A remote user is an authentication method that

  • enables the APIC to point at centralized enterprise credential datacenters instead of configuring local users,

  • supports multiple protocols including Lightweight Directory Access Protocol (LDAP), active directory, RADIUS, and TACACS+, and

  • provides server monitoring capabilities starting with the 3.1(1) release to determine whether AAA servers are alive.

Remote user authentication requirements

To configure a remote user authenticated through an external authentication provider, you must meet these prerequisites:

  • The DNS configuration should have already been resolved with the hostname of the RADIUS server.

  • You must configure the management subnet.

Note

When an APIC is in minority (disconnected from the cluster), remote logins can fail because the ACI is a distributed system and the user information is distributed across APICS. Local logins, however, continue to work because they are local to the APIC.

Server monitoring can be configured through RADIUS, TACACS+, LDAP, and RSA to determine whether the respective AAA servers are alive. Server monitoring feature uses the respective protocol login to check for server aliveness. For example, a LDAP server will use LDAP login and a RADIUS server will use RADIUS login with server monitoring to determine server aliveness.


AV pairs on external authentication servers

An AV pair on an external authentication server is a configuration mechanism that

  • specifies the APIC required RBAC roles and privileges for the user

  • uses the same format for RADIUS, LDAP, or TACACS+, and

  • is configured by adding a Cisco AV pair to the existing user record on the external authentication server.

AV pair configuration details

The Cisco APIC requires that an administrator configure a Cisco AV Pair on an external authentication server. To configure a Cisco AV Pair on an external authentication server, an administrator adds a Cisco AV pair to the existing user record.

The Cisco AV pair format is as follows:

shell:domains = 
domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,
domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2
shell:domains = 
domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,
domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2(16003)

Starting with Cisco APIC release 2.1, if no UNIX ID is provided in AV Pair, the APIC allocates the unique UNIX user ID internally.

Starting with release 3.1(x), the AV Pair shell:domains=all//admin allows you to assign Read-only privileges to users and provide them access to the switches and run commands.

The APIC supports these regexes:

shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})(\\(\\d+\\))$
shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})$
Note

The APIC Cisco AV-pair format is compatible and can co-exist with other Cisco AV-pair formats. APIC will pick up the first matching AV-pair from all the AV-pairs.

Note

The "/" character is a separator between writeRoles and readRoles per Security domain and is required even if only one type of role is to be used.

The Cisco AVpair string is case sensitive. Although a fault may not be seen, using mismatching cases for the domain name or roles could lead to unexpected privileges being given.

AV pair configuration examples

These examples show different AV pair configurations:

  • Example 1: A Cisco AV Pair that contains a single Security domain with only writeRoles:

    shell:domains=domainA/writeRole1|writeRole2/
  • Example 2: A Cisco AV Pair that contains a single Security domain with only readRoles:

    shell:domains=domainA//readRole1|readRole2
An example configuration for an open RADIUS server (/etc/raddb/users) is as follows:
aaa-network-admin Cleartext-Password := "<password>"
Cisco-avpair = "shell:domains = all/aaa/read-all(16001)"

Configure an AV pair on the external authentication server

Configure an AV pair on the external authentication server to define user authentication parameters and domain access privileges for SSH or telnet login sessions.

The numerical value within the parentheses in the attribute/value (AV) pair string is used as the UNIX user ID of the user who is logged in using Secure Shell (SSH) or telnet.

Note

Beginning with the 6.0(2) release, telnet is not supported.

Procedure

Configure an AV pair on the external authentication server.

The Cisco AV pair definition is as follows (Cisco supports AV pairs with and without UNIX user IDs specified):

Example:

shell:domains = domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2
shell:domains = domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2(8101)

These are the boost regexes supported by APIC:
uid_regex("shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})(\\(\\d+\\))$");
regex("shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})$");

The following is an example:

shell:domains = coke/tenant-admin/read-all,pepsi//read-all(16001)
Note

ACI users have limited access to APIC nodes. After you login to APIC using the CLI, you stay in a restricted sandbox with limited privileges. As an ACI user, you get your own home directory /home/$user and a /tmp directory. The mounted /tmp directory for a user is different from /tmp directory of the main system. You can create files only under these directories, you cannot create and delete files in any other directory. Also, you cannot delete files created by other users. Users also have restrictions regarding CPU, memory usages and FDs. Read-only users cannot create, update, or delete any configuration data.

The AV pair is configured on the external authentication server with the specified domain access and user privileges.


Configure APIC for TACACS+ access

This task enables TACACS+ authentication for user access to the APIC.

TACACS+ provides centralized authentication, authorization, and accounting services for network access. This configuration is essential for enterprise environments that require secure, centralized user management.

Before you begin

  • The Cisco Application Centric Infrastructure (ACI) fabric is installed, Application Policy Infrastructure Controllers (APICs) are online, and the APIC cluster is formed and healthy.

  • The TACACS+ server host name or IP address, port, and key are available.

  • The APIC management endpoint group is available.

Procedure

  1. In the APIC, create the TACACS+ Provider.

    For configuring a TACACS+ provider, see Create a provider.

    For toggling in-band or out-of-band management in the APIC GUI:

    In the Navigation pane, choose System > System Settings > APIC Connectivity Preferences. In the Work Pane select either inband or ooband.

  2. Create the Login Domain for TACACS+.

    For the detailed procedure, see Create login domain using the GUI.

The APIC is now configured for TACACS+ authentication with the provider and login domain created.

What to do next

This completes the APIC TACACS+ configuration steps. Next, if a RAIDUS server will also be used, configure the APIC for RADIUS. If only a TACACS+ server will be used, go to the ACS server configuration topic below.


Configure APIC for RADIUS access

Configure APIC for RADIUS access to enable centralized authentication and authorization for user access to the APIC.

This configuration allows the APIC to authenticate users against a RADIUS server, providing centralized user management and enhanced security for the ACI fabric.

Before you begin

  • The ACI fabric is installed, Application Policy Infrastructure Controllers (APICs) are online, and the APIC cluster is formed and healthy.

  • The RADIUS server host name or IP address, port, authorization protocol, and key are available.

  • The APIC management endpoint group is available.

Procedure

  1. In the APIC, create the RADIUS provider.

    For configuring a RADIUS provider, see Create a provider.

    For toggling in-band or out-of-band management in the APIC GUI:

    In the Navigation pane, choose System > System Settings > APIC Connectivity Preferences. In the Work Pane select either inband or ooband.

  2. Create the Login Domain for RADIUS.

    For the detailed procedure, see Create login domain using the GUI.

The APIC is now configured for RADIUS access with the necessary provider and login domain created.

What to do next

This completes the APIC RADIUS configuration steps. Next, configure the RADIUS server.


Configure a Cisco Secure Access Control Server for RADIUS and TACACS+ access to the APIC

This task configures a Cisco Secure Access Control Server to provide centralized authentication and authorization services for users accessing the APIC through RADIUS and TACACS+ protocols.

The Cisco Secure Access Control Server (ACS) provides centralized authentication, authorization, and accounting (AAA) services. When configured properly, it allows you to control user access to the APIC and assign appropriate role-based access control (RBAC) privileges based on user identity groups.

Before you begin

  • The Cisco Secure Access Control Server (ACS) version 5.5 is installed and online.

    Note

    ACS v5.5 was used to document these steps. Other versions of ACS might support this task but the GUI procedures might vary accordingly.

  • The Cisco Application Policy Infrastructure Controller (Cisco APIC) RADIUS or TACACS+ keys are available (or keys for both if both will be configured).

  • The APICs are installed and online; the APIC cluster is formed and healthy.

  • The RADIUS or TACACS+ port, authorization protocol, and key are available.

Follow these steps to configure a Cisco Secure Access Control Server for RADIUS and TACACS+ access to the APIC:

Procedure

  1. Log in to the ACS server to configure the APIC as a client.

    1. Navigate to Network Resources > Network Devices Groups > Network Devices and AAA Clients.
    2. Specify the client name, the APIC in-band IP address, select the TACACS+ or RADIUS (or both) authentication options.
      Note

      If the only RADIUS or TACACS+ authentication is needed, select only the needed option.

    3. Specify the authentication details such as Shared Secret (key), and port as appropriate for the authentication option(s).
      Note

      The Shared Secret(s) must match the APIC Provider key(s).

  2. Create the Identity Group.

    1. Navigate to Users and Identity Stores > Internal Groups option.
    2. Specify the Name, and Parent Group as appropriate.
  3. Map users to the Identity Group.

    1. In the Navigation pane, click the Users and Identity Stores > Internal Identity Stores > Users option.
    2. Specify the user Name, and Identity Group as appropriate.
  4. Create the Policy Element.

    1. Navigate to the Policy Elements option.
    2. For RADIUS, specify the Authorization and Permissions > Network Access > Authorization Profiles Name. For TACACS+, specify the Authorization and Permissions > Device Administration > Shell Profile Name as appropriate.
    3. For RADIUS, specify the Attribute as cisco-av-pair , Type as string, and the Value as shell:domains = <domain>/<role>/,<domain>//role as appropriate. For TACACS+, specify the Attribute as cisco-av-pair , Requirement as Mandatory, and the Value as shell:domains = <domain>/<role>/,<domain>//role as appropriate.

      The syntax of the Value field determines whether write privileges are granted:

      • For read/write privileges, the syntax is shell:domains = <domain>/<role>/ .

      • For read-only privileges, the syntax is shell:domains = <domain>// <role> .

      For example, if the cisco-av-pair has a value of shell:domains = solar/admin/,common// read-ALL , then solar is the security domain, admin is the role that gives write privileges to this user in the security domain called solar , common is the tenant common, and read-ALL is the role with read privileges that gives this user read privileges to ALL of the tenant common.

  5. Create a service selection rule.

    1. For RADIUS, create a service selection rule to associate the Identity Group with the Policy Element by navigating to Access Policies > Default Device Network Access Identity > Authorization and specifying the rule Name, Status, and Conditions as appropriate, and Add the Internal Users:UserIdentityGroup in ALL Groups:<identity group name> .
    2. For TACACS+, create a service selection rule to associate the Identity Group with the Shell Profile by navigating to Access Policies > Default Device Admin Identity > Authorization. Specify the rule Name, Conditions, and Select the Shell Profile as appropriate.

The Cisco Secure Access Control Server is now configured to provide RADIUS and TACACS+ authentication and authorization for users accessing the APIC. Users can now authenticate using their configured credentials and will receive appropriate access privileges based on their assigned identity groups and roles.

What to do next

Use the newly created RADIUS and TACACS+ users to log in to the APIC. Verify that the users have access to the correct APIC security domain according to the assigned RBAC roles and privileges. The users should not have access to items that have not been explicitly permitted. Read and write access rights should match those configured for that user.