Use the Manage Users screen to add, edit, or delete users and user groups from the vManage NMS.

Only a user logged in as the admin user or a user who has Manage Users write permission can add, edit, or delete users and user groups from the vManage NMS.

Add a User

To perform operations on a device, you configure usernames and passwords for users who are allowed to access the device. The Cisco SD-WAN software provides one standard username, admin, and you can create custom usernames, as needed. We recommend that you configure strong passwords for users.

To add a user:

1. In the Users tab, click Add User.

2. In the Add User popup window, enter the full name, username, and password for the user. Note that uppercase characters are not allowed in usernames.

3. From the User Groups drop-down list, select the groups that the user will be a member of.

4. Click Add. The user is then listed in the user table.

Delete a User

If a user no longer needs access to devices, you can delete the user. When you delete a user, that user no longer has access to the device. Deleting a user does not force log out the user if the user is logged in.

To delete a user:

1. In the Users tab, select the user you wish to delete.

2. Click the More Actions icon to the right of the column and click Delete.

3. Click OK to confirm deletion of the user.

Edit User Details

Editing user details lets you update login information for a user, and add or remove a user from a user group. If you edit details for a user who is logged in, the changes take effect after the user logs out.

To edit user details:

1. In the Users tab, select the user whose details you wish to edit.

2. Click the More Actions icon to the right of the column and click Edit.

3. Edit login details, and add or remove the user from user groups.

4. Click Update.

Change User Password

You can update passwords for users as needed. We recommend that you use strong passwords.

To change a password for a user:

1. In the Users tab, select the user whose password you wish to change.

2. Click the More Actions icon to the right of the column and click Change Password.

3. Enter, and then confirm, the new password. Note that the user, if logged in, is logged out.

4. Click Done.

You can use the CLI to configure user credentials on each edge device. In this way, you can create additional users to give them access specific devices. The credentials that you create for a user by using the CLI can be different than the vManage credentials for the user, and you can create different credentials for a user on each device. Any user with the netadmin privilege can create a new user.

To create a user account, configure the username and password, and place the user into a group:

vEdge(config)# system aaa
vEdge(config)# user username password  password
vEdge(config-aaa)# group group-name

username can be 1 to 128 characters long, and it must start with a letter. The name can contain only lowercase letters, the digits 0 through 9, hyphens (-), underscores (_), and periods (.). The name cannot contain any uppercase letters. Some usernames are reserved, so you cannot configure them. For a list of them, see the aaa configuration command.

password is the password for the user. Each username must have a password, and each user is allowed to change their own password. The CLI immediately encrypts the string and never displays a readable version of the password. When a user is logging in to the Cisco vEdge device , they have five chances to enter the correct password. After the fifth incorrect attempt, the user is locked out of the device, and they must wait 15 minutes before attempting to log in again.

group-name is the name of one of the standard Cisco SD-WAN groups (basic, netadmin, or operator) or of a group configured with the usergroup command (discussed below). If an admin user changes the permission of a user by changing their group, and if that user is currently logged in to the device, the user is logged out and must log back in again.

The factory-default password for the admin username is admin. It is strongly recommended that you modify this password the first time you configure a Cisco vEdge device .

vEdge(config)# system aaa admin password  password

Configure the password as an ASCII string. The CLI immediately encrypts the string and never displays a readable version of the password. For example:

vEdge(config-user-admin)# show config
system
 aaa
  user admin
   password $1$xULc8yYH$k71cTjvKESmeIGgImNDaC.
  !
  user eve
   password $1$8z3q4qoU$F6DMBr9vPBF0s/sl45ax5.
   group    basic
  !
 !
!

If you are using RADIUS to perform AAA authentication, you can configure a specific RADIUS server to use to verify the password:

vEdge(config)# system aaa radius-servers tag

tag is a string that you defined with the radius server tag command, as described below.

Users are placed in groups, which define the specific configuration and operational commands that the users are authorized to view and modify. A single user can be in one or more groups. The Cisco SD-WAN software provides three standard user groups, and you can create custom user groups, as needed:

• basic—Includes users who have permission to view interface and system information.

• netadmin—Includes the admin user, by default, who can perform all operations on the vManage NMS. You can add other users to this group.

• operator—Includes users who have permission only to view information.

To add a user group:

1. In the User Groups tab, click Add User Group.

2. In the Add User Group popup window, enter the user group name and select the desired read and write permissions for each feature. Note that uppercase characters are not allowed in user group names.

3. Click OK. The user group is then listed in the left pane.

Each user group can have read or write permission for the features listed below. Write permission includes read permission.

Note: All user groups, regardless of the read or write permissions selected, can view the information displayed in the vManage Dashboard screen.

Delete a User Group

You can delete a user group when it is no longer needed. For examle, you might delete a user group that you created for a specific project when that project ends.

1. In the User Groups tab, click the name of the user group you wish to delete. Note that you cannot delete any of the three standard user groups—basic, netadmin, and operator.

2. Click the Trash icon.

3. Click OK to confirm deletion of the user group.

Edit User Group Privileges

You can edit group privileges for an existing user group. This procedure lets you change configured feature read and write permissions for the user group needed.

1. In the User Groups tab, select the name of the user group whose privileges you wish to edit. Note that you cannot edit privileges for the three standard user groups—basic, netadmin, and operator.

2. Click the Edit button located directly above the privilege level table, and edit privileges as needed.

3. Click Save.

If an admin user changes the privileges of a user by changing their group, and if that user is currently logged in to the device, the user is logged out and must log back in again.

The Cisco SD-WAN software provides three fixed group names: basic, netadmin, and operator. The username admin is automatically placed in the netadmin usergroup.

If needed, you can create additional custom groups and configure privilege roles that the group members have. To create a custom group with specific authorization, configure the group name and privileges:

