Scenario 8-2: Enhancing Security by Using AAA

In this scenario, you secure both a Catalyst CatOS-based switch and an IOS-based switch. In doing so, you increase the security of each device and consequently the network. This exercise builds on the previous scenarios by including the configuration of AAA.

Scenario Exercise

Figure 8-3 illustrates the topology used for this scenario. Corporation XYZ requires their existing switches to be secured using best practices. Corporation XYZ is about to acquire a larger corporation and needs to add new switches to the network. A new CiscoSecure ACS 3.2 server has been installed to allow Corporation XYZ to evaluate the use of both TACACS+ and RADIUS to provide a suitable access control model. It is through the configuration of AAA that the ACS server can be used.

Scenario Objectives

The scenario objectives are as follows:

• Configure security server support

• Configure AAA authentication

• Configure AAA authorization

• Configure AAA accounting

Additional Equipment Needed

Building on the previous scenario, only the following additional equipment is required to complete the following steps:

• A server with CiscoSecure ACS v3.2 software installed. CiscoSecure ACS software requires Windows 2000 Server with Service Pack 3 installed and Internet Explorer 6.0 SP1.
  
  

Scenario Planning

Planning AAA can seem reasonably complex at first, with many options available for authentication, authorization, and accounting. Many AAA configuration options are designed towards Point-to-Point Protocol (PPP) access (such as dial-up access to an Internet service provider, ISP), so the number of options that you actually need to secure network devices is reduced.

The first step in configuring any AAA services is to establish a relationship with a security server on the network. The TACACS+ and RADIUS security server protocols require the IP address of the security server and a shared secret key (password) be defined on the switch. The security server must also be configured with the IP address of the switch and must share the same shared secret key to successfully communicate. Once you have configured security server support, you are ready to complete the implementation of AAA.

Planning Authentication

The following services can be authenticated on both CatOS and IOS:

• Login This refers to a user attempting to initially login to the switch via Telnet or the console.

• Enable This refers to a user attempting to login to enable mode on the switch via Telnet or the console.

For example, login access is required to establish a user mode connection to a switch, while enable access is required to establish privileged access to the switch.

Planning Authorization

The following services can be authorized on both CatOS and Cisco IOS:

• Exec This refers to a user attempting to start an exec process. An exec process is basically the shell (or command-line interface (CLI)) you use to input commands from a console or Telnet connection.

• Enable (CatOS only) This refers to a user attempting to access privileged mode (enable mode). This occurs when a user executes the enable command in user mode.

• Commands All commands that are executed can be authorized by the security server. This allows restricted use of dangerous commands such as erase or copy.

Authorization requires that a user be authenticated so that the switch can query the security server with a username and type of service required.

Planning Accounting

The following events can be accounted for on both CatOS and Cisco IOS:

• Exec Records are generated for each exec process (e.g., console or telnet session) and include the user who invoked the process and the duration of the session.

• System Records are generated every time a non-user system event occurs (such as a system reset).

• Command Records are generated every time a command is issued. This enables you to see exactly what a user did during their exec session

• Connect Records are generated every time a user running an exec session attempts a connection (such as Telnet or rlogin) to a remote device.

When you configure accounting, you also specify when to create accounting records. The following options are available:

• Start-Stop Records are generated at both the start and completion of each event.

• Stop-Only Records are generated at the completion of each event.

• Wait-Start (Cisco IOS only) Records are generated at both the start and completion of each event. However, the switch does not allow the service to commence until an accounting acknowledgement is received from the security server.

NOTE

Wait-Start should be used with great caution. For example, if Wait-Start is configured for EXEC sessions, you will not be able to log on to the network device if the AAA server is unavailable for any reason.

Command Syntax

The following sections describe the commands used for CatOS and Cisco IOS in this scenario.

CatOS Command Syntax

The following new CatOS commands are introduced in this scenario:

• The set radius command

• The set tacacs command

• The set authentication command

• The set authorization command

• The set accounting command

The set radius Command Syntax

The set radius server command is used to define the IP address of a RADIUS server:

 set radius server ip-address [auth-port port] [acct-port port] [primary] 

