Basic AAA Configuration on IOS

By stretch | Monday, September 27, 2010 at 1:18 a.m. UTC

Cisco IOS supports minimal password authentication at the console/VTY line and privilege exec boundaries,
through the use of static, locally defined passwords. For example:

enable secret 5 $1$J19J$Q2jB2AM64H0U001nHStLW1

no aaa new-model

line con 0

password 7 0532091A0C595D1D3B00351D190900

login

line vty 0 15

password 7 152B0419293F38300A36172D010212

login

While easily implemented, this approach is far from ideal for a production network. For much more robust and easily
managed authentication schemes, IOS supports the Authentication, Authorization, and Accounting (AAA) model,
using the RADIUS or TACACS+ protocols to centralize these functions on dedicated AAA servers.

This article will look at deploying a typical IOS router AAA configuration which must meet two requirements:

 All users logging into the router must authenticate with a username and password to one of two redundant
TACACS+ servers.
 Users must be able to log in using a backup local user account stored on the router only if neither TACACS+
server is reachable.

This article assumes that all back-end AAA server configuration has been completed and is working.

Configuring AAA on IOS for general administrative access entails four basic steps:

1. Enable the "new model" of AAA.

2. Configure the server(s) to be used for AAA (e.g. TACACS+ servers).
3. Define authentication and authorization method lists.
4. Enforce AAA authentication on the relevant lines (e.g. console and VTY lines).
Step 0: Create a backup user account
Although not technically a part of AAA configuration, we want to ensure a backup user account exists in the event
the AAA servers become unreachable, so that we can still log in to the router.

Router(config)# username BackupAdmin privilege 15 secret MySecretPassword

Step 1: Enabling AAA

The new AAA model of authentication is enabled with a single command, which unlocks all other aaa commands on
the command line interface. Note that this command will break non-AAA line and enable passwords.

Router(config)# aaa new-model

Step 2: Configuring the TACACS+ servers

Next we need to configure the addresses of the AAA servers we want to use. This example shows the configuration
of TACACS+ servers, but the concept applies to RADIUS servers as well.

There are two approaches to configuring TACACS+ servers. In the first, servers are specified in global configuration
mode using the command tacacs-server to specify an IP address and shared secret key for each server:

Router(config)# tacacs-server host 192.168.1.3 key MySecretKey1

Router(config)# tacacs-server host 192.168.2.3 key MySecretKey2

This approach is sufficient for many deployments, but is problematic if you want to reference only a subset of the
defined servers for a certain AAA function. For example, suppose you want to use one TACACS+ server for control
plane authentication on the router itself, and the second server for authenticating PPP connections. In this case, you
would assign the servers to named AAA server groups:

Router(config)# aaa group server tacacs+ LoginAuth

Router(config-sg-tacacs+)# server 192.168.1.3

Router(config)# aaa group server tacacs+ PPPAuth

Router(config-sg-tacacs+)# server 192.168.2.3

Note that if using server groups, the servers are still defined with tacacs-server in global configuration mode.
(Servers can optionally be defined only within a group by using the command private-server under group
configuration.)
Step 3: Define the AAA method lists
Next we need to define a method list which instructs the router to use AAA authentication for terminal logins.

Router(config)# aaa authentication login default group tacacs+ local

This is a rather lengthy command, so let's work through it one bit at a time. aaa authentication login specifies
that the following parameters are to be used for user login authentication. The word default is used in lieu of a
custom name for the list (you can only define one default list for each AAA function).

The rest of the line specifies authentication methods. group tacacs+ means "use all configured TACACS+
servers." If you defined a named server group in step two, use the name of that group in place of the
word tacacs+here. local defines a secondary authentication mechanism; it instructs the router to fail over to locally
defined user accounts if none of the authentication servers in the first method are reachable. (Note that this only
happens if the servers are unreachable; a response from a server denying authentication will not trigger a fail-over
to local authentication.)

The above method list handles only the authentication aspect of AAA. By itself, this list only allows us to
authenticate as a user with privilege level 1 (user exec mode). To communicate a heightened privilege level (e.g.
privilege level 15, or "enable mode") from the TACACS+ server, we also need to define an authorization method list
for IOS shell creation.

Router(config)# aaa authorization exec default group tacacs+ local

You can see that the authorization method list follows the same logic as our first list, the only difference being that
this list is used for exec (shell) authorization rather than login authentication.

Step 4: Enforcing AAA authentication on terminal lines

This last step has actually been done for us already by enabling AAA in step one. However, if we were to create a
custom authentication method list for these lines, we would use the command below, substituting the method list
name for the word default.

Router(config)# line console 0

Router(config-line)# login authentication default

Router(config)# line vty 0 15

Router(config-line)# login authentication default

These commands will not appear in the running configuration if the default method list is specified.
At this point, we should have a fully functional AAA configuration for console authentication and authorization.

stretch@Sandbox ~ $ telnet 192.168.1.132

Trying 192.168.1.132...

Connected to 192.168.1.132.

Escape character is '^]'.

Username: jstretch

Password:

Router#

Notice that upon logging in I was immediately placed into privileged exec mode without having to use the
command enable. This is our authorization method list at work. And remember, if the TACACS+ servers become
unreachable, we can log into the router using the local user account we created in step zero.

The completed AAA configuration is included below.

aaa new-model

aaa authentication login default group tacacs+ local

aaa authorization exec default group tacacs+ local

username BackupAdmin privilege 15 secret 5 $1$qLGb$VQ6BdqCEpzGZqPeC779Uh1

tacacs-server host 192.168.1.3 key 7 062B1612494D1B1C113C17125D

tacacs-server host 192.168.2.3 key 7 143A0B380907382E3003362C70

UPDATE: I've added a packet capture of the TACACS+ authentication and authorization requests made by the
router during a user login.
uthentication, Authorization, and Accounting… Otherwise Known as AAA (triple A). Most
people who have had to implement AAA on a router or switch probably know very little
about the commands they copy to the router config. Most simply grab the AAA configs
from another working router or switch and be done with. But have you ever wondered what
these commands do? Have you asked yourself – “Do I even need this? What’s the best
way to implement AAA?” Today we’re gonna get our [ROUTER]FREAK on and check out
some best practices with AAA.

If your working in an environment that uses AAA then you no doubt have a TACACS+ or
ACS server running somewhere that is used for management of logins to your
devices. AAA works in conjuction with TACACS+ to provide management of your login
security. Who can login (Authentication), What can that user do (Athorization), and track
the commands that are used (Accounting).
I’ve recently worked directly with Cisco to bang out what exactly is the best practices for
configuring AAA on a router. what we came up with is the following:
aaa new-model
aaa authentication login default group tacacs+ local
aaa authentication enable default group tacacs+ enable
aaa authorization config-commands
aaa authorization exec default group tacacs+ local if-authenticated
aaa authorization commands 1 default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ local if-authenticated
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
Some router configurations look more intimidating than others and AAA is always one
them. Don’t worry, we’ll break this down and you will see its not so bad after all.

So lets take a look at it one line at a time…

aaa new-model
This basically turns on aaa on the router.
aaa authentication login default group tacacs+ local
Here we are saying that to authenticate to this router for logins use the default group which
is tacacs+. If tacacs+ fails then use the local user account configured on the router. (This
is why you always want to make sure you have a local user configured on your router)
aaa authentication enable default group tacacs+ enable
Here we are saying that for enable mode we want to use the default group tacacs+ (notice
the local keyword is not used. This is because that a locally defined user will have
specified the authorization level they require. . for example leve 15 will get enable mode)

aaa authorization config-commands

This says we want to check with TACACS+ to authorize going into config mode.
aaa authorization exec default group tacacs+ local if-authenticated
Notice the “if-authenticated” keyword at the end of this line. This is saying that if we are
authenticated we will immediately be dropped into exec (enable) mode.
aaa authorization commands 1 default group tacacs+ if-authenticated
For best practices Cisco recommends that authorization be configured to each level of user
access to network devices. In this command we are authorizing level 1 user. This would
also be the same as non-enable mode. A fallback method should be configured such as a
local user. This also requires the use of tacacs+.
aaa authorization commands 15 default group tacacs+ local if-authenticated
Here we are providing authorization for level 15 users against tacacs+. If tacacs+ is not
available then the local user account is used. If authenticated the user will immediately be
dropped into exec/enable mode.
aaa accounting exec default start-stop group tacacs+
AAA Accounting for each level of commands ensures there is accountability for use of
privileged commands on the router. Privilege levels range from 1 to 15, with 15 being the
highest level. Some organizations may want to implement additional levels of commands
where 1 might be a help desk and 15 are network administrators.
aaa accounting commands 1 default start-stop group tacacs+
This is an optional command as far as best practices go… but this provides accountability
or tracking of user activity even they thay have only logged in (not exec/enable)
aaa accounting commands 15 default start-stop group tacacs+
This command will provide for accounting of adminsitrators or priveledge level 15
… And that’s it! See? Oonce you go over each line its not quite so bad. The biggest
hurdle is understanding the freaky Cisco command structure.