vEdge(config)# system  aaa usergroup group-name task privilege 

group-name can be 1 to 128 characters long, and it must start with a letter. The name can contain only lowercase letters, the digits 0 through 9, hyphens (-), underscores (_), and periods (.). The name cannot contain any uppercase letters Some group names are reserved, so you cannot configure them. For a list of them, see the aaa configuration command.

If a remote RADIUS or TACACS+ server validates authentication but does not specify a user group, the user is placed into the user group basic. If a remote server validates authentication and specifies a user group (say, X) using VSA Cisco SD-WAN-Group-Name, the user is placed into that user group only. However, if that user is also configured locally and belongs to a user group (say, Y), the user is placed into both the groups (X and Y).

In the task option, list the privilege roles that the group members have. The role can be one or more of the following: interface, policy, routing, security, and system.

In the following example, the basic user group has full access to the system and interface portions of the configuration and operational commands, and the operator user group can use all operational commands but can make no modifications to the configuration:

vEdge# show running-config system aaa
system
 aaa
  usergroup basic
   task system read write
   task interface read write
  !
  usergroup operator
   task system read
   task interface read
   task policy read
   task routing read
   task security read
  !
  user admin
   password $1$tokPB7tf$vchR2JI9Sw1/dqgkqup9S.
  !
 !
!

The Remote Authentication Dial-In User Service (RADIUS) is a distributed client/server system that secures networks against unauthorized access. RADIUS clients run on supported Cisco devices and send authentication requests to a central RADIUS server, which contains all user authentication and network service access information.

To have a Cisco vEdge device use RADIUS servers for user authentication, configure one or up to 8 servers:

vEdge(config)#  system radius
vEdge(config-radius)# server  ip-address
vEdge(config-server)# secret-key  password
vEdge(config-server)# priority number
​vEdge(config-server)# auth-port  port-number
vEdge(config-server#) acct-port port-number
vEdge(config-server)# source-interface interface-name
vEdge(config-server)# ​​​​​​​tag tag
vEdge(config-server)# vpn vpn-id

For each RADIUS server, you must configure, at a minimum, its IP address and a password, or key. You can specify the key as a clear text string up to 32 characters long or as an AES 128-bit encrypted key. The local device passes the key to the RADIUS server. The password must match the one used on the server. To configure more than one RADIUS server, include the server and secret-key commands for each server.

The remaining RADIUS configuration parameters are optional.

To set the priority of a RADIUS server, as a means of choosing or load balancing among multiple RADIUS servers, set a priority value for the server. The priority can be a value from 0 through 7. A server with a lower priority number is given priority over one with a higher number.

By default, the Cisco vEdge device uses port 1812 for authentication connections to the RADIUS server and port 1813 for accounting connections. To change these port numbers, use the auth-port and acct-port commands.

If the RADIUS server is reachable via a specific interface, configure that interface with the source-interface command.

You can tag RADIUS servers so that a specific server or servers can be used for AAA, IEEE 802.1X, and IEEE 802.11i authentication and accounting. Define the tag here, with a string from 4 to 16 characters long. Then associate the tag with the radius-servers command when you configure AAA, and when you configure interfaces for 802.1X and 802.11i.

If the RADIUS server is located in a different VPN from the Cisco vEdge device , configure the server's VPN number so that the Cisco vEdge device can locate it. If you configure multiple RADIUS servers, they must all be in the same VPN.

When a Cisco vEdge device is trying to locate a RADIUS server, it goes through the list of servers three times. To change this behavior, use the retransmit command, setting the number to a value from 1 to 1000:

vEdge(config-radius)# retransmit  number

When waiting for a reply from the RADIUS server, a Cisco vEdge device waits 3 seconds before retransmitting its request. To change this time interval, use the timeout command, setting a value from 1 to 1000 seconds:

vEdge(config-radius)# timeout  seconds

Restrictions for SSH Authentication on Cisco SD-WAN

• The range of SSH RSA key size supported by Cisco vEdge devices is from 2048 to 4096. SSH RSA key size of 1024and 8192 are not supported.

• A maximum of 10 keys are required on Cisco vEdge devices.

The authentication order dictates the order in which authentication methods are tried when verifying user access to a Cisco vEdge device through an SSH session or a console port. The default authentication order is local, then radius, and then tacacs. With the default authentication order, the authentication process occurs in the following sequence:

• The authentication process first checks whether a username and matching password are present in the running configuration on the local device.

• If local authentication fails, and if you have not configured authentication fallback (with the auth-fallback command), the authentication process stops. However, if you have configured authentication fallback, the authentication process next checks the RADIUS server. For this method to work, you must configure one or more RADIUS servers with the system radius server command. If a RADIUS server is reachable, the user is authenticated or denied access based on that server's RADIUS database. If a RADIUS server is unreachable and if you have configured multiple RADIUS servers, the authentication process checks each server sequentially, stopping when it is able to reach one of them. The user is then authenticated or denied access based on that server's RADIUS database.

• If the RADIUS server is unreachable (or all the servers are unreachable), the authentication process checks the TACACS+ server. For this method to work, you must configure one or more TACACS+ servers with the system tacacs server command. If a TACACS+ server is reachable, the user is authenticated or denied access based on that server's TACACS+ database. If a TACACS+ server is unreachable and if you have configured multiple TACACS+ servers, the authentication process checks each server sequentially, stopping when it is able to reach one of them. The user is then authenticated or denied access based on that server's TACACS+ database.

• If the TACACS+ server is unreachable (or all TACACS+ servers are unreachable), user access to the local Cisco vEdge device device is denied.

To modify the default order, use the auth-order command:

vEdge(config-system-aaa)#  auth-order  (local | radius | tacacs)

Specify one, two, or three authentication methods in the preferred order, starting with the one to be tried first. If you configure only one authentication method, it must be local.

To have the "admin" user use the authentication order configured in the auth-order command, use the following command:

vEdge(config-system-aaa)# admin-auth-order

If you do not include this command, the "admin" user is always authenticated locally.

You can configure authentication to fall back to a secondary or tertiary authentication mechanism when the higher-priority authentication method fails to authenticate a user, either because the user has entered invalid credentials or because the authentication server is unreachable (or all the servers are unreachable):

vEdge(config-system-aaa)#  auth-fallback 

Fallback to a secondary or tertiary authentication mechanism happens when the higher-priority authentication server fails to authenticate a user, either because the credentials provided by the user are invalid or because the server is unreachable.

The following examples illustrate the default authentication behavior and the behavior when authentication fallback is enabled:

• If the authentication order is configured as radius local:

  • With the default authentication, local authentication is used only when all RADIUS servers are unreachable. If an authentication attempt via a RADIUS server fails, the user is not allowed to log in even if they have provided the correct credentials for local authentication.

  • With authentication fallback enabled, local authentication is used when all RADIUS servers are unreachable or when a RADIUS server denies access to a user.

• If the authentication order is configured as local radius:

  • With the default authentication, RADIUS authentication is tried when a username and matching password are not present in the running configuration on the local device.

  • With authentication fallback enabled, RADIUS authentication is tried when a username and matching password are not present in the running configuration on the local device. In this case, the behavior of two authentication methods is identical.

• If the authentication order is configured as radius tacacs local:

  • With the default authentication, TACACS+ is tried only when all RADIUS servers are unreachable, and local authentication is tried only when all TACACS+ servers are unreachable. If an authentication attempt via a RADIUS server fails, the user is not allowed to log in even if they have provided the correct credentials for the TACACS+ server. Similarly, if a TACACS+ server denies access, the user cannot log via local authentication.

  • With authentication fallback enabled, TACACS+ authentication is used when all RADIUS servers are unreachable or when a RADIUS server denies access a user. Local authentication is used next, when all TACACS+ servers are unreachable or when a TACACS+ server denies access to a user.

If a remote server validates authentication but does not specify a user group, the user is placed into the user group basic.

If a remote server validates authentication and specifies a user group (say, X), the user is placed into that user group only. However, if that user is also configured locally and belongs to a user group (say, Y), the user is placed into both the groups (X and Y).

If a remote server validates authentication and that user is not configured locally, the user is logged in to the vshell as the user basic, with a home directory of /home/basic.

If a remote server validates authentication and that user is configured locally, the user is logged in to the vshell under their local username (say, eve) with a home direction of /home/username (so, /home/eve).

For RADIUS and TACACS+, you can configure Network Access Server (NAS) attributes for user authentication and authorization. To do this, you create a vendor-specific attributes (VSA) file, also called a RADIUS dictionary or a TACACS+ dictionary, on the RADIUS or TACACS+ server that contains the desired permit and deny commands for each user. The Cisco vEdge device retrieves this information from the RADIUS or TACACS+ server.

The VSA file must be named dictionary.viptela, and it must contain text in the following format:

localhost$ more dictionary.viptela
 # -*- text -*-
#
#  dictionary.viptela
#
#
# Version:      $Id$
#
 
VENDOR          Viptela                         41916
 
BEGIN-VENDOR    Viptela
 
ATTRIBUTE       Viptela-Group-Name              1    string

The Cisco SD-WAN software has three predefined user groups, as described above: basic, netadmin, and operator. These groups have the following permissions:

vEdge# show aaa usergroup
GROUP     USERS  TASK       PERMISSION  
----------------------------------------
basic     -      system     read  
                 interface  read  
netadmin  admin  system     read write  
                 interface  read write  
                 policy     read write  
                 routing    read write  
                 security   read write  
operator  -      system     read        
                 interface  read        
                 policy     read        
                 routing    read        
                 security   read    

To create new user groups, use this command:

vEdge(config)# system aaa usergroup
group-name task privilege

Here is a sample user configuration on a RADIUS server, which for FreeRADIUS would be in the file "users":

user1   Cleartext-password := "user123"
        Service-Type = NAS-Prompt-User,
        Viptela-Group-Name = operator,

user1   Cleartext-password := "user123"        Service-Type = NAS-Prompt-User,        Viptela-Group-Name = operator,

Then in the dictionary on the RADIUS server, add a pointer to the VSA file:

$INCLUDE    /usr/share/freeradius/dictionary.viptela

​For TACACS+, here is a sample configuration, which would be in the file tac_plus.conf:

group = test_group {
        default service = permit
        service = ppp protocol = ip {
              Viptela-Group-Name = operator
        }
}
user = user1 {
       pap = cleartext "user123"
       member = test_group
}

The Cisco SD-WAN AAA software implements role-based access to control the authorization permissions for users on Cisco vEdge devices. Role-based access consists of three components:

• Users are those who are allowed to log in to a Cisco vEdge device.

• User groups are collections of users.

• Privileges are associated with each group. They define the commands that the group's users are authorized to issue.

Users and User Groups

All users who are permitted to perform operations on a Cisco vEdge device must have a login account. For the login account, you configure a username and a password on the device itself. These allow the user to log in to that device. A username and password must be configured on each device that a user is allowed to access.

The Cisco SD-WAN software provides one standard username, admin, which is a user who has full administrative privileges, similar to a UNIX superuser. By default, the admin username password is admin. You cannot delete or modify this username, but you can and should change the default password.

User groups pool together users who have common roles, or privileges, on the Cisco vEdge device. As part of configuring the login account information, you specify which user group or groups that user is a member of. You do not need to specify a group for the admin user, because this user is automatically in the user group netadmin​ and is permitted to perform all operations on the Cisco vEdge device.

The user group itself is where you configure the privileges associated with that group. These privileges correspond to the specific commands that the user is permitted to execute, effectively defining the role-based access to the Cisco SD-WAN software elements.

The Cisco SD-WAN software provides three standard user groups. The two groups basic and operator are configurable. While you can use these two groups for any users and privilege levels, the basic group is designed to include users who have permission to both view and modify information on the device, while the operator group is designed to include users who have permission only to view information. The third group is net admin, which is non-configurable. By default, it includes the admin user. You can add other users to this group. Users in this group are permitted to perform all operations on the device.

Note

Only admin users can view running and local configuration. Users associated with predefined operator user group do not have access to the running and local configurations. The predefined user group operator has only read access for the template configuration. If you need only a subset of admin user privileges, then you need to create a new user group with the selected features from the features list with both read and write access and associate the group with the custom user.

Privileges for Role-Based Access

Role-based access privileges are arranged into five categories, which are called tasks:

• Interface—Privileges for controlling the interfaces on the Cisco vEdge device.

• Policy—Privileges for controlling control plane policy, OMP, and data plane policy.

• Routing—Privileges for controlling the routing protocols, including BFD, BGP, OMP, and OSPF.

• Security—Privileges for controlling the security of the device, including installing software and certificates. Only users belonging to the netadmin group can install software on the system.

• System—General systemwide privileges.

The tables in the following sections detail the AAA authorization rules for users and user groups. These authorization rules apply to commands issued from the CLI and to those issued from Netconf.

User Authorization Rules for Operational Commands

The user authorization rules for operational commands are based simply on the username. Any user who is allowed to log in to the Cisco vEdge device can execute most operational commands. However, only the admin user can issue commands that affect the fundamental operation of the device, such as installing and upgrading the software and shutting down the device.

Note that any user can issue the config command to enter configuration mode, and once in configuration mode, they are allowed to issue any general configuration command. Also, any user is allowed to configure their password by issuing the system aaa user self password password command and then committing that configuration change. For the actual commands that configure device operation, authorization is defined according to user group membership. See User Group Authorization Rules for Configuration Commands.

The following tables lists the AAA authorization rules for general CLI commands. All the commands are operational commands except as noted. Also, some commands available to the "admin" user are available only if that user is in the "netadmin" user group.

User Group Authorization Rules for Operational Commands

The following table lists the user group authorization roles for operational commands.

User Group Authorization Rules for Configuration Commands

The following table lists the user group authorization rules for configuration commands.

Configuring AAA by using the vManage template lets you make configuration setting in vManage and then push the configuration to selected devices of the same type. This procedure is a convenient way to configure several of the same type of devices at one time.

Use the AAA template for Cisco vBond Orchestrators, vManage NMSs, Cisco vSmart Controllers, and Cisco vEdge device s.

Cisco vEdge device s support configuration of authentication, authorization, and accounting (AAA) in combination with RADIUS and TACACS+.

Note	You must configure a local user with a secret key via the template if you are using PPP or using MLPPP with CHAP.

Navigate to the Template Screen and Name the Template

1. In vManage NMS, select the Configuration ► Templates screen.

2. In the Device tab, click Create Template.

3. From the Create Template drop-down, select From Feature Template.

4. From the Device Model drop-down, select the type of device for which you are creating the template.

5. Select the Basic Information tab.

6. To create a custom template for AAA, select the Factory_Default_AAA_Template and click Create Template. The AAA template form is displayed. The top of the form contains fields for naming the template, and the bottom contains fields for defining AAA parameters.

7. In the Template Name field, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.

8. In the Template Description field, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.

When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated by a check mark), and the default setting or value is shown. To change the default or to enter a value, click the scope drop-down to the left of the parameter field and select one of the following:

Configure Authentication Order and Fallback

You can configure the authentication order and authentication fallback for device. The authentication order specifies the order in which the system attempts to authenticate user, and provides a way to proceed with authentication if the current authentication method is unavailable. Fallback provides a mechanism for authentication is the user cannot be authenticated or if a RADUS or TACACS+ server is unreachable

To configure AAA authentication order and authentication fallback on a Cisco vEdge device , select the Authentication tab and configure the following parameters:

CLI equivalent:

 system
   ​ aaa
  admin-auth-order  auth-fallback  auth-order  (local | radius | tacacs)
     logs 
      [no] audit-disable
      [no] netconf-disable
     radius-servers tag
            

Configure Local Access for Users and User Groups

You can configure local access to a a device for users and user groups. Local access provides access to a device if RADIUS or TACACS+ authentication fails.

To configure local access for individual users, select the Local tab. To add a new user, select the User tab, click Add New User, and configure the following parameters:

Click Add to add the new user. Click Add New User again to add additional users.

To configure local access for user groups, you first place the user into either the basic or operator group. The admin is automatically placed in the netadmin group. Then you configure user groups. To make this configuration, select the Local tab, select the User Group tab, click Add New User Group, and configure the following parameters:

Click Add to add the new user group.

To add another user group, click Add New User Group again.

To delete a user group, click the trash icon at the right side of the entry. You cannot delete the three standard user groups, basic, netadmin, and operator.

CLI equivalent:

 system
   ​aaa  
     user username      
      group group-name      
      password password usergroup group-name      
      task (interface | policy | routing | security | system) (read | write)

Configure RADIUS Authentication

Configure RADIUS authentication if you are using RADIUS in your deployment.

To configure RADIUS authentication, select the RADIUS tab and configure the following parameters:

To configure a connection to a RADIUS server, select the RADIUS tab, click Add New Radius Server, and configure the following parameters:

Click Add to add the new RADIUS server.

To add another RADIUS server, click Add New RADIUS Server again.

To remove a server, click the trash icon on the right side of the line.