The auth-port and acct-port keywords specify the server User Datagram Protocol (UDP) ports that should be used for authentication and accounting communications (the various RADIUS products available differ; by default, ports 1812 and 1813 are used). If you specify the primary keyword and have multiple RADIUS servers defined, then this RADIUS server is contacted first. You can have up to three RADIUS servers defined. You must also specify a RADIUS secret key by using the set radius key command:

 set radius key secret 

This command sets the RADIUS key for all configured RADIUS servers.

The set tacacs Command Syntax

The set tacacs server command is used to define the IP address of a TACACS+ server:

 set tacacs server ip-address [primary] 

The primary keyword specifies that this TACACS+ server should always contacted first if multiple TACACS+ servers are defined. You can have up to three TACACS+ servers configured. You must also specify a TACACS+ secret key by using the set tacacs key command:

 set tacacs key secret 

This command sets the TACACS+ key for all configured TACACS+ servers.

The set authentication Command Syntax

To configure authentication, you use the set authentication command:

 set authentication {login | enable} {radius | tacacs | kerberos}   enable [all | console | telnet | http] [primary] 

You can specify the authentication method for either login authentication (access to exec mode) or enable authentication (access to privileged configuration mode). You then specify the use of RADIUS or TACACS+ and can apply the configuration to whichever management interfaces you require. The primary keyword is used when you have multiple authentication methods (e.g., using TACACS+ and RADIUS simultaneously), and you want to specify which authentication method is attempted first. You can also disable local authentication by using the following command:

 set authentication {login | enable} local disable   [console | telnet | http | all] 

WARNING

Be careful when disabling local authentication. If you disable local authentication for every management interface, if your security server is down you will be unable to access the switch. A common practice is to disable local authentication for Telnet access, but leave it enabled for console access.

The set authorization Command Syntax

To configure authorization, you use the set authorization command. To configure authorization for exec mode and/or enable mode access use the following syntax:

 set authorization {enable | exec} enable option fallback   [both | console | telnet] 

The option parameter specifies which security server protocol to use. Because RADIUS authorization is integrated with the authentication process, only tacacs is a valid option here. The fallback parameter specifies what action you should take if communication with the TACACS+ server fails (for example, you can specify none, meaning the service requested is granted if the TACACS+ server is down). Valid fallback options are tacacs+, deny, if-authenticated, and none.

To configure authorization for commands that can be executed use the following syntax:

 set authorization commands enable {config | enable | all}   option fallback [both | console | telnet] 

Using the config parameter limits command authorization to configuration commands only (i.e., show commands do not need to be authorized).

The set accounting Command Syntax

To configure accounting, you use the set accounting command. To configure accounting for connect, exec, and system events, use the following syntax:

 set accounting {connect | exec | system} enable   {start-stop | stop-only} {tacacs+ | radius} 

To configure accounting for command events, use the following syntax:

 set accounting commands {config | enable | all} [stop-only] tacacs+ 

Notice that your only security server protocol option is tacacs+, because RADIUS does not support command authorization and accounting.

Cisco IOS Command Syntax

The following new Cisco commands are introduced in this scenario:

• The radius-server command

• The tacacs-server command

• The aaa authentication command

• The aaa authorization command

• The aaa accounting command

The radius-server Command Syntax

Before configuring RADIUS support, you must enable AAA by using the aaa new-model global configuration mode command:

 aaa new-model 

The radius-server global configuration command can then be used to configure the IP address of the RADIUS server:

 radius-server host ip-address [auth-port port] [acct-port port] [key secret] 

If you do not specify a key using the optional key keyword, you must specify a RADIUS secret key by using the radius-server key global configuration command, as shown here:

 radius-server key secret 

This command sets the RADIUS key for all RADIUS servers defined (unless a host has a specific key configured via the radius-server host command).

The tacacs-server Command Syntax

The tacacs-server global configuration command is used to define the IP address of a TACACS+ server:

 tacacs-server host ip-address 

You must also specify a TACACS+ secret key by using the tacacs-server key global configuration command:

 tacacs-server key secret 

This command sets the TACACS+ key for all configured TACACS+ servers. The key can optionally be configured on a per-server basis using the key parameter to the tacacs-server host global configuration command.

The aaa authentication Command Syntax

Before configuring AAA on Cisco IOS, you must enable AAA support explicitly using the aaa new-model command:

 aaa new-model 

