Table Of Contents
Configuring Switch Access Using AAA
Understanding How Authentication Works
Authentication Overview
Understanding How Login Authentication Works
Understanding How Local Authentication Works
Understanding How TACACS+ Authentication Works
Understanding How RADIUS Authentication Works
Understanding How Kerberos Authentication Works
Using Kerberized Login Procedure
Using a Non-Kerberized Login Procedure
Understanding How 802.1x Authentication Works
Traffic Control
Authentication Server
802.1x Parameters Configurable on the Switch
Configuring Authentication
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 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 Deadtime
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
Configuring 802.1x Authentication
Enabling 802.1x Globally
Disabling 802.1x Globally
Enabling and Initializing 802.1x Authentication for Individual Ports
Setting and Enabling Automatic Reauthentication of the Supplicant
Manually Reauthenticating the Supplicant
Enabling Multiple Hosts
Disabling Multiple Hosts
Setting the Quiet Period
Setting the Authenticator-to-Supplicant Retransmission Time for EAP-Request/Identity Frames
Setting the Back-End Authenticator-to-Supplicant Retransmission Time for EAP-Request Frames
Setting theBack-End Authenticator-to-Authentication-Server Retransmission Time for Transport Layer Packets
Setting the Back-End Authenticator-to-Supplicant Frame-Retransmission Number
Resetting the 802.1x Configuration Parameters to the Default Values
Using the show Commands
Authentication Example
Understanding How Authorization Works
Authorization Overview
Authorization Events
TACACS+ Primary Options and Fallback Options
TACACS+ Command Authorization
RADIUS Authorization
Configuring Authorization
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
Accounting Default Configuration
Accounting Configuration Guidelines
Configuring Accounting
Enabling Accounting
Disabling Accounting
Accounting Example
Configuring 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 6000 family switches.
Note
For complete syntax and usage information for the commands used in this chapter, refer to the Catalyst 6000 Family Command Reference publication.
This chapter consists of these sections:
•
Understanding How Authentication Works
•
Configuring Authentication
•
Authentication Example
•
Understanding How Authorization Works
•
Configuring Authorization
•
Authorization Example
•
Understanding How Accounting Works
•
Configuring Accounting
•
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 TACACS+ Authentication Works
•
Understanding How RADIUS Authentication Works
•
Understanding How Kerberos Authentication Works
•
Understanding How 802.1x 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
•
802.1x 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.
You can enable login authentication access attempts within a range of three (the default) to ten tries. When a user reaches the set limit without successfully logging in, SNMP traps and syslog messages are generated and the lockout restriction occurs. Setting the login authentication to zero (0) disables the login limit checking.
If a user attempts to log in to privileged mode and fails, the system disables execution of the enable command for the lockout period.
The lockout time is configurable from the CLI and SNMP. The configurable range is 30 to 600 seconds. If a user is locked out at the console, the console does not allow the user to log in during that lockout time. If a user is locked out with a Telnet session, the connection closes when the limit is reached, and any subsequent accesses from that station are closed immediately (with proper notice) by the switch during the lockout time.
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 user names.
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 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 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 configured on the TACACS+ servers. The TACACS+ clients and servers use the key to encrypt all TACACS+ packets transmitted. 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 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 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 RADIUS packets transmitted. 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 used to encrypt RADIUS packets
•
Specify the RADIUS server timeout interval
•
Specify the RADIUS retransmit count
•
Specify the RADIUS server deadtime 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 terms used in Kerberos.
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 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 6000 family 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 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 Telnet to the switch:
1.
The Telnet client asks the user 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 the user's password and sends the TGT to the client.
3.
When the Telnet client receives the encrypted TGT, it prompts the user for the password. If the Telnet client can decrypt the TGT with the entered password, the user is successfully authenticated to the KDC. The client then builds a service credential request and sends this to the KDC. This request contains the user's identity and a message saying that it wants to Telnet to the switch. 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 the user does 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," the client software provided with the Kerberos package.
Figure 21-2 shows the non-Kerberized login process.
Figure 21-2 Non-Kerberized Telnet Connection
Understanding How 802.1x Authentication Works
IEEE 802.1x is a client-server-based access control and authentication protocol that restricts unauthorized devices from connecting to a LAN through publicly accessible
ports. 802.1x authenticates each user device connected to a switch port before making available
any services offered by the switch or the LAN. Until the device is authenticated, 802.1x access
control allows only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port
to which the device is connected. After authentication is successful, normal traffic can pass through
the port.
802.1x controls network access by creating two distinct virtual access points at each port. One access point is an uncontrolled port; the other is a controlled port. All traffic through the single port is available to both access points. Only EAPOL traffic is allowed to pass through the uncontrolled port, which is always open. The controlled port is open only when the device connected to the port has been authorized by 802.1x. After this authorization takes place, the controlled port opens, allowing normal traffic to pass.
Table 21-2 defines the terms used in 802.1x.
Table 21-2 802.1x Terminology
Term
|
Definition
|
Authenticator PAE
|
(Referred to as the "authenticator") entity at one end of a point-to-point LAN segment that enforces supplicant authentication. The authenticator is independent of the actual authentication method and functions only as a pass-through for the authentication exchange. It communicates with the supplicant, submits the information from the supplicant to the authentication server, and authorizes the supplicant when instructed to do so by the authentication server.
|
Authentication server
|
Entity that provides the authentication service for the authenticator PAE. It checks the credentials of the supplicant PAE and then notifies its client, the authenticator PAE, whether the supplicant PAE is authorized to access the LAN/switch services.
|
Authorized state
|
Status of the port after the supplicant PAE is authorized.
|
Both
|
Bidirectional flow control, incoming and outgoing, at an unauthorized switch port.
|
Controlled port
|
Secured access point.
|
EAP
|
Extensible Authentication Protocol.
|
EAPOL1
|
Encapsulated EAP messages that can be handled directly by a LAN MAC service.
|
In
|
Flow control only on incoming frames in an unauthorized switch port.
|
Port
|
Single point of attachment to the LAN infrastructure (for example, MAC bridge ports).
|
PAE2
|
Protocol object associated with a specific system port.
|
PDU
|
Protocol data unit.
|
RADIUS
|
Remote Access Dial-In User Service.
|
Supplicant PAE
|
(Referred to as the "supplicant") entity that requests access to the LAN/switch services and responds to information requests from the authenticator.
|
Unauthorized state
|
Status of the port before the supplicant PAE is authorized.
|
Uncontrolled port
|
Unsecured access point that allows the uncontrolled exchange of PDUs.
|
Traffic Control
You can restrict traffic in both directions or just incoming traffic.
Authentication Server
The frames exchanged between the authenticator and the authentication server are dependent on the authentication mechanism, so they are not defined by the 802.1x standard. You can use other protocols, but we recommend RADIUS for authentication, particularly when the authentication server is located remotely, because RADIUS has extensions that support encapsulation of EAP frames built into it.
802.1x Parameters Configurable on the Switch
You can configure these 802.1x parameters on the switch:
•
Force-Authorized, Force-Unauthorized, or Automatic 802.1x port control
•
Enable or disable multiple hosts on a specific port
•
Enable or disable system authentication control
•
Specify quiet time interval
•
Specify the authenticator to supplicant retransmission time interval
•
Specify the back-end authenticator to supplicant retransmission time interval
•
Specify the back-end authenticator to authentication server retransmission time interval
•
Specify the number of frames retransmitted from the back-end authenticator to supplicant
•
Specify the automatic supplicant reauthentication time interval
•
Enable or disable automatic supplicant reauthentication
Configuring Authentication
These sections describe how to configure the different authentication methods:
•
Authentication Default Configuration
•
Authentication Configuration Guidelines
•
Configuring Login Authentication
•
Configuring Local Authentication
•
Configuring TACACS+ Authentication
•
Configuring RADIUS Authentication
•
Configuring Kerberos Authentication
•
Configuring 802.1x Authentication
•
Authentication Example
Authentication Default Configuration
Table 21-3 shows the default authentication configuration.
Table 21-3 Authentication Default Configuration
Feature
|
Default Value
|
Login authentication (console and Telnet)
|
Enabled
|
Local authentication (console and Telnet)
|
Enabled
|
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 deadtime
|
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
|
802.1x port control
|
Force-Authorized
|
802.1x multiple hosts
|
Disabled
|
802.1x system authentication control
|
Enable
|
802.1x quiet period time
|
60 seconds
|
802.1x authenticator to supplicant retransmission time
|
30 seconds
|
802.1x back-end authenticator to supplicant retransmission time
|
30 seconds
|
802.1x back-end authenticator to authentication server retransmission time
|
30 seconds
|
802.1x number of frames retransmitted from back-end authenticator to supplicant
|
2
|
802.1x automatic supplicant reauthentication time
|
3600 seconds
|
802.1x automatic authenticator reauthentication of supplicant
|
Disabled
|
Authentication Configuration Guidelines
Follow these guidelines when 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 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.
•
802.1x will work with other protocols, but we recommend RADIUS, particularly with a remotely located authentication server.
•
You cannot enable 802.1x on a secure port until you turn off the security feature on that port. You cannot enable security on an 802.1x port.
•
802.1x is only supported on Ethernet ports.
•
You cannot enable 802.1x on a trunk port until you turn off the trunking feature on that port. You cannot enable trunking on an 802.1x port.
•
You cannot enable 802.1x on a dynamic port until you turn off the DVLAN feature on that port. You cannot enable DVLAN on an 802.1x port.
•
You cannot enable 802.1x on a channeling port until you turn off the channeling feature on that port. You cannot enable channeling on an 802.1x port.
•
You cannot enable 802.1x on a Multiple VLAN Access Port (MVAP) with an auxiliary VLAN ID until you turn off the auxiliary VLAN ID feature on that port. You cannot enable an auxiliary VLAN ID on an 802.1x port.
•
You cannot enable 802.1x on a switched port analyzer (SPAN) destination port. You cannot configure SPAN destination on an 802.1x port. However, you can configure an 802.1x port as a SPAN source port.
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 five, 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 to five, 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 the following task 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 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: