Device Security using AAA (TACACS+, RADIUS and Local Database)

Authentication Authorization and Accounting

Authentication refers to the verification of the users accessing a device; it seeks answers to the question "Who are you?". Authorization defines what resources the user is allowed to access and which operations the user is allowed to perform. Accounting logs all user actions on the system.

AAA is usually used for device access and metwork access. Device access provides administrative access to network devices for administrative purposes.

Application of AAA in network access can be used to segregate users between employee access and guest access. Additionally, employees access can be further refined such that some employees can access some departmental resources and others should be unable to access network resources in other departments.

Authentication can of a user can be performed using a username and password combination. Certificates (PKI) can also be used to authenticate users. The user may be a network device.

Authorization defines what resources the user has access to. It can also be defined as what the user actions the user is allowed to perform on a device.

AAA Components

Consists of three components: supplicant, authenticator and authentication server.

1. Supplicant: device requesting access; this may be a laptop, printer, smartphone. The supplicant is either requesting for network access or device access.
2. Authenticator: this is the device being accessed; it is the device that is enforcing authentication (NAD). With device access, this device can be any network-connected device such as router, switch, wireless LAN controller. If the access request is for network access, the device is usually a wireless LAN controller or switch for wireless and wired network access respectively.
3. Authentication Server: validates the identify of the client and notifies the authenticator if the client is authorized to access the network or device. This authentication uses username/password combination or certificates (PKI) to authenticate users. RADIUS is an example of an authentication services. Cisco systems offers Identity Services Engine (ISE) and Access Control System (ACS) to provide AAA services for a network.

Protocols

AAA can be used to authenticate users for device administration or network access:

1. Device administration: device access uses console, SSH, Telnet and HTTP(S). The network device then uses RADIUS or TACACS+ to authenticate the user's network access with the authentication server.
2. Network access: For network access, users can be authenticated using protocols such as EAPoL, HTTP(S), SSL, IKEv1 and IKEv2. RADIUS, TACACS+ are used between NAD and authentication server.

Privileges

Privileges are the list of commands that a user is authorized to execute. Cisco defines different privilege levels with level 0, 1 and 15 defined. Privilege levels 2-14 are open for customization. The following table displays the different levels of privileges in Cisco IOS:

Privilege Level	Origin	Accessibility
0	Built-in	No access. Few commands are available.
1	Built-in	User mode, very limited access. It is the default exec user level and provides some show commands.
15	Built-in	Privilege exec / enable mode, verification and full access.
2 - 14	User-defined	Granular control over commands users are authorised to use

Custom Privileges

These custom privilege levels are defined in the range 2 – 14. Users can then be assigned these privileges based on the level of configuration depth that you would like them to make on the devices. The default privilege for remote access (SSH, Telnet) is 1(one) while console is 15. If a privilege level is not assigned to a line or user, then the default privilege is used.

When configuring allowable commands to privilege levels, higher privilege levels inherit commands allowed in lower privilege levels. For example assigning a privilege level of 7 to a user allows the user to run commands that have been allowed to be run in privilege levels 0 – 6 in addition to level 7.

The following example configuration sets the commands that the custom privilege level 2 is permitted to run. Here, the user is permitted to access the configuration mode and shutdown or enable interfaces only. Privilege level 2 is then assigned to a user account on the local database.

R1(config)#privilege exec level 2 configure terminal
R1(config)#privilege configure level 2 interface
R1(config)#privilege interface level 2 shutdown
R1(config)#privilege interface level 2 no shutdown
R1(config)#privilege exec level 2 show privilege
R1(config)#username bob privilege 2 secret alice

When the privilege level is defined on the router as in the case above, by default, the router will use the local database for commands.

The use of role-based access control(RBAC) provides granular control over commands and privileges from a centralized point.

Line Privilege

Privilege level can be configured for a line rather than a user (see Local Database section). This can be accomplished using the line command privilege level <level>. Here, all users who login into the device through the configured line will be granted the same privilege level.

R1(config)#line vty 0 4
R1(config-line)#privilege level 10

If a user has a privilege configured in the local database and the user logs into the device through a VTY line that has a configured privilege, the user's local database configured-privilege supersedes the configured line privilege.

Verification

To verify privileges of the login session, use the command show privilege.

R2#192.168.1.1
Trying 192.168.1.1 ... Open

User Access Verification

Username: bob
Password:
R1#show privilege
Current privilege level is 2


From the output above, the VTY line was configured with a privilege level of 10. However, the user bob's session privilege is 2(two) which is the privilege level configured in the local database.

Local Database

The local database is a list of user accounts configured on the local device. The local database contains records of the username, password and configured privilege levels for users. The local database supports authentication and authorization features. However, it does not support accounting functionality. Authorization is supported through the configuration of privilege levels. This database can be used to authenticate many types of sessions such as login sessions.

A local user database is created using the global config command username <username> privilege <level> secret <password>. Use of the keyword secret is preferred to password because it encrypts the secret key in the configuration file. If password is used, then the secret key has to be encrypted in the configuration file using the command service password encryption.

R1(config)#username bob privilege 1 secret alice
R1(config)#username alice privilege 1 secret bob
R1(config)#username rasta privilege 1 password reggae
R1(config)#do show run | in username
username bob privilege 2 secret 5 $1$WHSh$PYERWv2eq6ud0txH8G4id.
username alice privilege 3 secret 5 $1$HxyA$IHet6l6lilvR7A2z7bYme.
username rasta password 0 reggae


Local Database for Authentication

If the local database is to be used for authenticating remote users through VTY lines or local console connections, then the following commands can be used.

R1(config)#ip domain-name emmanueltoko.blogspot.com
R1(config)#crypto key generate rsa modulus 2048
The name for the keys will be: R1.emmanueltoko.blogspot.com

% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 33 seconds)

R1(config)#
*Feb 22 13:29:06.599: %SSH-5-ENABLED: SSH 1.99 has been enabled
R1(config)#ip ssh version 2
R1(config)#do show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded):
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2ErQIRNGA/SVNcDfgoGZs2KTF3nNPXPC19zUVakD9
NGKyb88AhWu1kVJeOSBarZzivfezJY5E2QLzFw6FjZ6Tla41NOTduziwzHht2dvO3kDTCli61wW9bF5Q
ekjXc8HOwOXd2f0kslx8Il9QxELY1Sq01tPk/Q4Pgza3NOqC+oLHVLkJt5JBDn84AybjYn56OgXk1ETb
Mjj2VKy7M7WdNlhful17LHX/mkVVZSavpMfMhpjaz/Z+yHbgGsNu5r5wNS29+rMpjB4OCAbpATy/Ee1V
GsEEiQU8XChJk9kwM8ADxFJZKz5bHHlmbyiI9LS/jN3SaEtZbU2pKpQwMaKN
R1(config)#line vty 0 4
R1(config-line)#login local
R1(config-line)#transport input ssh telnet

The above command enables authentication using the local database on vty lines 0 to 4 (5 simultaneous remote logins). In this snippet, SSH has been enabled as the primary remote access method with telnet as backup if SSH fails.

Note: It is recommended disable remote access using telnet as it sends the authentication credentials and commands to the remote device in clear text.

Device Security With AAA

AAA refers to authentication, authorization and accounting. It is a refined approach to authenticating users, authorizing their activities and logging (accounting) for all their activities and commands issued on a network device. AAA supports the use of the local database, RADIUS and TACACS+ for authenticating and authorization, and only RADIUS and TACACS+ for accounting.

AAA features are not available until enabled globally using the global config mode command aaa new-model.

Local Database

When implementing AAA using the local database, the router authenticates the username and password using the local database and the user is authorized to access the network device based on the information in the local database. Local authentication is used on small networks and is not scalable.

Authentication with Local Database

1. Turn on AAA services;
   R1(config)#aaa new-model

2. Create a local user:
   R1(config)#username user secret pass

3. Set the enable password:
   R1(config)#enable secret pass

4. Configure login authentication to use the enable password as the default method:
   R1(config)#aaa authentication login default enable

   OR

   Create a login authentication method named local_auth and set it to authenticate users against the local database:

   R1(config)#aaa authentication login local_auth local

5. Apply AAA authentication to the VTY lines;

   If using the default method:

   R1(config)#line vty 0 15
R1(config-line)#login authentication default

   If using a configured authentication method:

   R1(config)#line vty 0 15
R1(config-line)#login authentication local_auth

6. SSH to above router: It uses the local database to authenticate;
   R1#ssh -l user7 192.168.1.1

Authorization using Local Database

If authorization is enabled for a line, and enable secret is configured, the enable secret is superseded by the aaa authorization. To enable authorization,

1. Create a user:
   R1(config)#username user secret pass
   Login to the above router from the remote host: What is the privilege level?
2. Create an exec-authorization method: Create method list local-author. Configure authorization to be performed against the local router’s database
   R1(config)#aaa authorization exec local-author local

3. Apply ‘local-author’ as an authorisation method for the vty lines
   R1(config)#line vty 0 4
R1(config-line)#authorisation exec local-author

4. Telnet to router and authenticate.

The main drawbacks of local user authentication are:

• User credentials are stored locally i.e., on the device
• Solution is not scalable if the network grows to hundreds of devices
• More administrative overhead
• No centralized control over authentication services

It is therefore recommended to deploy the services of external server-based authentication such as ISE, ACS, or any other platform that supports RADIUS or TACACS+ for network access control. These have the following strengths

RADIUS

RADIUS (Remote Authentication Dial-In User Service) is standards-based protocol for implementing AAA (RFC 2865). It combines authentication and authorization into a single resource. It offers robust accounting features. The default ports for RADIUS servers are 1645 for authentication and 1646 for accounting. The new RFC sets the RADIUS ports on UDP ports 1812 for authentication and 1813 for accounting. RADIUS uses both TCP and UDP as the transport protocol. With RADIUS, only the password is encrypted. RADIUS combines authentication and authorization features. It offers robust accounting features.

The RADIUS server may be located in the same subnet or remote network. All that is required is for the local device to have IP connectivity to the RADIUS server.

Authentication using RADIUS

When configuring authentication of user credentials against a RADIUS server, the local device sends the authentication credentials entered by the user to the specificed IP address of the RADIUS server connecting to the port number 1812 or 1645.

When configuring RADIUS authentication, ensure that a backup authentication method is configured to avoid being unable to access the device due to misconfiguration of the RADIUS authentication. Usually, this backup authentication method is the local database. When authenticating a user login session against a RADIUS server, by default, IOS will attempt to connect to the RADIUS server up to five times to make an access request. If the connection attempt fails all these five times, then the backup authentication method is used. A RADIUS server will not respond to an access request if the requester is not configured as a client. This happens regardless of whether IP connectivity between the client and the server exists.

RADIUS uses MD5 to generate a digest of the user's password by default.

If the RADIUS server does respond with an access denied message to an authentication request, then the IOS will deny access and not use the configured backup authentication method.

Configuration

1. Enable AAA with aaa new-model command;
   R1(config)#aaa new-model

2. Define the source of authentication: Use local database as last resort; The default RADIUS authentication port is 1645 and accounting port 1646.
   R1(config)#radius-server host 192.168.1.2 auth-port 1812 acc-port 1813
R1(config)#radius-server host 192.168.1.2 key password

   OR

   R1(config)#radius server RADIUS_SERVER01
R1(config-radius-server)#address ipv4 192.168.1.2 auth-port 1812 acct-port 1813
R1(config-radius-server)#key complexpassword
R1(config)#radius server RADIUS_SERVER02
R1(config-radius-server)#address ipv4 192.168.1.5 auth-port 1812 acct-port 1813
R1(config-radius-server)#key complexkey

   Additional interaction with the RADIUS servers can be configured using the following options:

   • timeout <1-1000>: the time to wait(in seconds) for the server to respond when requesting for an authentication attempt. If access to the first server times out, an attempt to connect to the second server is initiated.
   • retransmit <0-100>: number of retries to active server after every failure. The default number of retransmit attempts is five times.

   When configuring a server, it is automatically added to a group radius. If a server group is explicitly configured (step below), then the server will be added to this group. This can be verified using the command show radius server-group all:

   R1#show radius server-group all