CLI equivalent:

 system  radius     
    retransmit number    
    server ip-address      
      acct-port port-number
      auth-port port-number      
      priority number
      secret-key key 
      source-interface interface-name      
      ​tag tag
      vpn vpn-id    
    timeout seconds
            

Configure TACACS+ Authentication

Configure TACACS+ authentication if you are using TACACS+ in your deployment.

To configure the device to use TACACS+ authentication, select the TACACS tab and configure the following parameters:

To configure a connection to a TACACS+ server, select the TACACS tab, click Add New TACSCS Server, and configure the following parameters:

Click Add to add the new TACACS server.

To add another TACACS server, click Add New TACACS Server again.

To remove a server, click the trash icon on the right side of the line.

CLI equivalent:

 system  tacacs  
    authentication password-authentication
    server ip-address      
      auth-port port-number      
      priority number
      key key 
      source-interface interface-name    
      ​vpn vpn-id    
    timeout seconds
            

IEEE 802.1X is a port-based network access control (PNAC) protocol that prevents unauthorized network devices from gaining access to wired networks (WANs), by providing authentication for devices that want to connect to a WAN.

IEEE 802.11i prevents unauthorized network devices from gaining access to wireless networks (WLANs). 802.11i implements WiFi Protected Access II (WPA2) to provide authentication for devices that want to connect to a WLAN on a Cisco vEdge 100wm device.

A RADIUS authentication server must authenticate each client connected to a port before that client can access any services offered by network.

This section describes how to configure RADIUS servers to use for 802.1X and 802.11i authentication. It describes how to enable 802.1X on Cisco vEdge device interfaces to have the router act as an 802.1X authenticator, responsible for authorizing or denying access to network devices on a WAN.

It also describes how to enable 802.11i on Cisco vEdge 100wm device routers to control access to WLANs.

It describes how to enable IEEE 802.1X and AAA on a port, and how to enable IEEE 802.1X RADIUS accounting.

Configure RADIUS Authentication Servers

Authentication services for IEEE 802.1X and IEEE 802.11i are provided by RADIUS authentication servers. You configure the RADIUS servers to use for 802.1X and 802.11i authentication on a system-wide basis:

vEdge(config)#  system radius
 vEdge(config-radius)# server ip-address

Specify the IP address of the RADIUS server. You can configure one or two RADIUS servers to perform 802.1X and 802.11i authentication. (Note that for AAA authentication, you can configure up to eight RADIUS servers.)

For each RADIUS server, you can configure a number of optional parameters.

You can configure the VPN through which the RADIUS server is reachable and the router interface to use to reach the server:

vEdge(config-server)# vpn vpn-id
vEdge(config-server)# source-interface interface-name

If you configure two RADIUS servers, they must both be in the same VPN, and they must both be reachable using the same source interface.

You must configure a tag to identify the RADIUS server:

vEdge(config-server)# tag tag

The tag can be from 4 through 16 characters. You use this tag when configuring the RADIUS servers to use with IEEE 802.1X authentication and with IEEE 802.11i WPA enterprise authentication.

For authentication between the router and the RADIUS server, you can authenticate and encrypt packets sent between the Cisco vEdge device and the RADIUS server, and you can configure a destination port for authentication requests. To authenticate and encrypt packets, configure a key:

vEdge(config-server)# secret-key password

Enter the password as clear text, which is immediately encrypted, or as an AES 128-bit encrypted key. The key must match the AES encryption key used on the RADIUS server.

By default, UDP port 1812 is used as the destination port on the RADIUS server to use for authentication requests. You can change the port number to a number from 1 through 65535. To disable authentication, set the port number to 0.

vEdge(config-server)# auth-port number 

You can set the priority of a RADIUS server, to choose which one to use first when performing 802.1X authentication:

vEdge(config-server)# priority number 

The priority can be a value from 0 through 7. The server with the lower priority number is given priority. If you do not include this command in the RADIUS server configuration, the priority is determined by the order in which you enter the IP addresses in the system radius server command.

By default, accounting in enabled for 802.1X and 802.11i interfaces. Accounting information is sent to UDP port 1813 on the RADIUS server. To change this port:

vEdge(config-server)# acct-port number

The port number can be from 1 through 65535.

Configure IEEE 802.1X Port Security

To enable basic 802.1X port security on an interface, configure it and at least one RADIUS server to use for 802.1X authentication. The 802.1X interface must be in VPN 0.

vEdge(config)# vpn 0
interface interface-name
vEdge(config-interface)#  dot1x
vEdge(config-dot1x)#  radius-servers tag

For 802.1X authentication to work, you must also configure the same interface under an untagged bridge:

vEdge(config)#  bridge number
vEdge(config)# interface interface-name

The interface name in the vpn 0 interface and bridge interface commands must be the same. Do not configure a VLAN ID for this bridge so that it remains untagged.

You can enable 802.1X on a maximum of four wired physical interfaces. The interface cannot also be configured as a tunnel interface.

Configure the tags associated with one or two RADIUS servers to use for 802.1X client authentication and accounting. (You configure the tags with the system radius server tag command.) If you specify tags for two RADIUS servers, they must both be reachable in the same VPN. If you do not configure a priority value when you configure the RADIUS server with the system radius server priority command, the order in which you list the IP addresses is the order in which the RADIUS servers are tried.

Enable RADIUS Accounting

By default, the Cisco vEdge device never sends interim accounting updates to the 802.1X RADIUS accounting server. Accounting updates are sent only when the 802.1X session ends.

To enable the sending of interim accounting updates, configure the interval at which to send the updates:

vEdge(config-dot1x)#  accounting-interval seconds

The time can be from 0 through 7200 seconds.

Enable MAC Authentication Bypass

IEEE 802.1X authentication is accomplished through an exchange of Extensible Authentication Procotol (EAP) packets. After 802.1X-compliant clients respond to the EAP packets, they can be authenticated and granted access to the network. Enabling MAC authentication bypass (MAB) provides a mechanism to allow non-802.1X–compliant clients to be authenticated and granted access to the network.

The Cisco vEdge device determines that a device is non-802.1X–compliant clients when the 802.1X authentication process times out while waiting for an EAPOL response from the client.

To enable MAC authentication bypass for an 802.1X interface on the Cisco vEdge device :

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)# mac-authentication-bypass

With this configuration, the Cisco vEdge device authenticates non-802.1X–compliant clients using the configured RADIUS servers. The RADIUS server must be configured with the MAC addresses of non-802.1X–compliant clients that are allowed to access the network.

To enable MAB on the RADIUS server:

vEdge(config-dot1x)# mac-authentication-bypass server

To allow authentication to be performed for one or more non-802.1X–compliant clients before performing an authentication check with the RADIUS server, list their MAC addresses in the following command:

vEdge(config-dot1x)# mac-authentication-bypass allow mac-addresses

You can configure up to eight MAC addresses for MAC authentication bypass. For these devices, the Cisco vEdge device grants immediate network access based on their MAC addresses, and then sends a request to the RADIUS server to authenticate the devices.

Configure VLANs for Authenticated and Unauthenticated Clients

For clients that cannot be authenticated but that you want to provide limited network services to, you create VLANs to handle network access for these clients. You also create VLANs to handle authenticated clients.

You can create the following kinds of VLAN:

• Guest VLAN—Provide limited services to non-802.1X–compliant clients.

• Authentication Reject VLAN—Provide limited services to 802.1X-compliant clients that failed RADIUS authentication. An authentication-reject VLAN is similar to a restricted VLAN.

• Authentication Fail VLAN—Provide network access when RADIUS authentication or the RADIUS server fails. An authentication-fail VLAN is similar to a critical VLAN.

• Default VLAN—Provide network access to 802.1X–compliant clients that are successfully authenticated by the RADIUS server. If you do not configure a default VLAN on the Cisco vEdge device , successfully authenticated clients are placed into VLAN 0, which is the VLAN associated with an untagged bridge.

To configure the VLANs for authenticated and unauthenticated clients, first create the VLAN in a bridging domain, and then create the 802.1X VLANs for the unauthenticated clients by associating the bridging domain VLAN with an 802.1X VLAN.

To create the VLAN, configure a bridging domain to contain the VLAN:

vEdge(config)# bridge bridge-id
vEdge(config-bridge)# name text
vEdge(config-bridge)# vlan vlan-id
vEdge(config-bridge)# interface interface-name
vEdge(config-interface)# no shutdown

The bridging domain identifier is a number from 1 through 63. A best practice is to have the bridge domain ID be the same as the VLAN number.

The name is optional, but it is recommended that you configure a name that identifies the 802.1X VLAN type, such as Guest-VLAN and Default-VLAN.

The VLAN number can be from 1 through 4095. This is the number that you associate with an 802.1X VLAN.

The interface name is the interface that is running 802.1X.

Then configure the 802.1X VLANs to handle unauthenticated clients.

A guest VLAN provides limited services to non-802.1X–compliant clients, and it can be used to allow clients to download 802.1X client software. An interface running 802.1X assigns clients to a guest VLAN when the interface does not receive a response to EAP request/identity packets that it has sent to the client, or when the client does not send EAPOL packets and MAC authentication bypass is not enabled. To configure a guest VLAN:

vEdge(config)# vpn 0 interface interface-name interface dot1x
vEdge(config-dot1x)# guest-vlan vlan-id

The VLAN number must match one of the VLANs you configured in a bridging domain. A best practice is to have the VLAN number be the same as the bridge domain ID.

An authentication-reject VLAN provides limited services to 802.1X-compliant clients that have failed RADIUS authentication. To configure an authentication-reject VLAN:

vEdge(config-dot1x)# auth-reject-vlan vlan-id

The VLAN number must match one of the VLANs you configure in a bridging domain. A best practice is to have the VLAN number be the same as the bridge domain ID.

When the RADIUS authentication server is not available, 802.1X-compliant clients attempting to authenticate are placed in an authentication-fail VLAN if it is configured. If this VLAN is not configured, the authentication request is eventually dropped. To configure the authentication-fail VLAN:

vEdge(config-dot1x)#  auth-fail-vlan vlan-id 

The VLAN number must match one of the VLANs you configure in a bridging domain. A best practice is to have the VLAN number be the same as the bridge domain ID.

The following configuration snippet illustrates the interrelationship between the 802.1X configuration and the bridging domain configuration. This snippet shows that the bridging domain numbers match the VLAN numbers, which is a recommended best practice. Also, the bridging domain name identifies the type of 802.1X VLAN.

system
 ...
 radius
  server 10.1.15.150
   tag              freerad1
   source-interface ge0/0
   secret-key       $4$L3rwZmsIic8zj4BgLEFXKw==
   priority         1
  exit
  server 10.20.24.150
   auth-port        2000
   acct-port        2001
   tag              freerad2
   source-interface ge0/4
   secret-key       $4$L3rwZmsIic8zj4BgLEFXKw==
   priority         2
  exit
 !
!
bridge 1
 name Untagged_bridge
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
bridge 10
 name Authorize_VLAN
 vlan 10
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
bridge 20
 name Guest_VLAN
 vlan 20
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
bridge 30
 name Critical_VLAN
 vlan 30
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
bridge 40
 name Restricted_VLAN
 vlan 40
 interface ge0/5
  no native-vlan
  no shutdown
 !
