Table Of Contents
Configuring the Switch Access Using AAA
Understanding How Authentication Works
Authentication Overview
Understanding How Login Authentication Works
Understanding How Local Authentication Works
Understanding How Local User Authentication Works
Understanding How TACACS+ Authentication Works
Understanding How RADIUS Authentication Works
Understanding How Kerberos Authentication Works
Using a Kerberized Login Procedure
Using a Non-Kerberized Login Procedure
Configuring Authentication on the Switch
Authentication Default Configuration
Authentication Configuration Guidelines
Configuring Login Authentication
Setting Authentication Login Attempts on the Switch
Setting Authentication Login Attempts for the Privileged Mode
Configuring Local Authentication
Enabling Local Authentication
Setting the Login Password
Setting the Enable Password
Disabling Local Authentication
Recovering a Lost Password
Configuring Local User Authentication
Creating a Local User Account
Enabling Local User Authentication
Disabling Local User Authentication
Deleting a Local User Account
Configuring TACACS+ Authentication
Specifying TACACS+ Servers
Enabling TACACS+ Authentication
Specifying the TACACS+ Key
Specifying the TACACS+ Timeout Interval
Specifying the TACACS+ Login Attempts
Enabling TACACS+ Directed Request
Disabling TACACS+ Directed Request
Clearing TACACS+ Servers
Clearing the TACACS+ Key
Disabling TACACS+ Authentication
Configuring RADIUS Authentication
Specifying RADIUS Servers
Specifying the RADIUS Key
Enabling RADIUS Authentication
Specifying the RADIUS Timeout Interval
Specifying the RADIUS Retransmit Count
Specifying the RADIUS Dead Time
Specifying Optional Attributes for RADIUS Servers
Clearing RADIUS Servers
Clearing the RADIUS Key
Disabling RADIUS Authentication
Configuring Kerberos Authentication
Configuring a Kerberos Server
Enabling Kerberos
Defining the Kerberos Local Realm
Specifying a Kerberos Server
Mapping a Kerberos Realm to a Host Name or DNS Domain
Copying SRVTAB Files
Deleting an SRVTAB Entry
Enabling Credentials Forwarding
Disabling Credentials Forwarding
Defining and Clearing a Private DES Key
Encrypting a Telnet Session
Displaying and Clearing Kerberos Configurations
Authentication Example
Understanding How Authorization Works
Authorization Overview
Authorization Events
TACACS+ Primary Options and Fallback Options
TACACS+ Command Authorization
RADIUS Authorization
Configuring Authorization on the Switch
TACACS+ Authorization Default Configuration
TACACS+ Authorization Configuration Guidelines
Configuring TACACS+ Authorization
Enabling TACACS+ Authorization
Disabling TACACS+ Authorization
Configuring RADIUS Authorization
Enabling RADIUS Authorization
Disabling RADIUS Authorization
Authorization Example
Understanding How Accounting Works
Accounting Overview
Accounting Events
Specifying When to Create Accounting Records
Specifying RADIUS Servers
Updating the Server
Suppressing Accounting
Configuring Accounting on the Switch
Accounting Default Configuration
Accounting Configuration Guidelines
Configuring Accounting
Enabling Accounting
Disabling Accounting
Accounting Example
Configuring the Switch Access Using AAA
This chapter describes how to configure authentication, authorization, and accounting (AAA) to monitor and control access to the command-line interface (CLI) on the Catalyst 6500 series switches.
Note
For complete syntax and usage information for the commands used in this chapter, refer to the Catalyst 6500 Series Switch Command Reference publication.
Note
See Chapter 36, "Configuring 802.1x Authentication"for information on configuring 802.1x authentication to restrict unauthorized devices from connecting to a LAN through publicly accessible ports.
Note
See Chapter 35, "Configuring Port Security" for information on configuring ports to allow or restrict traffic based on host MAC addresses.
This chapter consists of these sections:
•
Understanding How Authentication Works
•
Configuring Authentication on the Switch
•
Authentication Example
•
Understanding How Authorization Works
•
Configuring Authorization on the Switch
•
Authorization Example
•
Understanding How Accounting Works
•
Configuring Accounting on the Switch
•
Accounting Example
Understanding How Authentication Works
These sections describe how the different authentication methods work:
•
Authentication Overview
•
Understanding How Login Authentication Works
•
Understanding How Local Authentication Works
•
Understanding How Local User Authentication Works
•
Understanding How TACACS+ Authentication Works
•
Understanding How RADIUS Authentication Works
•
Understanding How Kerberos Authentication Works
Authentication Overview
You can configure any combination of these authentication methods to control access to the switch:
•
Login authentication
•
Local authentication
•
RADIUS authentication
•
TACACS+ authentication
•
Kerberos authentication
Note
Kerberos authentication does not work if TACACS+ is used as the authentication method.
When you enable local authentication with one or more other authentication methods, local authentication is always attempted last. However, you can specify different authentication methods
for console and Telnet connections. For example, you might use local authentication for console connections and RADIUS authentication for Telnet connections.
Understanding How Login Authentication Works
Login authentication increases the security of the system by keeping unauthorized users from guessing the password. The user is limited to a specific number of attempts to successfully log in to the switch. If the user fails to authorize the password, the system delays accesses and captures the user ID and the IP address of the station in the syslog and in the SNMP trap.
The maximum number of login attempts is configurable from the CLI and SNMP through the set authentication login attempt count command. Use the set authentication enable attempt count command to set login limits for accessing enable mode. The configurable range is three (default) to ten tries. Setting the login authentication limit to zero (0) disables this function.
All authentication methods are supported (RADIUS, TACACS+, Kerberos, or local).
You can configure the lockout (delay) time from the CLI and SNMP through the set authentication login lockout time command. Use the set authentication enable lockout time command to set a delay time for accessing enable mode. The configurable range is 30-43200 seconds. Setting the lockout time to zero (0) disables this function.
If you are locked out at the console, the console does not allow you to log in during that lockout time. If you are locked out with a Telnet session, the connection closes when the time limit is reached. The switch closes any subsequent access from that station during the lockout time and provides an appropriate notice.
Understanding How Local Authentication Works
Local authentication uses locally configured login and enable passwords to authenticate login attempts. The login and enable passwords are local to each switch and are not mapped to individual usernames.
By default, local authentication is enabled. You can disable local authentication only after enabling one or more of the other authentication methods. However, when local authentication is disabled, if you disable all other authentication methods, local authentication is reenabled automatically.
You can enable local authentication and one or more of the other authentication methods at the same time. The switch attempts local authentication only if the other authentication methods fail.
Understanding How Local User Authentication Works
Local user authentication uses local user accounts and passwords that you create to validate the login attempts of local users. Each switch can have a maximum of 25 local user accounts. Before you can enable local user authentication, you must define at least one local user account.
You set up local user accounts by creating a unique username and password combination for each local user. Each username must be fewer than 65 characters and can be any alphanumeric character (at least one character must be alphabetic).
You configure each local user account with a privilege level; the valid privilege levels are 0 or 15. The privilege level assigned to a username and password combination designates whether a user will be logged in to normal or privileged mode after successful authentication. A user with a privilege level of 0 is automatically logged in to normal mode, and a user with a privilege level of 15 is logged in to privileged mode. A user with a privilege level of 0 can still access privileged mode by entering the enable command and password combination.Once a local user is logged in, only the commands that are available for that privilege level can be displayed.

Note
If you are running a CiscoView image or are logging in using an HTTP login, the system completes its initial authentication using the username and password combination. You can enter privileged mode by either providing the privilege password or using the username and password combination, provided that the local user has a privilege level of 15.
Understanding How TACACS+ Authentication Works
TACACS+ controls access to network devices by exchanging Network Access Server (NAS) information between a network device and a centralized database to determine the identity of a user or an entity. TACACS+ is an enhanced version of TACACS, a User Datagram Protocol (UDP)-based access-control protocol that is specified by RFC 1492. TACACS+ uses TCP to ensure reliable delivery and encrypt all traffic between the TACACS+ server and the TACACS+ daemon on a network device.
TACACS+ works with many authentication types, including fixed password, one-time password, and challenge-response authentication. TACACS+ authentication usually occurs in these instances:
•
When you first log on to a machine
•
When you send a service request that requires privileged access
When you request privileged or restricted services, TACACS+ encrypts your user password information using the MD5 encryption algorithm and adds a TACACS+ packet header. This header information identifies the packet type being sent (for example, an authentication packet), the packet sequence number, the encryption type used, and the total packet length. The TACACS+ protocol then forwards the packet to the TACACS+ server.
A TACACS+ server can provide authentication, authorization, and accounting functions. These services, while all part of TACACS+, are independent of one another, so a given TACACS+ configuration can use any or all of the three services.
When the TACACS+ server receives the packet, it does the following:
•
Authenticates the user information and notifies the client that authentication has either passed or failed.
•
Notifies the client that authentication will continue and that the client must provide additional information. This challenge-response process can continue through multiple iterations until authentication either passes or fails.
You can configure a TACACS+ key on the client and server. If you configure a key on the switch, it must be the same as the one that is configured on the TACACS+ servers. The TACACS+ clients and servers use the key to encrypt all transmitted TACACS+ packets. If you do not configure a TACACS+ key, packets are not encrypted.
You can configure the following TACACS+ parameters on the switch:
•
Enable or disable TACACS+ authentication to determine if a user has permission to access the switch
•
Enable or disable TACACS+ authentication to determine if a user has permission to enter privileged mode
•
Specify a key that is used to encrypt the protocol packets
•
Specify the server on which the TACACS+ server daemon resides
•
Set the number of login attempts allowed
•
Set the timeout interval for server daemon response
•
Enable or disable the directed-request option
TACACS+ authentication is disabled by default. You can enable TACACS+ authentication and local authentication at the same time.
When local authentication is disabled, if you disable all other authentication methods, local authentication is reenabled automatically.
Understanding How RADIUS Authentication Works
RADIUS is a client-server authentication and authorization access protocol that is used by the NAS to authenticate users attempting to connect to a network device. The NAS functions as a client, passing user information to one or more RADIUS servers. The NAS permits or denies network access to a user based on the response it receives from one or more RADIUS servers. RADIUS uses UDP for transport between the RADIUS client and server.
You can configure a RADIUS key on the client and server. If you configure a key on the client, it must be the same as the one configured on the RADIUS servers. The RADIUS clients and servers use the key to encrypt all transmitted RADIUS packets. If you do not configure a RADIUS key, packets are not encrypted. The key itself is never transmitted over the network.
Note
For more information about how the RADIUS protocol operates, refer to RFC 2138, "Remote Authentication Dial In User Service (RADIUS)."
You can configure the following RADIUS parameters on the switch:
•
Enable or disable RADIUS authentication to control login access
•
Enable or disable RADIUS authentication to control enable access
•
Specify the IP addresses and UDP ports of the RADIUS servers
•
Specify the RADIUS key that is used to encrypt RADIUS packets
•
Specify the RADIUS server timeout interval
•
Specify the RADIUS retransmit count
•
Specify the RADIUS server dead time interval
RADIUS authentication is disabled by default. You can enable RADIUS authentication and other authentication methods at the same time. You can specify which method to use first using the primary keyword.
When local authentication is disabled, if you disable all other authentication methods, local authentication is reenabled automatically.
Understanding How Kerberos Authentication Works
Kerberos is a client-server based secret-key network authentication method that uses a trusted Kerberos server to verify secure access to both services and users. In Kerberos, this trusted server is called the key distribution center (KDC). The KDC issues tickets to validate users and services. A ticket is a temporary set of electronic credentials that verifies the identity of a client for a particular service.
These tickets have a limited life span and can be used in place of the standard user password pair authentication mechanism if a service trusts the Kerberos server that issued the ticket. If the standard user password method is used, Kerberos encrypts user passwords into the tickets, ensuring that passwords are not sent on the network in clear text. When you use Kerberos, passwords are not stored on any machine, other than the Kerberos server, for more than a few seconds. Kerberos also guards against intruders who might pick up the encrypted tickets from the network.
Table 21-1 defines the Kerberos terms.
Table 21-1 Kerberos Terminology
Term
|
Definition
|
Kerberized
|
Applications and services that have been modified to support the Kerberos credential infrastructure.
|
Kerberos credential
|
General term referring to authentication tickets, such as ticket granting tickets (TGTs) and service credentials. Kerberos credentials verify the ticket of a user or service. If a network service decides to trust the Kerberos server that issued the ticket, the Kerberos credential can be used in place of retyping in a username and password. Credentials have a default life span of eight hours.
|
Kerberos identity
|
(See Kerberos principal.)
|
Kerberos principal
|
The Kerberos principal is who you are or what a service is according to the Kerberos server. (Also known as a Kerberos identity.)
|
Kerberos realm
|
A domain consisting of users, hosts, and network services that are registered to a Kerberos server. The Kerberos server is trusted to verify the identity of a user or network service to another user or network service. Kerberos realms must always be in uppercase characters.
|
Kerberos server
|
A daemon running on a network host. Users and network services register their identity with the Kerberos server. Network services query the Kerberos server to authenticate to other network services.
|
Key distribution center (KDC)
|
A Kerberos server and database program running on a network host that allocates the Kerberos credentials to different users or network services.
|
Service credential
|
A credential for a network service. When issued from the KDC, this credential is encrypted with the password that is shared by the network service and the KDC and with the user's TGT.
|
SRVTAB
|
A password that a network service shares with the KDC. The network service authenticates an encrypted service credential by using the SRVTAB (also known as a KEYTAB) to decrypt it.
|
Ticket granting ticket (TGT)
|
A credential that the KDC issues to authenticated users. When users receive a TGT, they can authenticate to network services within the Kerberos realm represented by the KDC.
|
In the Catalyst 6500 series switches, Telnet clients and servers through both the console and in-band management port can be Kerberized.
Note
Kerberos authentication does not work if TACACS+ is used as the authentication mechanism.
Note
If you are logged in to the console through a modem or a terminal server, you cannot use a Kerberized login procedure.
Using a Kerberized Login Procedure
You can use a Kerberized Telnet session if you are logging in through the in-band management port. When the Telnet client and services have been Kerberized, you will follow this process when attempting to access the switch through Telnet:
1.
The Telnet client asks you for the username and issues a request for a TGT to the KDC on the Kerberos server.
2.
The KDC creates the TGT, which contains the user's identity, the KDC's identity, and the TGT's expiration time. The KDC then encrypts the TGT with your password and sends the TGT to the client.
3.
When the Telnet client receives the encrypted TGT, it prompts you for the password. If the Telnet client can decrypt the TGT with the entered password, you are successfully authenticated to the KDC. The client then builds a service credential request and sends this to the KDC. This request contains your user identity and a message saying that it wants to access the switch through Telnet. This request is encrypted using the TGT.
4.
When the KDC successfully decrypts the service credential request with the TGT that it issued to the client, it builds a service to the switch. The service credential has the client's identity and the identity of the desired Telnet server. The KDC then encrypts the credential with the password that it shares with the switch's Telnet server and encrypts the resulting packet with the Telnet client's TGT and sends this packet to the client.
5.
The Telnet client decrypts the packet first with its TGT. If encryption is successful, the client then sends the resulting packet to the switch's Telnet server. At this point, the packet is still encrypted with the password that the switch's Telnet server and the KDC share.
6.
If the Telnet client has been instructed to do so, it forwards the TGT to the switch. This step ensures that you do not need to get another TGT in order to use another network service from the switch.
Figure 21-1 shows the Kerberos Telnet connection process.
Figure 21-1 Kerberized Telnet Connection
Using a Non-Kerberized Login Procedure
If you use a non-Kerberized login procedure to log in to the switch, the switch takes care of authentication to the KDC on behalf of the login client. However, the user password is now
transferred in clear text from the login client to the switch.
Note
A non-Kerberized login can be performed through a modem or terminal server through the in-band management port. Telnet does not support non-Kerberized login.
If you launch a non-Kerberized login, the following process takes place:
1.
The switch prompts you for a username and password.
2.
The switch requests a TGT from the KDC so that you can be authenticated to the switch.
3.
The KDC sends an encrypted TGT to the switch, which contains your identity, KDC's identity, and TGT's expiration time.
4.
The switch tries to decrypt the TGT with the password that you entered. If the decryption is successful, you are authenticated to the switch.
5.
If you want to access other network services, the KDC must be contacted directly for authentication. To obtain the TGT, you can run the program "kinit," which is the client software that is provided with the Kerberos package.
Figure 21-2 shows the non-Kerberized login process.
Figure 21-2 Non-Kerberized Telnet Connection
Configuring Authentication on the Switch
These sections describe how to configure the different authentication methods:
•
Authentication Default Configuration
•
Authentication Configuration Guidelines
•
Configuring Login Authentication
•
Configuring Local Authentication
•
Configuring Local User Authentication
•
Configuring TACACS+ Authentication
•
Configuring RADIUS Authentication
•
Configuring Kerberos Authentication
•
Authentication Example
Authentication Default Configuration
Table 21-2 shows the default authentication configuration.
Table 21-2 Authentication Default Configuration
Feature
|
Default Value
|
Login authentication (console and Telnet)
|
Enabled
|
Local authentication (console and Telnet)
|
Enabled
|
Local user authentication
|
Disabled
|
TACACS+ login authentication (console and Telnet)
|
Disabled
|
TACACS+ enable authentication (console and Telnet)
|
Disabled
|
TACACS+ key
|
None specified
|
TACACS+ login attempts
|
3
|
TACACS+ server timeout
|
5 seconds
|
TACACS+ directed request
|
Disabled
|
RADIUS login authentication (console and Telnet)
|
Disabled
|
RADIUS enable authentication (console and Telnet)
|
Disabled
|
RADIUS server IP address
|
None specified
|
RADIUS server UDP auth-port
|
Port 1812
|
RADIUS key
|
None specified
|
RADIUS server timeout
|
5 seconds
|
RADIUS server dead time
|
0 (servers not marked dead)
|
RADIUS retransmit attempts
|
2 times
|
Kerberos login authentication (console and Telnet)
|
Disabled
|
Kerberos enable authentication (console and Telnet)
|
Disabled
|
Kerberos server IP address
|
None specified
|
Kerberos DES key
|
None specified
|
Kerberos server auth-port
|
Port 750
|
Kerberos local-realm name
|
NULL string
|
Kerberos credentials forwarding
|
Disabled
|
Kerberos clients mandatory
|
Not mandatory
|
Kerberos preauthentication
|
Disabled
|
Authentication Configuration Guidelines
This section describes the guidelines for configuring authentication on the switch:
•
Authentication configuration applies both to console and Telnet connection attempts unless you use the console and telnet keywords to specify the authentication methods to use for each connection type individually.
•
If you configure a RADIUS or TACACS+ key on the switch, make sure that you configure an identical key on the RADIUS or TACACS+ server.
•
You must specify a RADIUS or TACACS+ server before enabling RADIUS or TACACS+ on the switch.
•
If you configure multiple RADIUS or TACACS+ servers, the first server configured is the primary server and authentication requests are sent to this server first. You can specify a server as primary by using the primary keyword.
•
RADIUS and TACACS+ support one privileged mode only (level 1).
•
Kerberos authentication does not work if TACACS+ is also used as an authentication mechanism.
•
Before you can enable local user authentication, you must define at least one username.
•
Local user accounts and passwords must be fewer than 65 characters and can consist of any alphanumeric characters. Local user accounts must contain at least one alphabetic character.
Configuring Login Authentication
These sections describe how to configure login authentication on the switch:
•
Setting Authentication Login Attempts on the Switch
•
Setting Authentication Login Attempts for the Privileged Mode
Setting Authentication Login Attempts on the Switch
To set up login authentication on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable login attempt limits on the switch. Enter the console or telnet keyword if you want to enable local authentication only for the console port or for Telnet connection attempts.
|
set authentication login attempt {count} [console | telnet]
|
Step 2
|
Enable the login lockout time on the switch. Enter the console or telnet keyword if you want to enable local authentication only for the console port or for Telnet connection attempts.
|
set authentication login lockout {time} [console | telnet]
|
Step 3
|
Verify the local authentication configuration.
|
show authentication
|
This example shows how to limit login attempts to 5, set the lockout time for both console and Telnet connections to 50 seconds, and verify the configuration:
Console> (enable) set authentication login attempt 5
Login authentication attempts for console and telnet logins set to 5.
Console> (enable) set authentication login lockout 50
Login lockout time for console and telnet logins set to 50.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session Http Session
--------------------- ---------------- ---------------- ----------------
tacacs disabled disabled disabled
radius disabled disabled disabled
kerberos disabled disabled disabled
local enabled(primary) enabled(primary) enabled(primary)
lockout timeout (sec) 50 50 -
Enable Authentication: Console Session Telnet Session Http Session
---------------------- ----------------- ---------------- ----------------
tacacs disabled disabled disabled
radius disabled disabled disabled
kerberos disabled disabled disabled
local enabled(primary) enabled(primary) enabled(primary)
lockout timeout (sec) disabled disabled -
Setting Authentication Login Attempts for the Privileged Mode
To set up login authentication for privileged mode, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable the login attempt limits for privileged mode. Enter the console or telnet keyword if you want to enable local authentication only for the console port or for Telnet connection attempts.
|
set authentication enable attempt {count} [console | telnet]
|
Step 2
|
Enable the login lockout time for privileged mode. Enter the console or telnet keyword if you want to enable local authentication only for the console port or for Telnet connection attempts.
|
set authentication enable lockout {time} [console | telnet]
|
Step 3
|
Verify the local authentication configuration.
|
show authentication
|
This example shows how to limit enable mode login attempts to5, set the enable mode lockout time for both console and Telnet connections to 50 seconds, and verify the configuration:
Console> (enable) set authentication enable attempt 5
Enable mode authentication attempts for console and telnet logins set to 5.
Console> (enable) set authentication enable lockout 50
Enable mode lockout time for console and telnet logins set to 50.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session Http Session
--------------------- ---------------- ---------------- ----------------
tacacs disabled disabled disabled
radius disabled disabled disabled
kerberos disabled disabled disabled
local enabled(primary) enabled(primary) enabled(primary)
lockout timeout (sec) 50 50 -
Enable Authentication: Console Session Telnet Session Http Session
---------------------- ----------------- ---------------- ----------------
tacacs disabled disabled disabled
radius disabled disabled disabled
kerberos disabled disabled disabled
local enabled(primary) enabled(primary) enabled(primary)
lockout timeout (sec) 50 50 -
Configuring Local Authentication
These sections describe how to configure local authentication on the switch:
•
Enabling Local Authentication
•
Setting the Login Password
•
Setting the Enable Password
•
Disabling Local Authentication
•
Recovering a Lost Password
Enabling Local Authentication
Note
Local login and enable authentication are enabled for both console and Telnet connections by default. You do not need to perform this task unless you want to modify the default configuration or you have disabled local authentication.
To enable local authentication on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable local login authentication on the switch. Enter the console or telnet keyword if you want to enable local authentication only for console port or Telnet connection attempts.
|
set authentication login local enable [all | console | http | telnet]
|
Step 2
|
Enable local enable authentication on the switch. Enter the console or telnet keyword if you want to enable local authentication only for console port or Telnet connection attempts.
|
set authentication enable local enable [all | console | http | telnet]
|
Step 3
|
Verify the local authentication configuration.
|
show authentication
|
This example shows how to enable local login, how to enable authentication for both console and Telnet connections, and how to verify the configuration:
Console> (enable) set authentication login local enable
local login authentication set to enable for console and telnet session.
Console> (enable) set authentication enable local enable
local enable authentication set to enable for console and telnet session.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
kerberos disabled disabled
local enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
kerberos disabled disabled
local enabled(primary) enabled(primary)
Setting the Login Password
The login password controls access to the user mode CLI. Passwords are case sensitive, contain up to 19 characters, and use any printable character including a space.
Note
Passwords set in releases prior to software release 5.4 remain non-case sensitive. You must reset the password after installing software release 5.4 to activate case sensitivity.
To set the login password for local authentication, perform this task in privileged mode:
Task
|
Command
|
Set the login password for access. Enter your old password (press Return on a switch with no password configured), enter your new password, and reenter your new password.
|
set password
|
This example shows how to set the login password on the switch:
Console> (enable) set password
Enter old password: <old_password>
Enter new password: <new_password>
Retype new password: <new_password>
Setting the Enable Password
The login password controls access to the user mode CLI. Passwords are case sensitive, contain up to 19 characters, and use any printable character including a space.
Note
Passwords set in releases prior to software release 5.4 remain non-case sensitive. You must reset the password after installing software release 5.4 to activate case sensitivity.
To set the enable password for local authentication, perform this task in privileged mode:
Task
|
Command
|
Set the password for privileged mode. Enter your old password (press Return on a switch with no password configured), enter your new password, and reenter your new password.
|
set enablepass
|
This example shows how to set the enable password on the switch:
Console> (enable) set enablepass
Enter old password: <old_password>
Enter new password: <new_password>
Retype new password: <new_password>
Disabling Local Authentication
Caution 
Make sure that RADIUS or TACACS+ authentication is configured and operating correctly before disabling local login or enable authentication. If you disable local authentication and RADIUS or TACACS+ is not configured correctly, or if the RADIUS or TACACS+ server is not online, you may be unable to log in to the switch.
To disable local authentication on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Disable local login authentication on the switch. Enter the console or telnet keyword if you want to disable local authentication only for console port or Telnet connection attempts.
|
set authentication login local disable [all | console | http | telnet]
|
Step 2
|
Disable local enable authentication on the switch. Enter the console or telnet keyword if you want to disable local authentication only for console port or Telnet connection attempts.
|
set authentication enable local disable [all | console | http | telnet]
|
Step 3
|
Verify the local authentication configuration.
|
show authentication
|
Note
You must have either RADIUS or TACACS+ authentication enabled before you disable local authentication.
This example shows how to disable local login authentication, how to enable authentication for both console and Telnet connections, and how to verify the configuration:
Console> (enable) set authentication login local disable
local login authentication set to disable for console and telnet session.
Console> (enable) set authentication enable local disable
local enable authentication set to disable for console and telnet session.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
radius enabled(primary) enabled(primary)
kerberos disabled disabled
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
radius enabled(primary) enabled(primary)
kerberos disabled disabled
Recovering a Lost Password
Use the following procedure to recover a lost local authentication password. You must complete Steps 3 through 7 within 30 seconds of a power cycle or the recovery will fail. If you lost both the login and enable passwords, repeat the process for each password.
To recover a lost password, perform these steps in privileged mode:
Step 1
Connect to the switch through the supervisor engine console port. You cannot recover the password if you are connected through a Telnet connection.
Step 2
Enter the reset system command to reboot the switch.
Step 3
At the "Enter Password" prompt, press Return. The login password is null for 30 seconds when you are connected to the console port.
Step 4
Enter privileged mode using the enable command.
Step 5
At the "Enter Password" prompt, press Return. (The enable password is null for 30 seconds when you are connected to the console port.)
Step 6
Enter the set password or set enablepass command, as appropriate.
Step 7
When prompted for your old password, press Return.
Step 8
Enter and confirm your new password.
Configuring Local User Authentication
These sections describe how to configure local user authentication on the switch:
•
Creating a Local User Account
•
Enabling Local User Authentication
•
Disabling Local User Authentication
•
Deleting a Local User Account
Creating a Local User Account
Local user accounts and passwords must be fewer than 65 characters in length and can consist of any alphanumeric characters. Local user accounts must also contain at least one alphabetic character.
To create a local user account on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Create a new local user account.
|
set localuser user username password pwd privilege privilege_level
|
Step 2
|
Verify the local user account.
|
show localusers
|
This example shows how to create a local user account and password, set the privilege level, and verify the configuration:
Console> (enable) set localuser user picard password captain privilege 15
Console> (enable) show localusers
Local User Authentication: disabled
Enabling Local User Authentication
To enable local user authentication on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable local user authentication.
|
set localuser authentication enable
|
Step 2
|
Verify the local user authentication configuration.
|
show authentication
|
This example shows how to create a local user account, enable local user authentication, and verify the configuration:
Console> (enable) set localuser authentication enable
Local User Authentication enabled.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session Http Session
--------------------- ---------------- ---------------- ----------------
tacacs disabled disabled disabled
radius disabled disabled disabled
kerberos disabled disabled disabled
local * enabled(primary) enabled(primary) enabled(primary)
lockout timeout (sec) disabled disabled -
Enable Authentication: Console Session Telnet Session Http Session
---------------------- ----------------- ---------------- ----------------
tacacs disabled disabled disabled
radius disabled disabled disabled
kerberos disabled disabled disabled
local * enabled(primary) enabled(primary) enabled(primary)
lockout timeout (sec) disabled disabled -
* Local User Authentication enabled.
Disabling Local User Authentication
To disable local user authentication on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Disable local user authentication.
|
set localuser authentication disable
|
Step 2
|
Verify the local authentication configuration.
|
show authentication
|
This example shows how to disable local user authentication for the switch and how to verify the configuration:
Console> (enable) set localuser authentication disable
local user authentication set to disable.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session Http Session
--------------------- ---------------- ---------------- ----------------
tacacs disabled disabled disabled
radius disabled disabled disabled
kerberos disabled disabled disabled
local * enabled(primary) enabled(primary) enabled(primary)
lockout timeout (sec) disabled disabled -
Enable Authentication: Console Session Telnet Session Http Session
---------------------- ----------------- ---------------- ----------------
tacacs disabled disabled disabled
radius disabled disabled disabled
kerberos disabled disabled disabled
local * enabled(primary) enabled(primary) enabled(primary)
lockout timeout (sec) disabled disabled -
* Local User Authentication disabled.
Deleting a Local User Account
To delete a local user account on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Delete a local user account.
|
clear localuser picard
|
Step 2
|
Verify that the local user account has been deleted.
|
show localusers
|
This example shows how to delete local user authentication for the switch and how to verify the configuration:
Console> (enable) clear localuser number1
Console> (enable) show localusers
Local User Authentication: enabled
Configuring TACACS+ Authentication
These sections describe how to configure TACACS+ authentication on the switch:
•
Specifying TACACS+ Servers
•
Enabling TACACS+ Authentication
•
Specifying the TACACS+ Key
•
Specifying the TACACS+ Timeout Interval
•
Specifying the TACACS+ Login Attempts
•
Enabling TACACS+ Directed Request
•
Disabling TACACS+ Directed Request
•
Clearing TACACS+ Servers
•
Clearing the TACACS+ Key
•
Disabling TACACS+ Authentication
Specifying TACACS+ Servers
Specify one or more TACACS+ servers before you enable TACACS+ authentication on the switch. The first server you specify is the primary server, unless you explicitly make one server the primary using the primary keyword.
To specify one or more TACACS+ servers, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the IP address of one or more TACACS+ servers.
|
set tacacs server ip_addr [primary]
|
Step 2
|
Verify the TACACS+ configuration.
|
show tacacs
|
This example shows how to specify TACACS+ servers and verify the configuration:
Console> (enable) set tacacs server 172.20.52.3
172.20.52.3 added to TACACS server table as primary server.
Console> (enable) set tacacs server 172.20.52.2 primary
172.20.52.2 added to TACACS server table as primary server.
Console> (enable) set tacacs server 172.20.52.10
172.20.52.10 added to TACACS server table as backup server.
Console> (enable) show tacacs
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
local enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
local enabled(primary) enabled(primary)
Tacacs timeout: 5 seconds
Tacacs direct request: disabled
---------------------------------------- -------
Enabling TACACS+ Authentication
Note
Specify at least one TACACS+ server before enabling TACACS+ authentication on the switch. For information on specifying a TACACS+ server, see the "Specifying TACACS+ Servers" section.
You can enable TACACS+ authentication for login and enable access to the switch. If desired, you can use the console and telnet keywords to specify that TACACS+ authentication be used only on console or Telnet connections. If you are using both RADIUS and TACACS+, you can use the primary keyword to force the switch to try TACACS+ authentication first.
To enable TACACS+ authentication, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable TACACS+ authentication for normal login mode. Enter the console or telnet keyword if you want to enable TACACS+ only for console port or Telnet connection attempts.
|
set authentication login tacacs enable [all | console | http | telnet] [primary]
|
Step 2
|
Enable TACACS+ authentication for enable mode. Enter the console or telnet keyword if you want to enable TACACS+ only for console port or Telnet connection attempts.
|
set authentication enable tacacs enable [all | console | http | telnet] [primary]
|
Step 3
|
Verify the TACACS+ configuration.
|
show authentication
|
This example shows how to enable TACACS+ authentication for console and Telnet connections and how to verify the configuration:
Console> (enable) set authentication login tacacs enable
tacacs login authentication set to enable for console and telnet session.
Console> (enable) set authentication enable tacacs enable
tacacs enable authentication set to enable for console and telnet session.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
tacacs enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
tacacs enabled(primary) enabled(primary)
Specifying the TACACS+ Key
Note
If you configure a TACACS+ key on the client, make sure that you configure an identical key on the TACACS+ server.
To specify the TACACS+ key, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the key that is used to encrypt packets.
|
set tacacs key key
|
Step 2
|
Verify the TACACS+ configuration.
|
show tacacs
|
This example shows how to specify the TACACS+ key and verify the configuration:
Console> (enable) set tacacs key Secret_TACACS_key
The tacacs key has been set to Secret_TACACS_key.
Console> (enable) show tacacs
Tacacs key: Secret_TACACS_key
Tacacs timeout: 5 seconds
Tacacs direct request: disabled
---------------------------------------- -------
Specifying the TACACS+ Timeout Interval
You can specify the timeout interval between retransmissions to the TACACS+ server. The default timeout is 5 seconds.
To specify the TACACS+ timeout interval, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the TACACS+ timeout interval.
|
set tacacs timeout seconds
|
Step 2
|
Verify the TACACS+ configuration.
|
show tacacs
|
This example shows how to specify the server timeout interval and verify the configuration:
Console> (enable) set tacacs timeout 30
Tacacs timeout set to 30 seconds.
Console> (enable) show tacacs
Tacacs key: Secret_TACACS_key
Tacacs timeout: 30 seconds
Tacacs direct request: disabled
---------------------------------------- -------
Specifying the TACACS+ Login Attempts
You can specify the number of failed login attempts allowed.
To specify the number of login attempts allowed, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the number of allowed login attempts.
|
set tacacs attempts number
|
Step 2
|
Verify the TACACS+ configuration.
|
show tacacs
|
This example shows how to specify the number of login attempts and verify the configuration:
Console> (enable) set tacacs attempts 5
Tacacs number of attempts set to 5.
Console> (enable) show tacacs
Tacacs key: Secret_TACACS_key
Tacacs timeout: 30 seconds
Tacacs direct request: disabled
---------------------------------------- -------
Enabling TACACS+ Directed Request
When TACACS+ directed request is enabled, you can optionally specify the host name of a configured TACACS+ server to direct the TACACS+ authentication request to that particular TACACS+ server. Authentication will fail if the server that the switch contacts does not have an account for the user that is attempting to login.
To enable TACACS+ directed request, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable TACACS+ directed request on the switch.
|
set tacacs directedrequest enable
|
Step 2
|
Verify the TACACS+ configuration.
|
show tacacs
|
This example shows how to enable TACACS+ directed request and verify the configuration:
Console> (enable) set tacacs directedrequest enable
Tacacs direct request has been enabled.
Console> (enable) show tacacs
Tacacs key: Secret_TACACS_key
Tacacs timeout: 30 seconds
Tacacs direct request: enabled
---------------------------------------- -------
Disabling TACACS+ Directed Request
To disable TACACS+ directed request, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Disable TACACS+ directed request on the switch.
|
set tacacs directedrequest disable
|
Step 2
|
Verify the TACACS+ configuration.
|
show tacacs
|
This example shows how to disable TACACS+ directed request:
Console> (enable) set tacacs directedrequest disable
Tacacs direct request has been disabled.
Clearing TACACS+ Servers
To clear one or more TACACS+ servers, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the IP address of the TACACS+ server to clear from the configuration. Enter the all keyword to clear all of the servers from the configuration.
|
clear tacacs server [ip_addr | all]
|
Step 2
|
Verify the TACACS+ server configuration.
|
show tacacs
|
This example shows how to clear a specific TACACS+ server from the configuration:
Console> (enable) clear tacacs server 172.20.52.3
172.20.52.3 cleared from TACACS table
This example shows how to clear all TACACS+ servers from the configuration:
Console> (enable) clear tacacs server all
All TACACS servers cleared
Clearing the TACACS+ Key
To clear the TACACS+ key, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Clear the TACACS+ key.
|
clear tacacs key
|
Step 2
|
Verify the TACACS+ configuration.
|
show tacacs
|
This example shows how to clear the TACACS+ key:
Console> (enable) clear tacacs key
TACACS server key cleared.
Disabling TACACS+ Authentication
When local authentication is disabled and only TACACS+ authentication is enabled, if you disable TACACS+ authentication, local authentication is reenabled automatically.
To disable TACACS+ authentication, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Disable TACACS+ authentication for normal login mode. Enter the console or telnet keyword if you want to disable TACACS+ only for console port or Telnet connection attempts.
|
set authentication login tacacs disable [all | console | http | telnet]
|
Step 2
|
Disable TACACS+ authentication for enable mode. Enter the console or telnet keyword if you want to disable TACACS+ only for console port or Telnet connection attempts.
|
set authentication enable tacacs disable [all | console | http | telnet]
|
Step 3
|
Verify the TACACS+ configuration.
|
show authentication
|
This example shows how to disable TACACS+ authentication for console and Telnet connections and how to verify the configuration:
Console> (enable) set authentication login tacacs disable
tacacs login authentication set to disable for console and telnet session.
Console> (enable) set authentication enable tacacs disable
tacacs enable authentication set to disable for console and telnet session.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
local enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
local enabled(primary) enabled(primary)
Configuring RADIUS Authentication
These sections describe how to configure RADIUS authentication on the switch:
•
Specifying RADIUS Servers
•
Specifying the RADIUS Key
•
Enabling RADIUS Authentication
•
Specifying the RADIUS Timeout Interval
•
Specifying the RADIUS Retransmit Count
•
Specifying the RADIUS Dead Time
•
Specifying Optional Attributes for RADIUS Servers
•
Clearing RADIUS Servers
•
Clearing the RADIUS Key
•
Disabling RADIUS Authentication
Specifying RADIUS Servers
To specify one or more RADIUS servers, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the IP address of up to three RADIUS servers. Specify the primary server using the primary keyword. Optionally, specify the destination UDP port to use on the server.
|
set radius server ip_addr [auth-port port] [primary]
|
Step 2
|
Verify the RADIUS server configuration.
|
show radius
|
This example shows how to specify a RADIUS server and verify the configuration:
Console> (enable) set radius server 172.20.52.3
172.20.52.3 with auth-port 1812 added to radius server table as primary server.
Console> (enable) show radius
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
local enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
local enabled(primary) enabled(primary)
Radius Deadtime: 0 minutes
Radius Timeout: 5 seconds
Radius-Server Status Auth-port
----------------------------- ------- ------------
Specifying the RADIUS Key
Note
If you specify a RADIUS key on the client, make sure that you specify an identical key on the RADIUS server.
The RADIUS key is used to encrypt and authenticate all communication between the RADIUS client and server. You must configure the same key on the client and the RADIUS server.
The length of the key is limited to 65 characters. It can include any printable ASCII characters except tabs.
To specify the RADIUS key, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the RADIUS key that is used to encrypt packets sent to the RADIUS server.
|
set radius key key
|
Step 2
|
Verify the RADIUS configuration.
|
show radius
|
This example shows how to specify the RADIUS key and verify the configuration (in normal mode, the RADIUS key value is hidden):
Console> (enable) set radius key Secret_RADIUS_key
Radius key set to Secret_RADIUS_key
Console> (enable) show radius
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
radius enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
radius enabled(primary) enabled(primary)
Radius Deadtime: 0 minutes
Radius Key: Secret_RADIUS_key
Radius Timeout: 5 seconds
Radius-Server Status Auth-port
----------------------------- ------- ------------
Enabling RADIUS Authentication
Note
Specify at least one RADIUS server before enabling RADIUS authentication on the switch. For information on specifying a RADIUS server, see the "Specifying RADIUS Servers" section.
You can enable RADIUS authentication for login and enable access to the switch. If desired, you can enter the console or telnet keyword to specify that RADIUS authentication be used only on console or Telnet connections. If you are using both RADIUS and TACACS+, you can use the primary keyword to force the switch to try RADIUS authentication first.
To set up the RADIUS username and enable RADIUS authentication, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable RADIUS authentication for normal login mode. Enter the console or telnet keyword if you want to enable RADIUS only for console port or Telnet connection attempts.
|
set authentication login radius enable [all | console | http | telnet] [primary]
|
Step 2
|
Enable RADIUS authentication for enable mode. Enter the console or telnet keyword if you want to enable RADIUS only for console port or Telnet connection attempts.
|
set authentication enable radius enable [all | console | http | telnet] [primary]
|
Step 3
|
Create a user $enab15$ on the RADIUS server and assign a password to that user.
|
See the Note below for additional information.
|
Step 4
|
Verify the RADIUS configuration.
|
show authentication
|

Note
To use RADIUS authentication for enable mode, you must create a user $enab15$ on the RADIUS server and assign a password to that user. This user needs to be created in addition to your assigned username and password on the RADIUS server (example: username john, password hello.) After you log in to the Catalyst 6500 series switch with your assigned username and password (john/hello), you can enter enable mode using the password that is assigned to the $enab15$ user.
If your RADIUS server does not support the $enab15$ username, you can set the service-type attribute (attribute 6) to Administrative (value 6) for a RADUIS user to directly launch the user into enable mode without asking for a separate enable password.
This example shows how to enable RADIUS authentication and verify the configuration:
Console> (enable) set authentication login radius enable
radius login authentication set to enable for console and telnet session.
Console> (enable) set authentication enable radius enable
radius enable authentication set to enable for console and telnet session.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
radius enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
radius enabled(primary) enabled(primary)
Specifying the RADIUS Timeout Interval
You can specify the timeout interval between retransmissions to the RADIUS server. The default timeout is 5 seconds.
To specify the RADIUS timeout interval, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the RADIUS timeout interval.
|
set radius timeout seconds
|
Step 2
|
Verify the RADIUS configuration.
|
show radius
|
This example shows how to specify the RADIUS timeout interval and verify the configuration:
Console> (enable) set radius timeout 10
Radius timeout set to 10 seconds.
Console> (enable) show radius
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
radius enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
radius enabled(primary) enabled(primary)
Radius Deadtime: 0 minutes
Radius Key: Secret_RADIUS_key
Radius Timeout: 10 seconds
Radius-Server Status Auth-port
----------------------------- ------- ------------
Specifying the RADIUS Retransmit Count
You can specify the number of times the switch will attempt to contact a RADIUS server before the next configured server is tried. By default, each RADIUS server is tried two times.
To specify the RADIUS retransmit count, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the RADIUS server retransmit count.
|
set radius retransmit count
|
Step 2
|
Verify the RADIUS configuration.
|
show radius
|
This example shows how to specify the RADIUS retransmit count and verify the configuration:
Console> (enable) set radius retransmit 4
Radius retransmit count set to 4.
Console> (enable) show radius
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
radius enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
radius enabled(primary) enabled(primary)
Radius Deadtime: 0 minutes
Radius Key: Secret_RADIUS_key
Radius Timeout: 10 seconds
Radius-Server Status Auth-port
----------------------------- ------- ------------
Specifying the RADIUS Dead Time
You can configure the switch so that, when a RADIUS server does not respond to an authentication request, the switch marks that server as dead for the length of time that is specified by the dead time. Any authentication requests that are received during the dead time interval (such as other users attempting to log in to the switch) are not sent to a RADIUS server that is marked dead. Configuring a dead time speeds up the authentication process by eliminating timeouts and retransmissions to the dead RADIUS server.
If you configure only one RADIUS server, or if all of the configured servers are marked dead, the dead time is ignored because no alternate servers are available.
To set the RADIUS dead time, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the RADIUS server dead time interval.
|
set radius deadtime minutes
|
Step 2
|
Verify the RADIUS configuration.
|
show radius
|
This example shows how to specify the RADIUS dead time interval and verify the configuration:
Console> (enable) set radius deadtime 5
Radius deadtime set to 5 minute(s)
Console> (enable) show radius
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
radius enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
radius enabled(primary) enabled(primary)
Radius Deadtime: 5 minutes
Radius Key: Secret_RADIUS_key
Radius Timeout: 10 seconds
Radius-Server Status Auth-port
----------------------------- ------- ------------
Specifying Optional Attributes for RADIUS Servers
You can specify optional attributes in the RADIUS ACCESS_REQUEST packet. The set radius attribute command allows you to specify the transmission of certain optional attributes such as Framed-IP address, NAS-Port, Called-Station-Id, Calling-Station-Id and so on. You can set attribute transmission by either the attribute number or the attribute name. Transmission of the attributes is disabled by default.
Note
Software release 7.5(1) supports only the Framed-IP address (Attribute 8).
To specify optional attributes for the RADIUS server, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the optional attributes for the RADIUS server.
|
set radius attribute [number | name] include-in-access-req [enable | disable]
|
Step 2
|
Verify the RADIUS configuration.
|
show radius
|
This example shows how to specify and enable the Framed-IP address attribute by number:
Console> (enable) set radius attribute 8 include-in-access-req enable
Transmission of Framed-ip address in access-request packet is enabled.
Console> (enable) show radius
RADIUS Deadtime: 0 minutes
RADIUS Timeout: 5 seconds
Framed-Ip Address Transmit: Enabled
RADIUS-Server Status Auth-port Acct-port
----------------------------- ------- ------------ ------------
10.6.140.230 primary 1812 1813
This example shows how to specify and disable the Framed-IP address attribute by name:
Console> (enable) set radius attribute framed-ip-address include-in-access-req disable
Transmission of Framed-ip address in access-request packet is disabled.
Clearing RADIUS Servers
To clear one or more RADIUS servers, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the IP address of the RADIUS server to clear from the configuration. Enter the all keyword to clear all of the servers from the configuration.
|
clear radius server [ip_addr | all]
|
Step 2
|
Verify the RADIUS server configuration.
|
show radius
|
This example shows how to clear a single RADIUS server from the configuration:
Console> (enable) clear radius server 172.20.52.3
172.20.52.3 cleared from radius server table.
This example shows how to clear all RADIUS servers from the configuration:
Console> (enable) clear radius server all
All radius servers cleared from radius server table.
Clearing the RADIUS Key
To clear the RADIUS key, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Clear the RADIUS key.
|
clear radius key
|
Step 2
|
Verify the RADIUS configuration.
|
show radius
|
This example shows how to clear the RADIUS key and verify the configuration:
Console> (enable) clear radius key
Console> (enable) show radius
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
local enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
local enabled(primary) enabled(primary)
Radius Deadtime: 0 minutes
Radius Timeout: 5 seconds
Radius-Server Status Auth-port
----------------------------- ------- ------------
Disabling RADIUS Authentication
When local authentication is disabled and only RADIUS authentication is enabled, if you disable RADIUS authentication, local authentication is reenabled automatically.
To disable RADIUS authentication, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Disable RADIUS authentication for login mode.
|
set authentication login radius disable [all | console | http | telnet]
|
Step 2
|
Disable RADIUS authentication for enable mode.
|
set authentication enable radius disable [all | console | http | telnet]
|
Step 3
|
Verify the RADIUS configuration.
|
show authentication
|
This example shows how to disable RADIUS authentication:
Console> (enable) set authentication login radius disable
radius login authentication set to disable for console and telnet session.
Console> (enable) set authentication enable radius disable
radius enable authentication set to disable for console and telnet session.
Console> (enable) show authentication
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
local enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
local enabled(primary) enabled(primary)
Configuring Kerberos Authentication
These sections describe how to configure Kerberos authentication on the switch:
•
Configuring a Kerberos Server
•
Enabling Kerberos
•
Defining the Kerberos Local Realm
•
Specifying a Kerberos Server
•
Mapping a Kerberos Realm to a Host Name or DNS Domain
•
Copying SRVTAB Files
•
Deleting an SRVTAB Entry
•
Enabling Credentials Forwarding
•
Disabling Credentials Forwarding
•
Defining and Clearing a Private DES Key
•
Encrypting a Telnet Session
•
Displaying and Clearing Kerberos Configurations
Configuring a Kerberos Server
Before you can use Kerberos as an authentication method on the switch, you need to configure the Kerberos server. You will need to create a database for the KDC and add the switch to the database.
Note
Kerberos authentication requires that NTP is enabled. Additionally, we recommend that you enable DNS.
To configure the Kerberos server, perform these steps:
Step 1
Before you can enter the switch in the Kerberos server's key table, you must create the database that the KDC will use. In the following example, a database called CISCO.EDU is created:
/usr/local/sbin/kdb5_util create -r CISCO.EDU -s
Step 2
Add the switch to the database. The following example adds a switch called Cat6509 to the CISCO.EDU database:
ank host/Cat6509.cisco.edu@CISCO.EDU
Step 3
Add the username as follows:
Step 4
Add the administrative principals as follows:
ank user1/admin@CISCO.EDU
Step 5
Using the admin.local ktadd command, create the database entry for the switch as follows:
ktadd host/Cat6509.cisco.edu@CISCO.EDU
Step 6
Move the keytab file to a place where the switch can reach it.
Step 7
Start the KDC server as follows:
Enabling Kerberos
To enable Kerberos authentication, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify Kerberos as the authentication method.
|
set authentication login kerberos enable [all | console | http | telnet] [primary]
|
Step 2
|
Verify the configuration.
|
show authentication
|
This example shows how to enable Kerberos as the login authentication method for Telnet and verify the configuration:
kerberos> (enable) set authentication login kerberos enable telnet
kerberos login authentication set to enable for telnet session.
kerberos> (enable) show authentication
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
kerberos disabled enabled(primary)
local enabled(primary) enabled
Enable Authentication:Console Session Telnet Session
---------------------- ----------------- ----------------
kerberos disabled enabled(primary)
local enabled(primary) enabled
This example shows how to enable Kerberos as the login authentication method for the console and verify the configuration:
kerberos> (enable) set authentication login kerberos enable console
kerberos login authentication set to enable for console session.
kerberos> (enable) show authentication
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
kerberos enabled(primary) enabled(primary)
Enable Authentication:Console Session Telnet Session
---------------------- ----------------- ----------------
kerberos enabled(primary) enabled(primary)
Defining the Kerberos Local Realm
The Kerberos realm is a domain consisting of users, hosts, and network services that are registered to a Kerberos server. To authenticate a user defined in the Kerberos database, the switch must know the host name or IP address of the host running the KDC and the name of the Kerberos realm.
To configure the switch to authenticate to the KDC in a specified Kerberos realm, perform this task in privileged mode:
Task
|
Command
|
Define the default realm for the switch.
|
set kerberos local-realm kerberos_realm
|
Note
Make sure that the realm is entered in uppercase letters. Kerberos will not authenticate users if the realm is entered in lowercase letters.
This example shows how to define a local realm and how to verify the configuration:
kerberos> (enable) set kerberos local-realm CISCO.COM
Kerberos local realm for this switch set to CISCO.COM.
kerberos> (enable) show kerberos
Kerberos Local Realm:CISCO.COM
Realm:CISCO.COM, Server:187.0.2.1, Port:750
Kerberos Domain<->Realm entries:
Domain:cisco.com, Realm:CISCO.COM
Kerberos Clients NOT Mandatory
Kerberos Credentials Forwarding Enabled
Kerberos Pre Authentication Method set to None
Srvtab Entry 1:host/niners.cisco.com@CISCO.COM 0 932423923 1 1 8 01;;8>00>50;0=0=0
Specifying a Kerberos Server
You can specify to the switch which KDC to use in a specific Kerberos realm. Optionally, you can also specify the port number that the KDC is monitoring. The Kerberos server information that you enter is maintained in a table with one entry for each Kerberos realm. The maximum number of entries in the table is 100.
To specify the Kerberos server, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify which KDC to use in a given Kerberos realm. Optionally, enter the port number that the KDC is monitoring. (The default port number is 750.)
|
set kerberos server kerberos_realm {hostname | ip_address} [port]
|
Step 2
|
Clear the Kerberos server entry.
|
clear kerberos server kerberos_realm {hostname | ip_address} [port]
|
This example shows how to specify which Kerberos server will serve as the KDC for the specified Kerberos realm and how to clear the entry:
kerberos> (enable) set kerberos server CISCO.COM 187.0.2.1 750
Kerberos Realm-Server-Port entry set to:CISCO.COM - 187.0.2.1 - 750
Console> (enable) clear kerberos server CISCO.COM 187.0.2.1 750
Kerberos Realm-Server-Port entry CISCO.COM-187.0.2.1-750 deleted
Mapping a Kerberos Realm to a Host Name or DNS Domain
Optionally, you can map a host name or domain name system (DNS) domain to a Kerberos realm.
To map a Kerberos realm to either a host name or DNS domain, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
(Optional) Map a host name or DNS domain to a Kerberos realm.
|
set kerberos realm {dns_domain | host} kerberos_realm
|
Step 2
|
Clear the Kerberos realm domain or host mapping entry.
|
clear kerberos realm {dns_domain | host} kerberos_realm
|
This example shows how to map a Kerberos realm to a DNS domain and how to clear the entry:
Console> (enable) set kerberos realm CISCO CISCO.COM
Kerberos DnsDomain-Realm entry set to CISCO - CISCO.COM
Console> (enable) clear kerberos realm CISCO CISCO.COM
Kerberos DnsDomain-Realm entry CISCO - CISCO.COM deleted
Copying SRVTAB Files
To allow remote users to authenticate to the switch using Kerberos credentials, the switch must share a key with the KDC. You must give the switch a copy of the file stored in the KDC that contains the key. These files are called SRVTAB files on the switch and KEYTAB files on the servers.
The most secure method to copy SRVTAB files to the hosts in your Kerberos realm is to copy them onto physical media and go to each host in turn and manually copy the files onto the system. To copy SRVTAB files to a switch that does not have a physical media drive, you must transfer the files through the network by using the Trivial File Transfer Protocol (TFTP).
When you copy the SRVTAB file from the switch to the KDC, the switch parses the information in this file and stores it in the running configuration in the Kerberos SRVTAB entry format. If you enter the SRVTAB directly into the switch, create an entry for each Kerberos principal (service) on the switch. The entries are maintained in the SRVTAB table. The maximum size of the table is 20 entries.
To retrieve SRVTAB files to the switch from the KDC, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Retrieve a specified SRVTAB file from the KDC.
|
set kerberos srvtab remote {hostname | ip_address} filename
|
Step 2
|
(Optional) Enter the SRVTAB directly into the switch.
|
set kerberos srvtab entry kerberos_principal principal_type timestamp key_version number key_type key_length encrypted_keytab
|
This example shows how to retrieve an SRVTAB file from the KDC, enter an SRVTAB directly into the switch, and verify the configuration:
kerberos> (enable) set kerberos srvtab remote 187.20.32.10 /users/jdoe/krb5/ninerskeytab
kerberos> (enable)
kerberos> (enable) set kerberos srvtab entry host/niners.cisco.com@CISCO.COM 0 932423923 1
1 8 03;;5>00>50;0=0=0
Kerberos SRVTAB entry set to
Principal:host/niners.cisco.com@CISCO.COM
Encrypted key tab:03;;5>00>50;0=0=0
kerberos> (enable) show kerberos
Kerberos Local Realm:CISCO.COM
Realm:CISCO.COM, Server:187.0.2.1, Port:750
Realm:CISCO.COM, Server:187.20.2.1, Port:750
Kerberos Domain<->Realm entries:
Domain:cisco.com, Realm:CISCO.COM
Kerberos Clients NOT Mandatory
Kerberos Credentials Forwarding Enabled
Kerberos Pre Authentication Method set to None
Srvtab Entry 1:host/niners.cisco.com@CISCO.COM 0 932423923 1 1 8 03;;5>00>50;0=0=0
Srvtab Entry 2:host/niners.cisco.edu@CISCO.EDU 0 933974942 1 1 8 00?58:127:223=:;9
Deleting an SRVTAB Entry
To delete an SRVTAB entry, perform this task in privileged mode:
Task
|
Command
|
Delete the SRVTAB entry for a particular Kerberos principal.
|
clear kerberos srvtab entry kerberos_principal principal_type
|
This example shows how to delete an SRVTAB entry:
kerberos> (enable) clear kerberos srvtab entry host/niners.cisco.com@CISCO.COM 0
Enabling Credentials Forwarding
A user authenticated to a Kerberized switch has a TGT and can use it to authenticate to a host on the network. However, if forwarding is not enabled and a user tries to list credentials after authenticating to a host, the output will show that no Kerberos credentials are present.
To enable credentials forwarding, configure the switch to forward user TGTs when they authenticate from the switch to Kerberized remote hosts on the network using Kerberized Telnet.
As an additional layer of security, you can configure the switch so that after users authenticate to it, these users can authenticate only to other services on the network with Kerberized clients. If you do not make Kerberos authentication mandatory and Kerberos authentication fails, the application attempts to authenticate users using the default method of authentication for that network service. For example, Telnet prompts for a password.
To configure clients to forward user credentials as they connect to other hosts in the Kerberos realm, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable all clients to forward user credentials upon successful Kerberos authentication.
|
set kerberos credentials forward
|
Step 2
|
(Optional) Configure Telnet to fail if clients cannot authenticate to the remote server.
|
set kerberos clients mandatory
|
This example shows how to configure clients to forward user credentials and verify the configuration:
kerberos> (enable) set kerberos credentials forward
Kerberos credentials forwarding enabled
kerberos> (enable) show kerberos
Kerberos Local Realm:CISCO.COM
Realm:CISCO.COM, Server:187.0.2.1, Port:750
Realm:CISCO.COM, Server:187.20.2.1, Port:750
Kerberos Domain<->Realm entries:
Domain:cisco.com, Realm:CISCO.COM
Kerberos Clients NOT Mandatory
Kerberos Credentials Forwarding Enabled
Kerberos Pre Authentication Method set to None
Srvtab Entry 1:host/aspen-niners.cisco.edu@CISCO.EDU 0 933974942 1 1 8 00?91:107:423=:;9
This example shows how to configure the switch so that Kerberos clients are mandatory for users to authenticate to other network services:
Console> (enable) set kerberos clients mandatory
Kerberos clients set to mandatory
Disabling Credentials Forwarding
To disable the credentials forwarding, perform this task in privileged mode:
Task
|
Command
|
Disable the credentials forwarding configuration.
|
clear kerberos credentials forward
|
This example shows how to disable the credentials forwarding and verify the change:
Console> (enable) clear kerberos credentials forward
Kerberos credentials forwarding disabled
Console> (enable) show kerberos
Kerberos Local Realm not configured
Kerberos Domain<->Realm entries:
Kerberos Clients NOT Mandatory
Kerberos Credentials Forwarding Disabled
Kerberos Pre Authentication Method set to None
To clear the Kerberos clients mandatory configuration, perform this task in privileged mode:
Task
|
Command
|
Clear the Kerberos clients mandatory configuration.
|
clear kerberos clients mandatory
|
This example shows how to clear the clients mandatory configuration and verify the change:
Console> (enable) clear kerberos clients mandatory
Kerberos clients mandatory cleared
Console> (enable) show kerberos
Kerberos Local Realm not configured
Kerberos Domain<->Realm entries:
Kerberos Clients NOT Mandatory
Kerberos Credentials Forwarding Disabled
Kerberos Pre Authentication Method set to None
Kerberos Domain<->Realm entries:
Kerberos Clients Mandatory
Kerberos Credentials Forwarding Disabled
Kerberos Pre Authentication Method set to Encrypted Unix Time Stamp
Defining and Clearing a Private DES Key
You can define a private DES key for the switch. You can use the private DES key to encrypt the secret key that the switch shares with the KDC so that when the show kerberos command is executed, the secret key is not displayed in clear text. The key length should be eight characters or less.
To define a DES key, perform this task in privileged mode:
Task
|
Command
|
Define a DES key for the switch.
|
set key config-key string
|
This example shows how to define a DES key and verify the configuration:
kerberos> (enable) set key config-key abcd
Kerberos config key set to abcd
kerberos> (enable) show kerberos
Kerberos Local Realm:CISCO.COM
Realm:CISCO.COM, Server:170.20.2.1, Port:750
Realm:CISCO.COM, Server:172.20.2.1, Port:750
Kerberos Domain<->Realm entries:
Domain:cisco.com, Realm:CISCO.COM
Kerberos Clients Mandatory
Kerberos Credentials Forwarding Disabled
Kerberos Pre Authentication Method set to Encrypted Unix Time Stamp
Srvtab Entry 1:host/aspen-niners.cisco.edu@CISCO.EDU 0 933974942 1 1 8 12151><88?=>>3>11
To clear the DES key, perform this task in privileged mode:
Task
|
Command
|
Clear a DES key from the switch.
|
clear key config-key string
|
This example shows how to clear the DES key:
Console> (enable) clear key config-key
Kerberos config key cleared
Encrypting a Telnet Session
After a user authenticates to the switch using Kerberos and wants to Telnet to another switch or host, whether or not this will be a Kerberized Telnet depends on the authentication method that the Telnet server uses. If the Telnet server uses Kerberos for authentication, you can choose to have all the application data packets encrypted for the duration of the Telnet session. To encrypt the Telnet session, select the encrypt kerberos option in the telnet command.
To encrypt a Telnet session, perform this task:
Task
|
Command
|
Encrypt a Telnet session.
|
telnet encrypt kerberos host
|
This example shows how to configure a Telnet session for Kerberos authentication and encryption:
Console> (enable) telnet encrypt kerberos
Displaying and Clearing Kerberos Configurations
Use these commands to display and clear Kerberos configurations on the switch:
•
show kerberos
•
show kerberos creds
•
clear kerberos creds
To display the Kerberos configuration, perform this task in privileged mode:
Task
|
Command
|
Display the Kerberos configuration.
|
show kerberos
|
This example shows how to display the Kerberos configuration:
kerberos> (enable) show kerberos
Kerberos Local Realm:CISCO.COM
Realm:CISCO.COM, Server:187.0.2.1, Port:750
Realm:CISCO.COM, Server:187.20.2.1, Port:750
Kerberos Domain<->Realm entries:
Domain:cisco.com, Realm:CISCO.COM
Kerberos Clients NOT Mandatory
Kerberos Credentials Forwarding Enabled
Kerberos Pre Authentication Method set to None
Srvtab Entry 1:host/niners.cisco.com@CISCO.COM 0 932423923 1 1 8 03;;5>00>50;0=0=0
Srvtab Entry 2:host/niners.cisco.edu@CISCO.EDU 0 933974942 1 1 8 00?58:127:223=:;9
To display the Kerberos credentials, perform this task in privileged mode:
Task
|
Command
|
Display the Kerberos credentials.
|
show kerberos creds
|
This example shows how to display the Kerberos credentials:
Console> (enable) show kerberos creds
To clear all Kerberos credentials, perform this task in privileged mode:
Task
|
Command
|
Clear all credentials.
|
clear kerberos creds
|
This example shows how to clear all Kerberos credentials from the switch:
Console> (enable) clear kerberos creds
Authentication Example
Figure 21-3 shows a simple network topology using TACACS+.
In this example, TACACS+ authentication is enabled and local authentication is disabled for both login and enable access to the switch for all Telnet connections. When Workstation A attempts to connect to the switch, the user is challenged for a TACACS+ username and password.
However, only local authentication is enabled for both login and enable access on the console port. Any user with access to the directly connected terminal can access the switch using the login and enable passwords.
Figure 21-3 TACACS+ Example Network Topology
This example shows how to configure the switch so that TACACS+ authentication is enabled for Telnet connections, local authentication is enabled for console connections, and a TACACS+ encryption key is specified:
Console> (enable) show tacacs
Tacacs timeout: 5 seconds
Tacacs direct request: disabled
---------------------------------------- -------
Console> (enable) set tacacs server 172.20.52.10
172.20.52.10 added to TACACS server table as primary server.
Console> (enable) set tacacs key tintin_et_milou
The tacacs key has been set to tintin_et_milou.
Console> (enable) set authentication login tacacs enable telnet
tacacs login authentication set to enable for telnet session.
Console> (enable) set authentication enable tacacs enable telnet
tacacs enable authentication set to enable for telnet session.
Console> (enable) set authentication login local disable telnet
local login authentication set to disable for telnet session.
Console> (enable) set authentication enable local disable telnet
local enable authentication set to disable for telnet session.
Console> (enable) show tacacs
Tacacs key: tintin_et_milou
Tacacs timeout: 5 seconds
Tacacs direct request: disabled
---------------------------------------- -------
Understanding How Authorization Works
These sections describe how authorization works:
•
Authorization Overview
•
Authorization Events
•
TACACS+ Primary Options and Fallback Options
•
TACACS+ Command Authorization
•
RADIUS Authorization
Authorization Overview
Catalyst 6500 series switches support TACACS+ and RADIUS authorization. Authorization limits access to specified users using a dynamically applied access list (or user profile) that is based on the username and password pair. The access list resides on the host running the TACACS+ or RADIUS server. The server responds to the user password information with an access list number that causes the specific list to be applied.
Authorization Events
You can enable authorization for the following:
•
Commands—When you enable the authorization feature for commands, the user must supply a valid username and password pair to execute certain commands. You can require authorization for all commands or for configuration (enable mode) commands only. When a user issues a command, the authorization server receives the command and user information and compares it against an access list. If the user is authorized to issue that command, the command is executed; otherwise, the command is not executed.
•
EXEC mode (normal login)—When the authorization feature is enabled for EXEC mode, the user must supply a valid username and password pair to gain access to EXEC mode. Authorization is required only if you have enabled the authorization feature.
•
Enable mode (privileged login)—When the authorization feature is enabled for enable mode, the user must supply a valid username and password pair to gain access to enable mode. Authorization is required only if you have enabled the authorization feature for enable mode.
TACACS+ Primary Options and Fallback Options
You can specify the primary options and the fallback options that are used in the authorization process. Available options and fallback options include the following:
•
tacacs+—If you have been authenticated, and there is no response from the TACACS+ server, then authorization will succeed immediately.
•
deny—Deny is strictly a fallback option. Authorization will fail if the TACACS+ server fails to respond. This is the default behavior.
•
if-authenticated—If you have been authenticated, and there is no response from the TACACS+ server, then authorization will succeed immediately.
•
none—Authorization will succeed if the TACACS+ server does not respond.
TACACS+ Command Authorization
You can require authorization for all commands or for configuration (enable mode) commands only. Configuration commands include the following:
•
copy
•
clear
•
commit
•
configure
•
delete
•
download
•
format
•
reload
•
rollback
•
session
•
set
•
squeeze
•
switch
•
undelete
The following TACACS+ authorization process occurs for every command that you enter:
•
If you have disabled the command authorization feature, the TACACS+ server will allow you to execute any command on the switch.
•
If you have enabled authorization for configuration commands only, the switch will verify that the argument string matches one of the commands listed in this section. If there is no match, the switch completes the command. If there is a match, the switch forwards the command to the NAS for authorization.
•
If you have enabled authorization for all commands, the switch forwards the command to the NAS for authorization.
RADIUS Authorization
RADUIS has limited authorization. There is one attribute, Service-Type, in the authentication protocol that provides authorization information. This attribute is part of the user-profile.
When you log in using RADIUS authentication and you do not have Administrative/Shell (6) Service-Type access, the network access server (NAS) authenticates you and logs you in to the EXEC mode. If you have Administrative/Shell (6) Service-Type access, the NAS authenticates you and logs you in to the privileged mode.
Configuring Authorization on the Switch
These sections describe how to configure authorization:
•
TACACS+ Authorization Default Configuration
•
TACACS+ Authorization Configuration Guidelines
•
Configuring TACACS+ Authorization
•
Configuring RADIUS Authorization
TACACS+ Authorization Default Configuration
Table 21-3 shows the TACACS+ default authorization configuration.
Table 21-3 Default Authorization Configuration
Feature
|
Default Value
|
TACACS+ login authorization (console and Telnet)
|
Disabled
|
TACACS+ EXEC authorization (console and Telnet)
|
Disabled
|
TACACS+ enable authorization (console and Telnet)
|
Disabled
|
TACACS+ commands authorization (console and Telnet)
|
Disabled
|
TACACS+ Authorization Configuration Guidelines
This section describes the guidelines for configuring TACACS+ authorization on the switch:
•
TACACS+ authorization is disabled by default.
•
Authorization configuration applies to console connections, Telnet connections, or both types of connections.
•
You must specify the mode, option, fallback option, and connection type when enabling authorization.
•
Configure RADIUS and TACACS+ servers before enabling authorization. See the "Specifying TACACS+ Servers" section or the "Specifying RADIUS Servers" section for more information on server setup.
•
Configure RADIUS and TACACS+ keys to encrypt protocol packets before enabling authorization. See the "Specifying the TACACS+ Key" section or the "Specifying the RADIUS Key" section for more information on the key setup.
Configuring TACACS+ Authorization
These sections describe how to configure TACACS+ authorization on the switch:
•
Enabling TACACS+ Authorization
•
Disabling TACACS+ Authorization
Enabling TACACS+ Authorization
To enable TACACS+ authorization on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable authorization for normal mode. Enter the console or telnet keyword if you want to enable authorization only for console port or Telnet connection attempts. Enter the both keyword to enable authorization for both console port and Telnet connection attempts.
|
set authorization exec enable {option}{fallbackoption} [console | telnet | both]
|
Step 2
|
Enable authorization for enable mode. Enter the console or telnet keyword if you want to enable authorization only for console port or Telnet connection attempts. Enter the both keyword to enable authorization for both console port and Telnet connection attempts.
|
set authorization enable enable {option} {fallbackoption} [console | telnet | both]
|
Step 3
|
Enable authorization of configuration commands. Enter the console or telnet keyword if you want to enable authorization only for console port or Telnet connection attempts. Enter the both keyword to enable authorization for both console port and Telnet connection attempts.
|
set authorization commands enable {config | all} {option}{fallbackoption} [console | telnet | both]
|
Step 4
|
Verify the TACACS+ authorization configuration.
|
show authorization
|
This example shows how to enable TACACS+ EXEC mode authorization for both console and Telnet connections. Authorization is configured with the tacacs+ option. The fallback option is deny.
Console> (enable) set authorization exec enable tacacs+ deny both
Successfully enabled enable authorization.
This example shows how to enable TACACS+ enable mode authorization for console and Telnet connections. Authorization is configured with the tacacs+ option. The fallback option is deny.
Console> (enable) set authorization enable enable tacacs+ deny both
Successfully enabled enable authorization.
This example shows how to enable TACACS+ command authorization for both console and Telnet connections. Authorization is configured with the tacacs+ option. The fallback option is deny.
Console> (enable) set authorization commands enable config tacacs+ deny both
Successfully enabled commands authorization.
This example shows how to verify the configuration:
Console> (enable) show authorization
Disabling TACACS+ Authorization
To disable TACACS+ authorization on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Disable authorization for normal mode. Enter the console or telnet keyword if you want to disable authorization only for console port or Telnet connection attempts. Enter the both keyword to disable authorization for both console port and Telnet connection attempts.
|
set authorization exec disable [console | telnet | both]
|
Step 2
|
Disable authorization for enable mode. Enter the console or telnet keyword if you want to disable authorization only for console port or Telnet connection attempts. Enter the both keyword to disable authorization for both console port and Telnet connection attempts.
|
set authorization enable disable [console | telnet | both]
|
Step 3
|
Disable authorization of configuration commands. Enter the console or telnet keyword if you want to disable authorization only for console port or Telnet connection attempts. Enter the both keyword to disable authorization for both console port and Telnet connection attempts.
|
set authorization commands disable [console | telnet | both]
|
Step 4
|
Verify the TACACS+ authorization configuration.
|
show authorization
|
This example shows how to disable TACACS+ EXEC mode authorization for both console and Telnet connections and how to verify the configuration:
Console> (enable) set authorization exec disable both
Successfully disabled enable authorization.
This example shows how to disable TACACS+ enable mode authorization for both console and Telnet connections and how to verify the configuration:
Console> (enable) set authorization enable disable both
Successfully disabled enable authorization.
This example shows how to disable TACACS+ command authorization for both console and Telnet connections and how to verify the configuration:
Console> (enable) set authorization commands disable both
Successfully disabled commands authorization.
This example shows how to verify the configuration:
Console> (enable) show authorization
Configuring RADIUS Authorization
These sections describe how to configure RADIUS authorization on the switch:
•
Enabling RADIUS Authorization
•
Disabling RADIUS Authorization
Enabling RADIUS Authorization
To enable RADIUS authorization and authentication on the switch, perform these steps in privileged mode:
Step 1
Enter the set authentication login radius enable command in privileged mode. This command enables both RADIUS authentication and authorization.
Step 2
Set the Service-Type (RADIUS attribute 6) for the user to Admistrative (that is, a value of 6) in the RADIUS server to launch the user into enable mode in the RADIUS server. If the service-type is set for anything other than 6-administrative (for example, 1-login, 7-shell, or 2-framed), you will be at the switch EXEC prompt, not the enable prompt.
Disabling RADIUS Authorization
Enter the set authentication login radius disable command in privileged mode to disable RADIUS
authorization.
Authorization Example
Figure 21-4 shows a simple network topology using TACACS+.
When Workstation A initiates a command on the switch, the switch registers a request with the TACACS+ daemon. The TACACS+ daemon determines if the user is authorized to use the feature and sends a response either executing the command or denying access.
Figure 21-4 TACACS+ Example Network Topology
In this example, TACACS+ authorization is enabled for enable mode access and for configuration commands to be entered on the switch over Telnet and console connections:
Console> (enable) set authorization enable enable tacacs+ deny both
Successfully enabled enable authorization.
Console> (enable) set authorization commands enable config tacacs+ deny both
Successfully enabled commands authorization.
Console> (enable) show authorization
Understanding How Accounting Works
These sections describe how the different accounting methods work:
•
Accounting Overview
•
Accounting Events
•
Specifying When to Create Accounting Records
•
Specifying RADIUS Servers
•
Updating the Server
•
Suppressing Accounting
Accounting Overview
You can configure these accounting methods to monitor access to the switch:
•
TACACS+ accounting
•
RADIUS accounting
Accounting allows you to track user activity to a specified host, suspicious connection attempts in the network, and unauthorized changes to the NAS configuration itself. The accounting information is sent to the accounting server where it is saved as a record. Accounting information typically consists of the user's action and the duration for which the action lasted. You can use the accounting feature for security, billing, and resource allocation purposes.
The accounting protocol operates in a client-server model using TCP for transport. The NAS acts as the client and the accounting server acts as the daemon. The NAS sends accounting information to the server. The server, after successfully processing the information, sends a response to the NAS, acknowledging the request. All transactions between the NAS and server are authenticated using a key.
Once accounting has been enabled and an accountable event occurs on the system, the accounting information is gathered dynamically in memory. When the event ends, an accounting record is created and sent to the NAS, and then the system deletes the record from memory. The amount of memory that is used by the NAS for accounting varies depending on the number of concurrent accountable events.
Accounting Events
You can configure accounting for these event types:
•
EXEC mode accounting—Provides information about user EXEC sessions (normal login sessions) on the NAS (includes the duration of the EXEC session but does not include traffic statistics).
•
Connect accounting—Provides information about all outbound connections from the NAS (such as Telnet, rlogin).
Note
If you get a connection immediately upon login and then your connection terminates, the EXEC and connect events overlap and have almost identical start and stop times.
•
System accounting—Provides information on system events that are not related to users (includes system reset, system boot, and user configuration of accounting).
•
Command accounting—Sends a record for each command issued by the user. This feature permits audit trail information to be gathered.
Specifying When to Create Accounting Records
You configure the switch to gather accounting information to create records. When you configure accounting (using the set accounting commands), the switch can generate two types of records:
•
Start records—Include partial information of the event (when the event started, type of service, and traffic statistics).
•
Stop records—Include complete information of the event (when the event started, its duration, type of service, and traffic statistics).
Accounting records are created and sent to the server at two events:
•
Start-stop—Records are sent at both the start and stop of an action if the action has duration. If the NAS fails to send the accounting record at the start of the action, it still allows you to proceed with the action.
•
Stop-only—Records are sent only at the termination of the event. Commands are assumed to have zero duration, so only stop records are generated for command accounting. No users are associated with system events; therefore, the start-stop option in the set accounting system command is ignored for system events.
Note
Stop records include complete information of the event (when the event started, its duration, and traffic statistics). However, you might want redundancy and may monitor both start and stop records of events occurring on the NAS.
Specifying RADIUS Servers
To specify one or more RADIUS servers, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Specify the IP address of up to three RADIUS servers. Specify the primary server using the primary keyword. Optionally, specify the destination UDP port to use on the server.
|
set radius server ip_addr [acct-port port] [primary]
|
Step 2
|
Verify the RADIUS server configuration.
|
show radius
|
This example shows how to specify a RADIUS server and verify the configuration:
Console> (enable) set radius server 172.20.52.3
172.20.52.3 with auth-port 1812 added to radius server table as primary server.
Console> (enable) show radius
Login Authentication: Console Session Telnet Session
--------------------- ---------------- ----------------
local enabled(primary) enabled(primary)
Enable Authentication: Console Session Telnet Session
---------------------- ----------------- ----------------
local enabled(primary) enabled(primary)
Radius Deadtime: 0 minutes
Radius Timeout: 5 seconds
Radius-Server Status Auth-port
----------------------------- ------- ------------
Updating the Server
You can configure the switch to send accounting information to the TACACS+ server. There are two options:
•
Newinfo—Sends accounting information to the server only when new accounting information becomes available.
•
Periodic—Sends accounting update records at regular intervals. This option could be used to keep up-to-date connection and session information even if the NAS restarts and loses the initial start time. You must set a time lapse between periodic updates. Valid intervals are from 1 to 71,582 minutes.
Suppressing Accounting
You can configure the system to suppress accounting when an unknown user with no username accesses the switch by using the set accounting suppress null-username enable command.
Note
RADIUS and TACACS+ accounting are the same, except that RADIUS does not do command accounting, periodic updates, or allow null-username suppression.
Configuring Accounting on the Switch
These sections describe how to configure accounting for both TACACS+ and RADIUS:
•
Accounting Default Configuration
•
Accounting Configuration Guidelines
•
Configuring Accounting
Accounting Default Configuration
Table 21-4 shows the accounting default configuration.
Table 21-4 Accounting Default Configuration
Feature
|
Default Value
|
Accounting
|
Disabled
|
Accounting events (EXEC, system, commands, and connect)
|
Disabled
|
Accounting records
|
Stop-only
|
Accounting Configuration Guidelines
This section describes the guidelines for configuring accounting on the switch:
•
Configure RADIUS and TACACS+ servers before enabling accounting. See the "Specifying TACACS+ Servers" section or the "Specifying RADIUS Servers" section for more information on server setup.
•
Configure RADIUS and TACACS+ keys to encrypt protocol packets before enabling accounting. See the "Specifying the TACACS+ Key" section or the "Specifying the RADIUS Key" section for more information on the key setup.
Note
The amount of DRAM that is allocated for one accounting event is approximately 500 bytes. The total amount of DRAM that is used by accounting depends on the number of concurrent accountable events in the system.
Configuring Accounting
These sections describe how to configure RADIUS and TACACS+ accounting on the switch:
•
Enabling Accounting
•
Disabling Accounting
Enabling Accounting
To enable accounting on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Enable accounting for connection events.
|
set accounting connect enable {start-stop | stop-only} {tacacs+ | radius}
|
Step 2
|
Enable accounting for EXEC mode.
|
set accounting exec enable {start-stop | stop-only} {tacacs+ | radius}
|
Step 3
|
Enable accounting for system events.
|
set accounting system enable {start-stop | stop-only} {tacacs+ | radius}
|
Step 4
|
Enable accounting of configuration commands.
|
set accounting commands enable {config | all} {stop-only} tacacs+
|
Step 5
|
Enable suppression of information for unknown users.
|
set accounting suppress null-username enable
|
Step 6
|
Configure accounting to be updated as new information is available.
|
set accounting update {new-info | {periodic [interval]}}
|
Step 7
|
Verify the accounting configuration.
|
show accounting
|
This example shows how to enable stop-only TACACS+ accounting events:
Console> (enable) set accounting connect enable stop-only tacacs+
Accounting set to enable for connect events in stop-only mode.
Console> (enable) set accounting exec enable stop-only tacacs+
Accounting set to enable for exec events in stop-only mode.
Console> (enable) set accounting system enable stop-only tacacs+
Accounting set to enable for system events in stop-only mode.
Console> (enable) set accounting commands enable all stop-only tacacs+
Accounting set to enable for commands-all events in stop-only mode.
This example shows how to suppress accounting of unknown users:
Console> (enable) set accounting suppress null-username enable
Accounting will be suppressed for user with no username.
This example shows how to update the server periodically:
Console> (enable) set accounting update periodic 120
Accounting updates will be periodic at 120 minute intervals.
This example shows how to verify the configuration:
Console> (enable) show accounting
connect: tacacs+ stop-only
system: tacacs+ stop-only
TACACS+ Suppress for no username: enabled
Update Frequency: periodic, Interval = 120
Active Accounted actions on tty0, User (null) Priv 0
Active Accounted actions on tty288091924, User (null) Priv 0
Overall Accounting Traffic:
Disabling Accounting
To disable RADIUS accounting on the switch, perform this task in privileged mode:
| |
Task
|
Command
|
Step 1
|
Disable accounting for connection events.
|
set accounting connect disable
|
Step 2
|
Disable accounting for EXEC mode.
|
set accounting exec disable
|
Step 3
|
Disable accounting for system events.
|
set accounting system disable
|
Step 4
|
Disable accounting of configuration commands.
|
set accounting commands disable
|
Step 5
|
Disable suppression of information for unknown users.
|
set accounting suppress null-username disable
|
Step 6
|
Verify the accounting configuration.
|
show accounting
|
This example shows how to disable stop-only accounting:
Console> (enable) set accounting connect disable
Accounting set to disable for connect events.
Console> (enable) set accounting exec disable
Accounting set to disable for exec events.
Console> (enable) set accounting system disable
Accounting set to disable for system events.
Console> (enable) set accounting commands disable
Accounting set to disable for commands-all events.
This example shows how to disable suppression of unknown users:
Console> (enable) set accounting suppress null-username disable
Accounting will be not be suppressed for user with no username.
This example shows how to verify the configuration:
Console> (enable) show accounting
TACACS+ Suppress for no username: disabled
Update Frequency: new-info
Active Accounted actions on tty0, User (null) Priv 0
Active Accounted actions on tty288091924, User (null) Priv 0
Overall Accounting Traffic:
Accounting Example
Figure 21-5 shows a simple network topology using TACACS+.
When Workstation A initiates an accountable event on the switch, the switch gathers event information and forwards the information to the server at the conclusion of the event. Accounting information is gathered at the conclusion of the event. Accounting is suspended for unknown users, and the system is updated every 120 minutes.
Figure 21-5 TACACS+ Example Network Topology
In this example, TACACS+ accounting is enabled for connection, EXEC, system, and all command accounting:
Console> (enable) set accounting connect enable stop-only tacacs+
Accounting set to enable for connect events in stop-only mode.
Console> (enable) set accounting exec enable stop-only tacacs+
Accounting set to enable for exec events in stop-only mode.
Console> (enable) set accounting commands enable all stop-only tacacs+
Accounting set to enable for commands-all events in stop-only mode.
Console> (enable) set accounting update periodic 120
Accounting updates will be periodic at 120 minute intervals.
Console> (enable) show accounting
connect: tacacs+ stop-only
system: tacacs+ stop-only
TACACS+ Suppress for no username: enabled
Update Frequency: periodic, Interval = 120
Active Accounted actions on tty0, User (null) Priv 0
Active Accounted actions on tty288091924, User (null) Priv 0
Overall Accounting Traffic: