Basic Aaa Configuration On Ios.docx

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. 2. 3. 4.

Enable the "new model" of AAA. Configure the server(s) to be used for AAA (e.g. TACACS+ servers). Define authentication and authorization method lists. 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-todate 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-ornothing 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