To configure authentication for login (exec) access, you use the aaa authentication login global configuration command:

 aaa authentication login {default | list} method1 [method2..] 

The preceding command creates a profile that can be applied to different interfaces (e.g., a console port), allowing you to create different policies for different access methods. The default keyword specifies the default login authentication profile that is used for all management interfaces. You can specify multiple methods of authentication (e.g., RADIUS, TACACS+, line, none). To use a custom profile that you have created, you must bind the profile to the management interface that you want to control. The login authentication line configuration mode command is used to bind a profile to a management interface, as shown in Example 8-33

Example 8-33. Creating and Applying an AAA Authentication Profile

 Switch(config)# aaa authentication login PROFILE-A radius line Switch(config)# line con 0 Switch(config-line)# login authentication PROFILE-A 

In Example 8-33, an AAA authentication profile is created called PROFILE-A that uses RADIUS authentication as its primary method, and line authentication (i.e., the password assigned to the line to which access is being attempted) is used if the configured RADIUS server is down. The profile is then bound to the console port, meaning this profile is applied when access is attempted from the console port.

WARNING

When you enable AAA by using the aaa new-model command, the default method of login authentication for Telnet access is to use the local method. The local method requires users to be defined locally using the username command. If no users are defined when you turn on AAA, you will be unable to gain Telnet access to the switch. A good rule of thumb is to set the default authentication method as the line method, which uses the line password (e.g., the vty password) as the default mechanism.

To configure authentication for enable mode access, you use the aaa authentication enable global configuration command:

 aaa authentication enable default method1 [method2..] 

You can create only a single (the default) enable authentication profile, and you do not need to bind this to any management interface because enable mode access is independent from a management interface.

The aaa authorization Command Syntax

To configure authorization, you use the aaa authorization global configuration command:

 aaa authorization {network | exec | commands level} {default | list}   method1 [method2..] 

Similar to authentication, the preceding command creates a profile that can be applied to different interfaces. You can control authorization for either exec access (i.e., starting a command session on the switch), or you can control authorization for commands entered at a specific privilege level. Example 8-34 shows a sample AAA authorization configuration:

Example 8-34. Creating and Applying an AAA Authorization Profile

 Switch(config)# aaa authorization exec PROFILE-EXEC radius none Switch(config)# line vty 0 4 Switch(config-line)# authorization exec PROFILE-EXEC 

In Example 8-34, an AAA authorization profile called PROFILE-EXEC is created that authorizes exec access using RADIUS. If the RADIUS server is down, the switch permits the access as indicated by the use of the none keyword.

TIP

When configuring both AAA authentication and authorization, it is good practice to configure backup methods, as shown in Example 8-34. It is important to understand that these methods are invoked only if the primary security server is down. If the primary security server rejects a request, the switch rejects the requested access (and does not try the second method).

The aaa accounting Command Syntax

To configure accounting, you use the aaa accounting global configuration command:

 aaa accounting {network | exec | connection | system | commands level}   {default | list} {start-stop | stop-only | wait-start}   method1 [method2..] 

Similar to both authentication and authorization, the preceding command creates a profile that can be applied to different interfaces. You can specify accounting for exec, connection, system, or command events. You can also control when the accounting events are created.

Configuration Tasks

In this scenario, you perform the following tasks:

• Step 1 Configuring the CiscoSecure server for AAA support

• Step 2 Configuring each switch for AAA support

• Step 3 Confirming your AAA configuration

Step 1Configuring the CiscoSecure Server for AAA Support

This scenario assumes that you have installed CiscoSecure ACS and performed preliminary switch configurations from Scenario 8-1. CiscoSecure ACS 3.2 must be installed on a Windows 2000 Server.

Once you have installed CiscoSecure ACS, you need to create an AAA client definition for each switch and then create user accounts for network administrators.