!
vpn 0
 interface ge0/0
  ip address 10.1.15.15/24
  tunnel-interface
   encapsulation ipsec
   ...
  !
  no shutdown
 !
 interface ge0/1
  ip address 60.0.1.16/24
  no shutdown
 !
 interface ge0/2
  ip address 10.1.19.15/24
  no shutdown
 !
 interface ge0/4
  ip address 10.20.24.15/24
  no shutdown
 !
 interface ge0/5
  dot1x
   auth-reject-vlan 40
   auth-fail-vlan   30
   guest-vlan       20
   default-vlan     10
   radius-servers   freerad1
  !
  no shutdown
 !
 interface ge0/7
  ip address 10.0.100.15/24
  no shutdown
 !
!
vpn 1
 interface ge0/2.1
  ip address 10.2.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb1
  ip address 56.0.1.15/24
  mac-address 00:00:00:00:aa:01
  no shutdown
  dhcp-server
   address-pool 56.0.1.0/25
   offer-time   600
   lease-time   86400
   admin-state  up
   options
    default-gateway 56.0.1.15
   !
  !
 !
!
vpn 10
 interface ge0/2.10
  ip address 10.10.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb10
  ip address 56.0.10.15/24
  mac-address 00:00:00:00:aa:10
  no shutdown
  dhcp-server
   address-pool 56.0.10.0/25
   offer-time   600
   lease-time   86400
   admin-state  up
   options
    default-gateway 56.0.10.15
   !
  !
 !
!
vpn 20
 interface ge0/2.20
  ip address 10.20.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb20
  ip address 56.0.20.15/24
  mac-address 00:00:00:00:aa:20
  no shutdown
 !
!
vpn 30
 interface ge0/2.30
  ip address 10.30.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb30
  ip address 56.0.30.15/24
  mac-address 00:00:00:00:aa:30
  no shutdown
 !
!
vpn 40
 interface ge0/2.40
  ip address 10.40.19.15/24
  mtu      1496
  no shutdown
 !
 interface irb40
  ip address 56.0.40.15/24
  mac-address 00:00:00:00:aa:40
  no shutdown
 !
!
vpn 512
 interface eth0
  ip dhcp-client
  no shutdown
 !
!

Configure Control Direction

To configure how the 802.1X interface handles traffic when the client is unauthorized, set the control direction:

vEdge(config-dot1x)#  control-direction  (in-and-out | in-only)

The direction can be one of the following:

• in-and-out—The 802.1X interface can both send packets to and receive packets from the authorized client. Bidirectional control is the default behavior.

• in-only—The 802.1X interface can send packets to the unauthorized client, but cannot receive packets from that client.

Configure Authentication with Wake on LAN

IEEE 802.1X authentication wake on LAN (WoL) allows dormant clients to be powered up when the Cisco vEdge device receives a type of Ethernet frame called the magic packet. Administrators can use wake on LAN when to connect to systems that have been powered down.

When a client that uses wake on LAN and that attaches through an 802.1X port powers off, the 802.1X port becomes unauthorized. The port can only receive and send EAPOL packets, and wake-on-LAN magic packets cannot reach the client. When the device is powered off, it is not authorized, and the switch port is not opened.

Without wake on LAN, when an 802.1X port is unauthorized, the router's 802.1X interface block traffic other than EAPOL packets coming from unauthorized clients.

When you enable wake on LAN on an 802.1X port, the Cisco vEdge device is able to send magic packets even if the 802.1X port is unauthorized.

To enable wake on LAN on an 802.1X interface, use the following command:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)#  wake-on-lan 

Configure 802.1X Host Mode

The host mode of an 802.1X interfaces determines whether the interface grants access to a single client or to multiple clients. Three host modes are available:

• Single-host mode—The 802.1X interface grants access only to the first authenticated client. All other clients attempting access are denied and dropped.

• Multiple-host mode—A single 802.1X interface grants access to multiple clients. In this mode, only one of the attached clients must be authorized for the interface to grant access to all clients. If the interface becomes unauthorized, the Cisco vEdge device denies network access to all the attached clients.

• Multiple-authentication mode—A single 802.1X interface grants access to multiple authenticated clients on data VLANs.

To configure the host mode of the 802.1X interface, use the following command:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)#  host-mode  (multi-auth | multi-host | single-host)

Set the Timeout for Inactive Clients

By default, when a client has been inactive on the network for 1 hour, its authentication is revoked, and the client is timed out. To change the timeout interval, use the following command:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)#  timeout inactivity minutes 

The timeout interval can be from 0 through 1440 minutes (24 hours).

Enable Periodic Client Reauthentication

By default, once a client session is authenticated, that session remains functional indefinitely. To enable the periodic reauthentication of 802.1X clients, configure the number of minutes between reauthentication attempts:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)#  reauthentication minutes 

The time can be from 0 through 1440 minutes (24 hours)

Configure Dynamic Authorization Service for RADIUS Change of Authorization

Dynamic authorization service (DAS) allows an 802.1X interface on a Cisco vEdge device to accept change of authorization (CoA) requests from a RADIUS or other authentication server and to act on the requests. The Cisco SD-WAN implementation of DAS supports disconnect packets, which immediately terminate user sessions, and reauthentication CoA requests, which modify session authorization attributes.

DAS, defined in RFC 5176 , is an extension to RADIUS that allows the RADIUS server to dynamically change 802.1X session information without requiring the Cisco vEdge device to initiate the change request. When you enable DAS on the Cisco vEdge device , the router opens a socket to listen for CoA requests from the RADIUS server. If the network administrator of a RADIUS server modifies the authentication of an 802.1X client, the RADIUS server sends a CoA request to inform the router about the change of authorization. When the router receives the CoA request, it processes the requested change.

To enable DAS for an 802.1X interface, you configure information about the RADIUS server from which the interface can accept CoA requests. In the context of configuring DAS, the Cisco vEdge device is the server and the RADIUS server (or other authentication server) is the client.

To configure the RADIUS server from which to accept CoA requests, configure the server's IP address and the password that the RADIUS server uses to access the router's 802.1X interface:

vEdge(config)# vpn 0 interface interface-name dot1x
vEdge(config-dot1x)#  das 
vEdge(config-das)# client ip-address
vEdge(config-das)# secret-key password

You can configure the VPN through which the RADIUS server is reachable:

vEdge(config-das)# vpn vpn-id

By default, the 802.1X interface uses UDP port 3799 to listen for CoA request from the RADIUS server. You can change the port number:

vEdge(config-das)# port port-number

The port number can be a value from 1 through 65535. If you configure DAS on multiple 802.1X interfaces on a Cisco vEdge device , you must configure each interface to use a different UDP port.

By default, the CoA requests that the Cisco vEdge device receives from the DAS client are all honored, regardless of when the router receives them. To have the router handle CoA within a specified time, you require that the DAS client timestamp all CoA requests:

vEdge(config-das)# require-timestamp

With this configuration, the Cisco vEdge device processes only CoA requests that include an event timestamp. Non-timestamped CoA requests are dropped immediately.

When timestamping is configured, both the Cisco vEdge device and the RADIUS server check that the timestamp in the CoA request is current and within a specific time window. The default time window is 300 seconds (5 minutes). This behavior means that if the DAS timestamps a CoA at 15:00 and the router receives it at 15:04, the router honors the request. However, if the router receives the request at 15:10, the router drops the CoA request. You can change the time window to a time from 0 through 1000 seconds:

vEdge(config-das)# time-window seconds 

Configure RADIUS Authentication and Accounting Attributes

For IEEE 802.1X authentication and accounting, the Cisco vEdge device , acting as a network access server (NAS), sends RADIUS attribute–value (AV) pairs to the RADIUS server. These AV pairs are defined in RFC 2865 , RADIUS, RFC 2866 , RADIUS Accounting, and RFC 2869 , RADIUS Extensions. The AV pairs are placed in the Attributes field of the RADIUS packet.

By default, when you enable IEEE 802.1X port security, the following authentication attributes are included in messages sent to the RADIUS server:

When you enable RADIUS accounting, the following accounting attributes are included, by default, in messages sent to the RADIUS server:

Several configuration commands allow you to add additional attribute information to RADIUS packets.

To include the NAS-IP-Address (attribute 4) in messages sent to the RADIUS server to indicate the IP address of the Cisco vEdge device that is acting as a NAS server:

vEdge(config-dot1x)  nas-ip-address ip-address

To include the NAS-Identifier (attribute 32) in messages sent to the RADIUS server, use the following command:

vEdge(config-dot1x)#  nas-identifier string

The NAS identifier is a unique string from 1 through 255 characters long that identifies the Cisco vEdge device that is acting as a NAS server.

To include a RADIUS authentication or accounting attribute of your choice in messages sent to the RADIUS server, use the following commands:

vEdge(config-dot1x)#  auth-req-attr attribute-number (integer integer | octet
octet | string string)
vEdge(config-dot1x)#  acct-req-attr attribute-number (integer integer | octet
octet | string
string)

Specify the desired value of the attribute as an integer, octet value, or string, depending on the attribute. For example, to set the Service-Type attribute to be authenticate-only:

vEdge(config-dot1x)# auth-req-attr 6 integer 8 

Configure IEEE 802.11i Authentication

For Cisco vEdge device that support wireless LANs (WLANs), you can configure the router to support either a 2.4-GHz or 5-GHz radio frequency. Then, you segment the WLAN into multiple broadcast domains, which are called virtual access points, or VAPs. Users who connect to a VAP can be unauthenticated, or you can configure IEEE 802.11i authentication for each VAP.

For information about configuring the WLAN interface itself, see Configuring WLAN Interfaces .

To enable user authentication on the WLAN, you create a VAP on the desired radio frequency and then you configure Wi-Fi protected access (WPA) or WPA2 data protection and network access control for the VAP. WPA authenticates individual users on the WLAN using a username and password. WPA uses the Temporal Key Integrity Protocol (TKIP), which is based on the RC4 cipher. WPA2 implements the NIST FIPS 140-2–compliant AES encryption algorithm along with IEEE 802.1X-based authentication, to enhance user access security over WPA. WPA2 uses the Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP), which is based on the AES cipher. Authentication is done either using preshared keys or through RADIUS authentication.

To enable personal authentication, which requires users to enter a password to connect to the WLAN, configure the authentication and password:

vEdge(config)#  wlan frequency
vEdge(config-wlan)# interface vap number
vEdge(config-vap)# no shutdown
vEdge(config-vap)#  data-security  (wpa-personal | wpa/wpa2-personal | wpa2-personal)
vEdge(config-vap)#  wpa-personal-key password

For the security, configure either WPA, WPA2, or both (WPA/WPA2). Enter the password either as clear text or an AES-encrypted key.

For each VAP, you can customize the security mode to control wireless client access.

To enable enterprise WPA security, configure the authentication and the RADIUS server to perform the authentication:

vEdge(config-vap)# data-security (wpa-enterprise | wpa/wpa2-enterprise | wpa2-enterprise)
vEdge(config-vap)#  radius-servers tag

For the security, configure either WPA, WPA2, or both (WPA/WPA2). Enter the password either as clear text or an AES-encrypted key.

In the radius-servers command, enter the tags associated with one or two RADIUS servers to use for 802.11i authentication. (You configure the tags with the system radius server tag command.) If you specify tags for two RADIUS servers, they must both be reachable in the same VPN. If you do not configure a priority value when you configure the RADIUS server with the system radius server priority command, the order in which you list the IP addresses is the order in which the RADIUS servers are tried.

By default, management frames sent on the WLAN are not encrypted. For each VAP, you can configure the encryption to be optional or required:

vEdge(config-vap)#  mgmt-security  (none | optional | required)