I hope this break down has helped clear things up a bit.

Until next time — FREAK!

 Lab Topology

After creating users and network devices (Routers or Switches) accounts in Cisco Secure Access Control Server, you can
start configuring the network devices (Routers or Switches) for AAA login authentication. To configure AAA login
authentication in a Cisco Router or Switch using TACACS+ and RADIUS, use the following Cisco IOS CLI commands.

• Enable AAA in Cisco Router or Cisco Switch. Before start using AAA, we must enable AAA globally in a Cisco Router or
switch. To enable AAA in a Cisco Router or Switch, use the "aaa new-model" Cisco IOS CLI command, as shown below.

OmniSecuR1#configure terminal

OmniSecuR1(config)#aaa new-model

OmniSecuR1(config)#exit

OmniSecuR1#a

• Configure the Cisco Router or Switch with the IP address of Secure ACS, which provides the AAA authentication services
and the shared key for encryption, using Cisco IOS CLI commands as shown below. The Shared Key must be same as
the Shared Secret which we configured for the device OmniSecuR1, in Cisco ACS.

You can use either TACACS+ or RADIUS as the AAA authentication protocol.

Below Cisco IOS CLI commands show how to configure a TACACS+ server IP address and Shared Key.

OmniSecuR1#configure terminal
OmniSecuR1(config)#tacacs-server host 192.168.10.50

OmniSecuR1(config)#tacacs-server key OmniSecu123

OmniSecuR1(config)#exit

OmniSecuR1#

Below Cisco IOS CLI commands show how to configure a RADIUS server IP address and Shared Key.

OmniSecuR1#configure terminal

OmniSecuR1(config)#aaa new-model

OmniSecuR1(config)#radius-server host 192.168.10.50

OmniSecuR1(config)#radius-server key OmniSecu123

OmniSecuR1(config)#exit

OmniSecuR1#

• Configure AAA Login Authentication on Cisco Routers or Switches using a AAA Authentication Method List. Cisco IOS
command syntax for creating a AAA Authentication Method List is shown below.

aaa authentication login {default | list-name} group {group-name | radius | tacacs+} [methods]

Use the following Cisco IOS CLI commands to create a default AAA Authentication Method List. The following default method
list specifies TACACS+ as the first authentication method option. If TACACS+ authentication failed, local user database will be
used.

OmniSecuR1#configure terminal

OmniSecuR1(config)#aaa authentication login default group tacacs+ local

OmniSecuR1(config)#exit

OmniSecuR1#

Default AAA authentication method list will be applied to all lines and interfaces by default. You can override the default method
list by defining another AAA Method Listwith a "list-name" and it applying to a line.

Below Cisco IOS CLI examples show how to define an AAA authentication method list with no authentication required and
applying it to line console.

• To define a AAA authentication method list "NOAUTH" with no authentication required, use below IOS CLI commands.

OmniSecuR1#configure terminal

OmniSecuR1(config)#aaa authentication login NOAUTH none

OmniSecuR1(config)#exit

• To apply the AAA authentication method list "NOAUTH" to line console, use below IOS CLI commands.

OmniSecuR1#configure terminal

OmniSecuR1(config)#line console 0
 OmniSecuR1(config-line)#login authentication NOAUTH

OmniSecuR1(config-line)#exit

OmniSecuR1(config)#exit

OmniSecuR1#

CCNP SWITCH 300-115 – Part 2.2 Security With

Cisco IOS AAA TACACS+ & RADIUS

Authentication Authorization and Accounting

You can manage user activity to and through a switch with authentication, authorization, and accounting (AAA) features. AAA uses
standardized methods to challenge users for their credentials before access is allowed or authorized. Accounting protocols also
can record user activity on a switch.

Simply put, think of AAA in the following manner:

 Authentication: Who is the user?

 Authorization: What is the user allowed to do?
 Accounting: What did the user do?

Background
You have several methods to manage users who might try to log in to one of your switches to perform some operation. At the most
basic level, you could avoid any authentication other than simple passwords configured on the switch console/vty lines. Authorization
can be equally simple: When users successfully log in, they are authorized for EXEC level privileges. By entering the correct enable
secret password, users can be authorized for a higher privilege level.

Under the simple scenario, if a user knows the correct password, he can connect to the switch. But who is that user? You might never
know who actually logged in and changed the configuration or rebooted the switch! Instead, you could use the username command to
configure individual usernames and passwords on the switch. That would solve the user anonymity problem, but your network might
consist of many administrative users
and many switches, requiring quite a bit of username configuration and maintenance.

A more scalable solution is to leverage AAA functions that are centralized, standardized, resilient, and flexible. A centralized
authentication server can contain a database of all possible users and their passwords, as well as policies to authorize user activities.
As users come and go, their accounts can be easily updated in one place. All switches and routers query the AAA server to get up-to-
date information about a user.

Cisco switches can use the following two protocols to communicate with AAA servers:

 TACACS+: A Cisco proprietary protocol that separates each of the AAA functions, communication is secure and encrypted over TCP
port 49.
 RADIUS: A standards-based protocol that combines authentication and authorization into a single resource; communication uses UDP
ports 1812 and 1813 (accounting), but is not completely encrypted.
Both TACACS+ and RADIUS are arranged as a client/server setup, where a switch acts as a client talking to a AAA server.
Below shows a simplified view of the process. In the AAA client role, a switch is often called a Network Access Device (NAD) or
Network Access Server (NAS). When a user tries to connect to a switch, the switch challenges the user for credentials, then passes the
credentials along to the AAA server. In simple terms, if the user passes authentication, the AAA server returns an “accept” message to
the switch. Otherwise, a “reject” message is returned.

Note: Cisco implements AAA services in its Identity Services Engine (ISE) and Cisco Secure Access Control Server (ACS).

Configuring Authentication
Switch access can be granted only after a user’s identity has been validated. User authentication is commonly used on switches and
routers to permit remote access to the network administration staff only. In this case, when someone uses Telnet or SSH to log in to a
switch, that individual is challenged to provide a username and password. The individual’s credentials are then submitted to a device
that can grant the user access.

TACACS+, administered through the AAA security services, can provide these services:

•Authentication—Provides complete control of authentication through login and password dialog, challenge and response, and
messaging support.
The authentication facility can conduct a dialog with the user (for example, after a username and password are provided, to challenge a
user with several questions, such as home address, mother’s maiden name, service type, and social security number). The TACACS+
authentication service can also send messages to user screens. For example, a message could notify users that their passwords must
be changed because of the company’s password aging policy.

•Authorization—Provides fine-grained control over user capabilities for the duration of the user’s session, including but not limited to
setting autocommands, access control, session duration, or protocol support. You can also enforce restrictions on what commands a
user can execute with the TACACS+ authorization feature.
•Accounting—Collects and sends information used for billing, auditing, and reporting to the TACACS+ daemon. Network managers
can use the accounting facility to track user activity for a security audit or to provide information for user billing. Accounting records
include user identities, start and stop times, executed commands (such as PPP), number of packets, and number of bytes.
The TACACS+ protocol provides authentication between the switch and the TACACS+ daemon, and it ensures confidentiality because
all protocol exchanges between the switch and the TACACS+ daemon are encrypted.

You need a system running the TACACS+ daemon software to use TACACS+ on your switch.

User authentication can be handled by several methods:

-Usernames and passwords configured locally on the switch
-One or more external Remote Authentication Dial-In User Service (RADIUS) servers
-One or more external Terminal Access Controller Access Control System + (TACACS+) servers

Any combination of these methods can be used. In fact, authentication must be defined by grouping the desired methods into a method
list. The list contains the types or protocols that will be used, in the sequential order that they will be tried.

To use authentication on a Catalyst switch, you must configure several things in the following order:

1. Enable AAA on the switch. All user authentication is handled locally by configuring usernames and passwords on the switch itself:

Switch(config)# aaa new-model

The new-model refers to the use of method lists, by which authentication methods and sources can be grouped or organized. The new
model is much more scalable than the “old model,” in which the authentication source was explicitly configured.

2. Define the source of authentication. You can compare user credentials against locally configured usernames and passwords, or
against a database managed by external RADIUS or TACACS+ servers. Use locally configured usernames and passwords as a last
resort, when no other authentication servers are reachable or in use on the network.

Switch(config)# username username password password

RADIUS or TACACS+ servers are defined in groups. First, define each server along with its secret shared password. This string is
known only to the switch and the server, and provides a key for encrypting the authentication session. Use one of the following global
configuration commands:

Switch(config)# radius-server host {hostname | ip-address} [key string]

Switch(config)# tacacs-server host {hostname | ip-address} [key string]

Define a group name that will contain a list of servers, using the following global configuration command:

Switch(config)# aaa group server {radius | tacacs+} group-name

Define each server of the group type with the following server-group configuration command:

Switch(config-sg)# server ip-address

You can define multiple RADIUS or TACACS+ servers by repeating the commands in this step.

3. Define a list of authentication methods to try. You can list switch login authentication methods by giving the method a descriptive
name or using the unnamed “default” method. List each method or protocol type in the order that it should be tried. If none of the
servers for the first method responds, the switch will try the servers in the next method listed.
Define a method list:
 Switch(config)# aaa authentication login {default | list-name} method1 [method2 ..

Here the methods refer to the following keywords:

 tacacs+: Each of the TACACS+ servers configured on the switch is tried, in the order that it was configured.
 radius: Each of the RADIUS servers configured on the switch is tried, in the order that it was configured.
 local: The user’s credentials are compared against all the username commands configured on the local switch.
 line: The line passwords authenticate any connected user. No usernames can be used.

Note: Add the local or line methods at the end of the list, as a last resort. This way, if all the RADIUS or TACACS+ servers are
unavailable or the switch is completely isolated from the rest of the network, a locally configured authentication method will eventually
be used. Otherwise, you will never be able to access the switch until at least one of the servers comes back online.

4. Apply a method list to a switch line.

First, select a line (console or vty for Telnet/SSH access) using the line line command. Then trigger the user authentication on that line
to use an AAA
method list:

Switch(config-line)# login authentication {default | list-name}

You can use the default method list only if one list is sufficient for all circumstances on the switch. Otherwise, if you have configured
named method lists, you can reference one of them here.

5. After authentication is configured on a switch, stay logged in on one session so that the authentication can be tested. If you
exit the configuration session, you will not be able to log in again if the authentication is misconfigured. While you stay logged in on the
original session, bring up a new Telnet session to the switch. If you can authenticate successfully, everything is configured properly.
Below example lists the commands necessary to configure a switch to use two TACACS+ servers to authenticate management users.
The servers are 192.168.10.10 and 192.168.10.11, also known as the AAA group named myauthservers.

AAA authentication group myauth is configured to try the TACACS+ server group. If none of the servers is available, local
authentication will be used instead. Notice that a username lastresort is configured for that case. Finally, the myauth method is used to
authenticate users on lines vty 0 through 15 for Telnet or SSH access.

Switch(config)# aaa new-model

Switch(config)# username lastresort password MySecretP@ssw0rd
Switch(config)# tacacs-server host 192.168.10.10 key t@c@csk3y
Switch(config)# tacacs-server host 192.168.10.11 key t@c@csk3y
Switch(config)# aaa group server tacacs+ myauthservers
Switch(config-sg)# server 192.168.10.10
Switch(config-sg)# server 192.168.10.11
Switch(config-sg)# exit
Switch(config)# aaa authentication login myauth group myauthservers local
Switch(config)# line vty 0 15
Switch(config-line)# login authentication myauth

Configuring Authorization
 After a user is authenticated, the switch allows access to certain services or switch commands based on the user’s privilege level.