Step 1.	Start the web-based CiscoSecure administration application by opening the URL http://127.0.0.1:2002 from the ACS server.
Step 2.	Click on the Network Configuration button and click on the Add Entry button, as shown in Figure 8-4. Figure 8-4. Creating an AAA Client
Step 3.	Enter the appropriate parameters for XYZSW1, using a secret key of cisco123 and ensuring RADIUS (Cisco IOS/PIX) is selected as the authentication protocol. Once complete, click the Submit + Restart button, as shown in Figure 8-5. Figure 8-5. Creating an AAA Client
Step 4.	Repeat Steps 2 and 3 for XYZSW2, except ensure that TACACS+ is selected as the authentication protocol. The AAA Client list should now contain entries for both XYZSW1 and XYZSW2, as shown in Figure 8-6. Figure 8-6. Verifying AAA Clients
Step 5.	Click on the User Setup button, and enter the username "administrator" in the User field. Click on the Add/Edit once complete as shown in Figure 8-7. Figure 8-7. Creating a User
Step 6.	In the User Setup page, scroll down to the Password Authentication section, configure a password of "password," and then click the Submit button as shown in Figure 8-8. Figure 8-8. Configuring a User Password

Step 2Configuring Each Switch for AAA Support

In this section, you configure each switch to use AAA. The following actions are required:

• Configuring the appropriate security server protocol support

• Configuring each switch to use AAA for authentication

• Configuring each switch to use AAA for management access authorization

• Configuring each switch to use AAA for management access accounting

Configuring the Appropriate Security Server Protocol Support

In this section, you configure both RADIUS (on XYZSW1) and TACACS+ (on XYZSW2) support.

Step 1.

Configure RADIUS support on XYZSW1 by specifying the RADIUS server IP address (192.168.1.10) and RADIUS server secret key (cisco123), as shown in Example 8-35. Example 8-35. Configuring RADIUS Support on XYZSW1 XYZSW1> (enable) set radius server 192.168.1.10 192.168.1.10 with auth-port 1812 acct-port 1813 added to radius server table as primary server. XYZSW1> (enable) set radius key cisco123 Radius key set to cisco123

Step 2.

Configure TACACS+ support on XYZSW2 by specifying the TACACS+ server IP address (192.168.1.10) and TACACS+ server secret key (cisco123), as shown in Example 8-36. Example 8-36. Configuring TACACS+ Support on XYZSW2 XYZSW2(config)# tacacs-server host 192.168.1.10 XYZSW2(config)# tacacs-server key cisco123

Configuring Each Switch to Use AAA for Authentication

In this section, you learn how to use AAA authentication for management access on each switch.

Step 1.

Configure XYZSW1 to use RADIUS authentication and authorization for Telnet logins only, as shown in Example 8-37.

Example 8-37. Configuring RADIUS Authentication for Telnet Login on XYZSW1

 XYZSW1> (enable) set authentication login radius enable telnet radius login authentication set to enable for telnet session. 

In Example 8-37, the use of the telnet keyword enables RADIUS authentication for Telnet access only.

Step 2.

Configure XYZSW2 to use TACACS+ authentication for Telnet logins only, as shown in Example 8-38.

Example 8-38. Configuring TACACS+ Authentication for Telnet Login on XYZSW2

 XYZSW2(config)# aaa new-model XYZSW2(config)# aaa authentication login default line XYZSW2(config)# aaa authentication login TELNET group tacacs+ line XYZSW2(config)# line vty 0 4 XYZSW2(config-line)# login authentication TELNET XYZSW2(config)# line con 0 XYZSW2(config-line)# password cisco XYZSW2(config-line)# end 

In Example 8-38, notice that you have to globally enable AAA by using the aaa new-model command. The next command tells the switch to use the locally configured line password as the default login authentication mechanism. Next, you create a login authentication profile called TELNET, which uses TACACS+ as the authentication method, and uses the line authentication method as a backup in case the TACACS+ server is down. The last step is to apply the profile (TELNET) to the vty lines, which then enables TACACS+ authentication for Telnet access.

WARNING

Be careful when setting the default authentication mechanism as the line password. If your console port does not have a line password configured, access is denied to the console port. Ensure that you set a line password for the console port if you are using line password as the default authentication mechanism.

Configuring Each Switch to Use AAA for Management Access Authorization

In this section, you learn how to use AAA authorization to allow enable mode management access on each switch and to deny the use of the erase command on XYZSW2 using TACACS+.

NOTE

You can enable mode authorization with two approaches. The first is to apply enable mode authentication when an authenticated user types in the enable command. The second is to authorize enable mode access when a user first attempts management access (e.g., authenticates at a Telnet prompt), which takes the user straight to enable mode if authenticated and authorized. TACACS+ supports both of these methods, while RADIUS supports only the second method (RADIUS does support the first, but not very well). For this reason, we look exclusively at the second method of enable mode authorization.

Step 1.	On the CiscoSecure ACS server, click on the Group Setup button, ensure the Default Group is selected (which contains the user administrator), and click on the Edit Settings button, as shown in Figure 8-9. Figure 8-9. Configuring Group Settings
Step 2.	On the Group Setup page, scroll down to the TACACS+ Settings section and enable the Shell (exec) setting and configure Privilege level to be 15 (enable mode), as shown in Figure 8-10. This authorizes the user for enable mode (privilege level 15) access via TACACS+. Figure 8-10. Enabling TACACS+ Enable Mode Authorization
Step 3.	On the Group Setup page, scroll down to the IETF RADIUS Attributes section and enable the [006] Service-Type attribute, changing the attribute value to Administrative. This authorizes the user for enable mode access via RADIUS. Once complete, click on the Submit + Restart button to apply the configuration, as shown in Figure 8-11. Figure 8-11. Enabling RADIUS Enable Mode Authorization
Step 4.	Remaining on the Group Setup page, scroll down to the Shell Command Authorization Set section and enable the Per Group Command Authorization setting. Configure the Unmatched Cisco IOS commands setting to Permit, and then disable the erase command, as shown in Figure 8-12. This prevents the user from using the erase command. Figure 8-12. Enabling TACACS+ Command Authorization
Step 5.	Configure XYZSW2 to use TACACS+ authorization for enable mode access, as shown in Example 8-39. Example 8-39. Configuring TACACS+ Authorization for Enable Mode Access on XYZSW2 XYZSW2(config)# aaa authorization exec TELNET group tacacs+ none XYZSW2(config)# line vty 0 4 XYZSW2(config-line)# authorization exec TELNET XYZSW2(config-line)# end

In Example 8-39, you use the exec keyword to tell the switch to contact the TACACS+ server for authorization when a user starts an exec process. Notice the use of the none keyword to ensure the user can at least get user mode access if the TACACS+ server is down (if you omitted this and the TACACS+ server is down, you would not be able to access the switch via Telnet).

Step 6.

Configure XYZSW2 to use TACACS+ authorization for commands, as shown in Example 8-40.

Example 8-40. Configuring TACACS+ Authorization for Commands on XYZSW2

 XYZSW2(config)# aaa authorization commands 15 TELNET group tacacs+ none XYZSW2(config)# line vty 0 4 XYZSW2(config-line)# authorization commands TELNET XYZSW2(config-line)# end 

In Example 8-40, you use the commands keyword to tell the switch to contact the TACACS+ server for authorization of commands when in enable mode (privilege level 15). Notice that this authorization is used only for Telnet access because we have created a specific AAA profile (TELNET) and applied it only to the vty lines.

Configuring Each Switch to Use AAA for Management Access Accounting

In this section, you learn how to use AAA accounting to audit exec events (e.g., starting a Telnet session) and command events (invoked each time a command is issued).

Step 1.

On XYZSW1, configure AAA accounting for exec events (audit both the start and stop of each event), as shown in Example 8-41. Example 8-41. Configuring AAA Accounting on XYZSW1 XYZSW1> (enable) set accounting exec enable start-stop radius Accounting set to enable for exec events in start-stop mode.

Step 2.

On XYZSW2, configure AAA accounting for exec events (audit both the start and stop of each event) and enable mode command events (ensure you can contact the TACACS+ server before allowing commands to proceed) for Telnet sessions, as shown in Example 8-42. Example 8-42. Configuring AAA Accounting on XYZSW2 XYZSW2(config)# aaa accounting exec TELNET start-stop group tacacs+ XYZSW2(config)# aaa accounting commands 15 TELNET-CMD wait-start group tacacs+ XYZSW2(config)# line vty 0 4 XYZSW2(config-line)# accounting exec TELNET XYZSW2(config-line)# accounting commands 15 TELNET-CMD XYZSW2(config)# end

You create two separate profiles for each event category you are accounting and then apply the profiles to the vty lines. Notice the use of the wait-start keyword to ensure enable mode command events are always audited.