Server group radius                    
    Sharecount = 1  sg_unconfigured = FALSE
    Type = standard  Memlocks = 1      
    Server(192.168.1.2:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0
    Server_auto_test_enabled: FALSE    
     Keywrap enabled: FALSE            
    Server(192.168.1.5:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0
    Server_auto_test_enabled: FALSE    
     Keywrap enabled: FALSE            
R1#

3. 1. Define a group name that will contain the list of servers: aaa group server radius <group-name>.
      R1(config)#aaa group server radius RADIUS_SERVERS

   2. Define each server in the group server <ip-address>
      R1(config-sg-radius)#server name RADIUS_SERVER01
R1(config-sg-radius)#server name RADIUS_SERVER02

      Alternatively, IP address or server name (requires DNS server to be configured) of the RADIUS servers can be defined in place of the server names using the command server <ip-address|hostname>. The timeout and retransmit settings can also be configured for each server in this group.

      R1(config-sg-radius)#do show radius server-group all
Server group radius                      
    Sharecount = 1  sg_unconfigured = FALSE
    Type = standard  Memlocks = 1        
    Server(192.168.1.2:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0  
    Server_auto_test_enabled: FALSE      
     Keywrap enabled: FALSE              
    Server(192.168.1.5:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0  
    Server_auto_test_enabled: FALSE      
     Keywrap enabled: FALSE              
Server group RADIUS_SERVERS              
    Sharecount = 1  sg_unconfigured = FALSE
    Type = standard  Memlocks = 1        
    Server(192.168.1.2:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0  
    Server_auto_test_enabled: FALSE      
     Keywrap enabled: FALSE              
    Server(192.168.1.5:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0  
    Server_auto_test_enabled: FALSE      
     Keywrap enabled: FALSE              
                                          
R1(config-sg-radius)#

      If configuring a server as private, using server-private instead of server, it does not get added to the group radius but is only available in the group can it is defined in.

      R1(config)#aaa group server radius RADIUS_SERVERS
R1(config-sg-radius)#server-private 192.168.1.7 auth-port 1645 acct-port 1646 key cisco

4. Configure the purpose of the authentication and method of authentication:
   1. Purpose of authentication: authentication can be enabled for a list of services such as the following:
      • login: login to the device.
      • enable: executing the enable command to move into privileged mode. The authentication prompt for enable appears regardless of connection type i.e., console, SSH, telnet.
      • dot1x: authentication by cable network access.
   2. Authentication list: You can list authentication methods by giving the method a descriptive name or using the unnamed ‘default’ method; aaa authentication login <default | list-name method1, method2, method3>.
      1. default list: the default authentication list uses the keyword default to define the list;
         R1(config)#aaa authentication login default

         It is recommended to use the named list over the default list. The default list keyword gets attached to console, vty lines automatically; it is common to all the lines. This increases the possibilities of getting locked out due to misconfiguration. With the named lists, the different lines such as console, vty will require explicit configuration.

      2. Using a named list: here, the named list AAA_AUTHENTICATION is used:
         R1(config)#aaa authentication login AAA_AUTHENTICATION

   3. Define the authentication method(s):

      More than one method can be configured. The methods refer to the following;

      • tacacs+: each tacacs+ server is tried in configuration order
      • radius: each radius server is tried in configuration order
      • local: the local user database containing the username commands configured on the switch
      • local-case: use the local database with case sensitivity.
      • enable: use of the enable password for authentication.
      • line: line passwords authenticate any connected user. No usernames can be used.

      The following configuration uses the enable authentication as a backup for RADIUS authentication.

      R1(config)#aaa authentication login AAA_AUTHENTICATION group radius local enable

      The keyword group has the options RADIUS or TACACS and the authentication request will be forwarded to the configured RADIUS groups first, the next 'local' will be used if the RADIUS servers are unavailable/unreachable. Lastly, the enable password will be used for authentication. Note: Add the local, line and/or enable methods at the end of the list as a last resort authentication method.

      If the authentication using RADIUS fails, the next authentication method is not used. RADIUS authentication failure happens when a user account is not available in the RADIUS server or when a user's password is not correct. The second authentication method is only used if the RADIUS server is not reachable.

      However, if the local or local-case authentication method is configured as first authentication method and RADIUS as second, if an authentication request fails for the local method, then RADIUS authentication is attempted next. This fact can be used to ensure that some users are authenticated using the local database and others use RADIUS only.

5. Apply a method list to a line (Console, VTY): To enable AAA authentication on VTY lines 0 to 4 (5 simultaneous connections).
   R1(config)#line vty 0 4
R1(config-line)#login authentication AAA_AUTHENTICATION

Instead the default unnamed method list can be used if method list was not defined in Step 4.

Verification

RADIUS authentication can be verified using the command debug radius authentication. The following output shows an attempt to login remotely using telnet. The RADIUS servers in the server group are unreachable, so the backup authentication method, local-case is used and is successful:

!!On R1

R1#debug radius authentication


!--------------------------

!!On R2

R2#192.168.1.1
Trying 192.168.1.1 ... Open

User Access Verification

Username: bob
Password:

R1#

!!! Debug messages on R1
!---------------
*Apr 17 22:47:31.367: RADIUS/ENCODE(00000024): ask "Username: "
*Apr 17 22:47:31.367: RADIUS/ENCODE(00000024): send packet; GET_USER
R1(config)#
*Apr 17 22:47:37.479: RADIUS/ENCODE(00000024): ask "Password: "
*Apr 17 22:47:37.483: RADIUS/ENCODE(00000024): send packet; GET_PASSWORD
R1(config)#
*Apr 17 22:47:41.855: RADIUS/ENCODE(00000024):Orig. component type = Exec
*Apr 17 22:47:41.859: RADIUS: AAA Unsupported Attr: interface [221] 4 1797168952
*Apr 17 22:47:41.859: RADIUS/ENCODE(00000024): dropping service type, "radius-server attribute 6 on-for-login-auth" is off
*Apr 17 22:47:41.859: RADIUS(00000024): Config NAS IP: 0.0.0.0
*Apr 17 22:47:41.859: RADIUS(00000024): Config NAS IPv6: ::
*Apr 17 22:47:41.863: RADIUS/ENCODE(00000024): acct_session_id: 19
*Apr 17 22:47:41.863: RADIUS(00000024): sending
*Apr 17 22:47:41.867: RADIUS/ENCODE: Best Local IP-Address 192.168.1.1 for Radius-Server 192.168.1.2
*Apr 17 22:47:41.867: RADIUS(00000024): Send Access-Request to 192.168.1.2:1812 id 1645/2, len 67
*Apr 17 22:47:41.867: RADIUS: authenticator 83 1D 62 A3 6C FD D2 D4 - A2 59 29 65 B0 96 39 3D
*Apr 17 22:47:41.867: RADIUS: User-Name [1] 5 "bob"
*Apr 17 22:47:41.867: RADIUS: User-Password [2] 18 *
*Apr 17 22:47:41.867: RADIUS: NAS
R1(config)#-Port [5] 6 2
*Apr 17 22:47:41.867: RADIUS: NAS-Port-Id [87] 6 "tty2"
*Apr 17 22:47:41.867: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
*Apr 17 22:47:41.867: RADIUS: NAS-IP-Address [4] 6 192.168.1.1
*Apr 17 22:47:41.867: RADIUS(00000024): Sending a IPv4 Radius Packet
*Apr 17 22:47:41.867: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:47:46.875: RADIUS(00000024): Request timed out!
*Apr 17 22:47:46.875: RADIUS: Retransmit to (192.168.1.2:1812,1813) for id 1645/2
*Apr 17 22:47:46.879: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:47:51.923: RADIUS(00000024): Request timed out!
*Apr 17 22:47:51.923: RADIUS: Retransmit to (192.168.1.2:1812,1813) for id 1645/2
*Apr 17 22:47:51.927: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:47:56.959: RADIUS(00000024): Request timed out!
*Apr 17 22:47:56.959: RADIUS: Retransmit to (192.168.1.2:1812,1813) for id 1645/2
*Apr 17 22:47:56.963: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:01.979: RADIUS(00000024): Request timed out!
*Apr 17 22:48:01.979: RADIUS: Fail-over to (192.168.1.5:1812,1813) for id 1645/2
*Apr 17 22:48:01.983: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:07.019: RADIUS(00000024): Request timed out!
*Apr 17 22:48:07.019: RADIUS: Retransmit to (192.168.1.5:1812,1813) for id 1645/2
*Apr 17 22:48:07.019: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:12.047: RADIUS(00000024): Request timed out!
*Apr 17 22:48:12.047: RADIUS: Retransmit to (192.168.1.5:1812,1813) for id 1645/2
*Apr 17 22:48:12.051: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:17.083: RADIUS(00000024): Request timed out!
*Apr 17 22:48:17.083: RADIUS: Retransmit to (192.168.1.5:1812,1813) for id 1645/2
*Apr 17 22:48:17.087: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:22.111: RADIUS(00000024): Request timed out!
*Apr 17 22:48:22.111: RADIUS: Fail-over to (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:22.115: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:27.135: RADIUS(00000024): Request timed out!
*Apr 17 22:48:27.135: RADIUS: Retransmit to (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:27.139: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:32.175: RADIUS(00000024): Request timed out!
*Apr 17 22:48:32.179: RADIUS: Retransmit to (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:32.183: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:37.215: RADIUS(00000024): Request timed out!
*Apr 17 22:48:37.215: RADIUS: Retransmit to (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:37.219: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:42.243: RADIUS(00000024): Request timed out!
*Apr 17 22:48:42.243: RADIUS: No response from (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:42.247: RADIUS/DECODE: No response from radius-server; parse response; FAIL
*Apr 17 22:48:42.247: RADIUS/DECODE: Case error(no response/ bad packet/ op decode);parse response; FAIL
R1(config)#

Authorization

AAA authorization determines what commands an authenticated user is permitted to issue to the network device. Authenticated users are by default put at EXEC level. Command authorization involves configuring the commands that an authenticated user is permitted to use. Here, an authorization request is sent to the RADIUS server each time that the user types a command. Authorization can be configured to set the login session to a configured privilege. If privileges have not been configured, then the default privilege is set (one for remote session and fifteen for a console session).

Configuring a privilege at the line level is not recommended as all users will have the same privilege. It is recommended to set the privilege for each user.

1. Configure authorisation by defining any RADIUS or TACACS+ servers. Follow steps 1 -3 of RADIUS and/or TACACS+ configurations above.
2. Define a method list of authorisation that will be tried in sequence using; aaa authorisation <commands | config-commands | configuration | exec | network| reverse-access> <default | list-name> method1, method2, method3 …. methodn .

   Specify the function or service needing authorisation with one of the following keywords;

   • commands: the server must return permission to use any command at any privilege level
   • config-commands: the server must return permission to use any configuration command.
   • configuration: The server must return permission to enter configuration mode.
   • exec: server must return permission for the user to run an EXEC session. The server can also return the privilege level for the user so that the user immediately can be put into privileged EXEC (enabled) mode without typing ‘enable’.
   • network: the server must return permission to use network-related services.
   • reverse-access: the server must return permission for the user to access a reverse telnet session.

   You can identify the method with a descriptive name (list-name) or use the single unnamed list (default). Each authorisation method will be listed in the order it will be tried;

   • group <group-name>: requests are sent to servers in a group.
   • group <radius|tacacs+: requests are sent to all servers of this type.
   • if-authenticated: requests are granted if the user is already authenticated.
   • none: no external authorisation is used; every user is authorised successfully.

   Only TACACS+ servers can authorise users with permission to use specific commands. RADIUS servers offer more of an all or nothing approach.

3. Apply an authorisation method list to a specific line; authorization <commands level | exec | reverse-access> <default | list-name>. If this command is not entered, the default group is used for all lines. To configure a switch / router to use AAA authorisation for all lines using configured TACACS+ group, with the local user database as backup authorisation.
   R1(config)#aaa authorisation exec aaa-exec group tacacs+ local

   Another example:

   R1(config)#aaa authorisation exec VTY group radius local

   Here authorization is attempted using configured RADIUS servers; if this fails, then the local database is used as backup.

4. Apply the authorization to the line:
   1. For remote sessions(vty):
      R1(config)#line vty 0 98
R1(config-line)#authorization exec VTY

   2. For console sessions:

      Authorization is not enabled on console by default. It should be explicitly enabled first.

      R1(config)#aaa authorization console

      R1(config)#line console 0
R1(config-line)#authorization exec CON


autocommand logout

Given a user, bob, if we want to ensure that this account is authenticated for some purposes but not for login, one option available is not to use the aaa authentication for login. Another option is to use username bob autocommand logout. Under authorization, aaa authorization exec default local group MYRADIUS.

Accounting

AAA accounting logs all actions including configurations and show commands issued on the network device. To configure accounting, the following sequence of commands needs to be configured;

Enable AAA and configure RADIUS and TACACS+ server groups as described in steps 1 -3 of RADIUS and TACACS+ authentication procedures. Define a method list giving a sequence of accounting methods; aaa accounting [system | exec | commands <level>] [default | <list-name>] [start | stop | stop-only | wait-start | none] [method1 method2 method3 ..methodn] .

The function triggering the accounting can be one of the following;

• system: major events such as reloading are recorded.
• exec: user authentication into an EXEC session is recorded along with the user’s address, time, duration.
• commands level: information about any command running at a specific privilege level is recorded, along with the user who issued the command.

You can specify that certain types of accounting records to be sent to the accounting server using;

• start-stop: events are recorded when they start and stop-only
• stop-only: event are recorded only when they stop.
• none: no events are recorded.

Apply an accounting method list to a specific line; accounting <commands level | connection | exec> <default | list-name>. If the above command is not used, default group will be used for all lines. User EXEC sessions will be recorded as they start and stop along with user information. Any commands that are entered while a user is in privilege 15 (enable mode) will also b recorded.

Example:

R1(config)#aaa accounting exec default start-stop group myauthserver
R1(config)#aaa accounting commands 15 default start-stop group myauthserver

TACACS+

Developed by Cisco systems, it is mainly used for device administration using ACS servers. It uses TCP port 49 for both the client and server. TACACS+ does not support EAPoL.

In networks supporting TACACS+ and RADIUS, it is common for TACACS+ to be used for device administration and RADIUS for network access.

Authentication using TACACS+

TACACS+ (Terminal Access Controller Access Control System) is Cisco-proprietary and uses port 49 on TCP (but also UDP). It provides separate services for authentication, authorisation and accounting. TACACS+ offers basic accounting features. Unlike RADIUS where only the password is encrypted, with TACACS+, the entire packet is encrypted.

Configuration

1. Enable AAA:
   R1(config)#aaa new-model

2. Configure TACACS+ server settings on the client:
   R1(config)#tacacs server TACACS+_SERVER01
R1(config-tacacs-server)#address ipv4 192.168.1.2
R1(config-tacacs-server)#key complexpassword
R1(config)#tacacs server TACACS+_SERVER02
R1(config-tacacs-server)#address ipv4 192.168.1.5
R1(config-tacacs-server)#key complexkey


   The TACACS+ port does not need to be explicitly configured as the default port of 49 is used. However, it can be explicitly configured if the TACACS+ server is listening on a port that is not the default TCP port 49.

   R1(config-tacacs-server)#port 65000

   Some prefer to configure TACACS+ server settings using the command tacacs-server host <server-ip-address>.

   R1(config)#tacacs-server host 192.168.1.2
R1(config)#tacacs-server key complexpassword

3. Configure TACACS+ server groups;
   R1(config)#aaa group server tacacs+ TACACS+_SERVER_GROUP
R1(config-sg-tacacs)#server name TACACS+_SERVER01
R1(config-sg-tacacs)#server name TACACS+_SERVER02


4. Create a login authentication method named ‘AAA_AUTHENTICATION’ and configure it to authenticate against a TACACS+ server. The local user database should be the backup authentication method.
   R1(config)#aaa authentication login AAA_AUTHENTICATION group tacacs+ local

5. Apply ‘AAA_AUTHENTICATION’ method to vty lines
   R1(config)#line vty 0 4
R1(config-line)#login authentication AAA_AUTHENTICATION

6. Telnet above router. What credentials were used and why?

Cisco Authentication Servers

Cisco offers access control system (ACS) and Identity Services Engine(ISE) servers as physical hardware or virtual images to implement access authentication. ACS and ISE support RADIUS and TACACS+:

• Access Control System (ACS):
  • Used for both device access and network access
  • Supports both RADIUS and TACACS+ with TACACS+ particularly used for device access.
• Identity Services Engine (ISE):
  • Mainly used for network access.
  • Mainly uses RADIUS. However, starting ISE 2.0, TACACS+ support has been added.
  • Supports RADIUS with Change of authorization (CoA).
  • Supports additional features such as profiling such as granting access to specific devices only, security posture assessment of the end-user device (device must meet certain minimum requirements), web portal services such as for guest user access.