Authenticated users are put at the EXEC level by default. Certain commands, such as show interface, are available at the EXEC level.
Other commands, such as configure terminal, are accessible only if the user is able to move into the privileged EXEC or enable mode.

Authorization provides a means of granting specific users the ability to perform certain tasks. As with authentication, authorization is
performed by querying external RADIUS or TACACS+ servers. If the authorization server has an entry for a user and a service
or command, the switch allows the user to perform that task.

Configure authorization by first defining any RADIUS or TACACS+ servers that will be used. These normally are defined as part of the
authentication configuration and do not need to be redefined for authorization.

Next, define a method list of authorization methods that will be tried in sequence using the following global configuration command:

Switch(config)# aaa authorization {commands | config-commands | configuration | exec | n

Here you specify the function or service needing authorization with one of the following keywords:

 commands: The server must return permission to use any switch command at any privilege level.
 config-commands: The server must return permission to use any switch configuration command
 configuration: The server must return permission to enter the switch configuration mode.
 exec: The server must return permission for the user to run a switch EXEC session. The server also can return the privilege level for
the user so that the user immediately can be put into privileged EXEC (enable) mode without having to type in the enable command.
 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 on the switch.

You can identify the method with a descriptive name (list-name) if you are configuring more than one list. Otherwise, a single unnamed
list is called the default list. Each authorization method then is listed in the order it will be tried. The methods can be any of the following
values:

 group group-name: Requests are sent to the servers in a specific group.

 group {radius | tacacs+}: Requests are sent to all servers of this type.
 if-authenticated: Requests are granted if the user already is authenticated.
 none: No external authorization is used; every user is authorized successfully.

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

Next, you can apply an authorization method list to a specific line on the switch. Users accessing the switch through that line will be
subject to authorization. Use the following line configuration command syntax:

Switch(config-line)# authorization {commands level | exec | reverse-access} {default | list-name}

If you do not use this command, the default group is used for all lines. To configure a switch to use AAA authorization for all lines, you
enter the following:
 Switch(config)# aaa authorization exec default group myauthservers none

The AAA servers contained in the group myauthservers are used as a default method to allow authenticated users into the EXEC mode
or any other privilege level granted.

Verify TACACS+ Configuration

To verify TACACS+ statistics, use:

Switch# show tacacs

Configuring Accounting
The AAA accounting feature tracks the services that users are accessing and the amount of network resources that they are
consuming. When AAA accounting is enabled, the switch reports user activity to the TACACS+ security server in the form of accounting
records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. This data can then
be analyzed for network management, client billing, or auditing.

This accounting information can be collected by RADIUS and TACACS+ servers. Again, the RADIUS and TACACS+ servers must
already be configured and grouped as part of the authentication configuration.

As usual, you must define a method list giving a sequence of accounting methods by using the following global configuration command
syntax:

Switch(config)# aaa accounting {system | exec | commands level} {default | list-name} {start-stop |
stop-only | wait-start | none} method1 [method2...]

The function triggering the accounting can be one of the following keywords:

 system: Major switch events such as a reload are recorded.

 exec: User authentication into an EXEC session is recorded, along with information about the user’s address and the time and duration
of the session.
 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 be sent to the accounting server using the following keywords:
■ start-stop: Events are recorded when they start and stop.
■ stop-only: Events are recorded only when they stop.
■ none: No events are recorded.

Next, you can apply an accounting method list to a specific line on the switch. Users accessing the switch through that line will have
their activity recorded. Use the following line-configuration command to accomplish this:

Switch(config-line)# accounting {commands level | connection | exec} {default | list-name}

If you do not use this command, the default group will be used for all lines. Below, AAA accounting is configured for all lines on the
switch, using the AAA servers contained in the myauthservers group (in previous example). 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 level 15 (enable mode) will
be recorded, too.

Switch(config)# aaa accounting exec default start-stop group myauthservers

Switch(config)# aaa accounting commands 15 default start-stop group myauthservers

Local privilege authorization fallback

The following examples show how to use a TACACS+ server to authorize the use of network services, including PPP and ARA. If the
TACACS+ server is not available or an error occurs during the authorization process, the fallback method (none) is to grant all
authorization requests:

Switch# aaa authorization network default group tacacs+ none