Step 3.

Now you are ready to test your accounting configuration. From Host A, make a Telnet connection to XYZSW1 logging in as the administrator user you created earlier, leaving the session open for 30 seconds or so, and then disconnect. On the CiscoSecure ACS server, click on the Reports and Activity button, then click the RADIUS Accounting hyperlink, and then click the RADIUS Accounting active.csv hyperlink. Figure 8-13 shows the accounting information that you should see.

Figure 8-13. Viewing RADIUS Accounting Information

Figure 8-13 shows a start and stop record around 09:09 a.m. The Service Type column indicates this is a NAS Prompt (exec) event, and the Acct-Session-Time column for the stop record indicates the session lasted for 35 seconds. The User-Name column indicates that the user administrator established the exec connection.

Step 4.

From Host A, make a Telnet connection to XYZSW2, perform some minor configuration changes (e.g., change an interface description), and then disconnect. On the CiscoSecure ACS server, click on the Reports and Activity button, then click the TACACS+ Accounting hyperlink, and then click the TACACS+ Accounting active.csv hyperlink. Figure 8-14 shows the accounting information that you should see.

Figure 8-14. Viewing TACACS+ Accounting Information

Figure 8-14 shows a start and stop record around 09:18 a.m. The Service column indicates this is a shell (exec) event, and the elapsed time column for the stop record indicates the session lasted for 10 seconds. The User-Name column indicates that the user administrator established the exec connection, and the Caller-Id column indicates that the exec session was initiated from 192.168.1.100 (Host A).

Notice that no events are related to commands in Figure 8-14. This is because command accounting records are stored in the TACACS+ Administration database on CiscoSecure ACS. On the CiscoSecure ACS server, click on the Reports and Activity button, then click the TACACS+ Administration hyperlink, and then click the TACACS+ Administration active.csv hyperlink. Figure 8-15 shows the accounting information that you should see.

Figure 8-15. Viewing TACACS+ Administration Information

Figure 8-15 shows three command events that occurred around 09:18 a.m. The events indicate that the user administrator configured a description of TEST for interface fastEthernet0/1. The NAS-IP-Address column indicates the configuration was performed on 192.168.1.2 (XYZSW2).

Step 3Confirming Your AAA Configuration

Now it is time to test your configuration by attempting Telnet access to both switches and requesting various services.

Step 1.

From Host A, attempt a Telnet connection to XYZSW1. Enter in the administrator credentials (password = password), as shown in Example 8-43.

Example 8-43. Testing Telnet Access to XYZSW1

 C:\> telnet 192.168.1.1 Cisco Systems, Inc. Console Username: administrator Password: ******** XYZSW1> (enable) 

Notice that once you have successfully authenticated, you are taken directly to enable mode on the switch. This is because the RADIUS server returned the 006 Service-Type attribute with a value of Administrative, which tells the switch to grant the user enable mode access.

Step 2.

From Host A, attempt a Telnet connection to XYZSW2. Enter in the administrator credentials (password = password), as shown in Example 8-44.

Example 8-44. Testing Telnet Access to XYZSW2

 C:\> telnet 192.168.1.2 Username: administrator Password: ******** XYZSW2# 

Again, you have been granted enable mode access directly. This is because you configure the switch to authorize exec access, and the TACACS+ server authorized the user with a privilege level of 15 (enable mode).

Step 3.

In the Telnet session established in Step 2, try entering configuration mode, execute a few commands, and then exit back to enable mode. Then attempt to erase the startup configuration of the switch, as shown in Example 8-45.

Example 8-45. Testing Command Authorization on XYZSW2

 XYZSW2# configure terminal XYZSW2(config)# interface fastEthernet0/10 XYZSW2(config-if)# description Just Mucking around here… XYZSW2(config-if)# end XYZSW2# erase startup-config Command authorization failed. 

In Example 8-45, notice how you can execute normal configuration commands, but once you attempt to execute the erase command, you cannot. This is because every time the user executes a command, the switch contacts the TACACS+ server to authorize the command and we had previously denied it.

Step 4.

(Optional) Access each switch via the console port. Notice that you do not need to enter user credentials (only a line password or local username authentication), and you can perform all commands. This is because you have applied the AAA configurations only for Telnet access.