The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
A simple way of providing terminal access control in your network is to use passwords and assign privilege levels. Password protection restricts access to a network or network device. Privilege levels define what commands users can enter after they have logged into a network device.
Feature | Default Setting |
---|---|
Enable password and privilege level |
No password is defined. The default is level 15 (privileged EXEC level). The password is not encrypted in the configuration file. |
Enable secret password and privilege level |
No password is defined. The default is level 15 (privileged EXEC level). The password is encrypted before it is written to the configuration file. |
Line password |
No password is defined. |
The enable password controls access to the privileged EXEC mode.
1.
enable
6.
copy running-config
startup-config
To provide an additional layer of security, particularly for passwords that cross the network or that are stored on a Trivial File Transfer Protocol (TFTP) server, you can use either the enable password or enable secret global configuration commands. Both commands accomplish the same thing; that is, you can establish an encrypted password that users must enter to access privileged EXEC mode (the default) or any privilege level you specify.
We recommend that you use the enable secret command because it uses an improved encryption algorithm.
If you configure the enable secret command, it takes precedence over the enable password command; the two commands cannot be in effect simultaneously.
Use the level keyword to define a password for a specific privilege level. After you specify the level and set a password, give the password only to users who need to have access at this level. Use the privilege level global configuration command to specify commands accessible at various levels.
If you enable password encryption, it applies to all passwords including username passwords, authentication key passwords, the privileged command password, and console and virtual terminal line passwords.
1.
enable
3.
Use one of the
following.
4.
service password-encryption
7.
copy running-config
startup-config
By default, any end user with physical access to the switch can recover from a lost password by interrupting the boot process while the switch is powering on and then by entering a new password.
The password-recovery disable feature protects access to the switch password by disabling part of this functionality. When this feature is enabled, the end user can interrupt the boot process only by agreeing to set the system back to the default configuration. With password recovery disabled, you can still interrupt the boot process and change the password, but the configuration file (config.text) and the VLAN database file (vlan.dat) are deleted.
Note | If you disable password recovery, we recommend that you keep a backup copy of the configuration file on a secure server in case the end user interrupts the boot process and sets the system back to default values. Do not keep a backup copy of the configuration file on the switch. If the switch is operating in VTP transparent mode, we recommend that you also keep a backup copy of the VLAN database file on a secure server. When the switch is returned to the default system configuration, you can download the saved files to the switch by using the Xmodem protocol. |
Note | Disabling password recovery will not work if you have set the switch to boot up manually by using the boot manualglobal configuration command. This command produces the boot loader prompt (switch:) after the switch is power cycled. |
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | no service password-recovery
|
Disable password recovery. This setting is saved in an area of the flash memory that is accessible by the boot loader and the Cisco IOS image, but it is not part of the file system and is not accessible by any user. |
Step 4 | end
Example: Switch(config)# end | |
Step 5 | show version
|
Verifies the configuration by checking the last few lines of the command output. |
When you power-up your switch for the first time, an automatic setup program runs to assign IP information and to create a default configuration for continued use. The setup program also prompts you to configure your switch for Telnet access through a password. If you did not configure this password during the setup program, you can configure it now through the command-line interface (CLI).
1.
2.
enable
4.
line vty 0 15
5.
passwordpassword
8.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
|
Attach a PC or workstation with emulation software to the switch console port, or attach a PC to the Ethernet management port. The default data characteristics of the console port are 9600, 8, 1, no parity. You might need to press the Return key several times to see the command-line prompt. |
Step 2 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 3 | configure
terminal
Example: Switch# configure terminal | |
Step 4 | line vty 0 15
|
Configure the number of Telnet sessions (lines), and enter line configuration mode. There are 16 possible sessions on a command-capable switch. The 0 and 15 mean that you are configuring all 16 possible Telnet sessions. |
Step 5 | passwordpassword
|
Enter a Telnet password for the line or lines. For password, specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. By default, no password is defined. |
Step 6 | end
Example: Switch(config)# end | |
Step 7 | show running-config
Example: Switch# show running-config | |
Step 8 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
You can configure username and password pairs, which are locally stored on the switch. These pairs are assigned to lines or ports and authenticate each user before that user can access the switch. If you have defined privilege levels, you can also assign a specific privilege level (with associated rights and privileges) to each username and password pair.
1.
enable
3.
username
name[privilege
level] {password
encryption-type
password}
4.
Use one of the following.
5.
login
local
8.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | username
name[privilege
level] {password
encryption-type
password}
|
|
Step 4 | Use one of the following. |
Enters line configuration mode, and configure the console port (line 0) or the VTY lines (line 0 to 15). |
Step 5 | login
local
|
Enables local password checking at login. Authentication is based on the username specified in earlier step. |
Step 6 | end
Example: Switch(config)# end | |
Step 7 | show running-config
Example: Switch# show running-config | |
Step 8 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
By default, the Cisco IOS software has two modes of password security: user EXEC and privileged EXEC. You can configure up to 16 hierarchical levels of commands for each mode. By configuring multiple passwords, you can allow different sets of users to have access to specified commands.
For example, if you want many users to have access to the clear line command, you can assign it level 2 security and distribute the level 2 password fairly widely. But if you want more restricted access to the configure command, you can assign it level 3 security and distribute that password to a more restricted group of users.
When you set a command to a privilege level, all commands whose syntax is a subset of that command are also set to that level. For example, if you set the show ip traffic command to level 15, the show commands and show ip commands are automatically set to privilege level 15 unless you set them individually to different levels.
1.
enable
3.
privilegemodelevellevel
command
4.
enable password levellevel
password
7.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | privilegemodelevellevel
command
|
Sets the privilege level for a command.
|
Step 4 | enable password levellevel
password
|
Specifies the enable password for the privilege level. |
Step 5 | end
Example: Switch(config)# end | |
Step 6 | show running-config
Example: Switch# show running-config | |
Step 7 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
Users can override the privilege level you set using the privilege level line configuration command by logging in to the line and enabling a different privilege level. They can lower the privilege level by using the disable command. If users know the password to a higher privilege level, they can use that password to enable the higher privilege level. You might specify a high level or privilege level for your console line to restrict line usage.
1.
enable
3.
line vty
line
4.
privilege level
level
7.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | line vty
line
|
Selects the virtual terminal line on which to restrict access. |
Step 4 | privilege level
level
|
Changes the default privilege level for the line. For level, the range is from 0 to 15. Level 1 is for normal user EXEC mode privileges. Level 15 is the level of access permitted by the enable password. |
Step 5 | end
Example: Switch(config)# end | |
Step 6 | show running-config
Example: Switch# show running-config | |
Step 7 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
1.
enable
3.
enablelevel
4.
disablelevel
7.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | enablelevel
|
Logs in to a specified privilege level. For level, the range is 0 to 15. |
Step 4 | disablelevel
|
Exits to a specified privilege level. For level, the range is 0 to 15. |
Step 5 | end
Example: Switch(config)# end | |
Step 6 | show running-config
Example: Switch# show running-config | |
Step 7 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
Terminal Access Controller Access Control System Plus (TACACS+) provides detailed accounting information and flexible administrative control over authentication and authorization processes. TACACS+ is facilitated through authentication, authorization, accounting (AAA) and can be enabled only through AAA commands.
Note | We recommend a redundant connection between a switch stack and the TACACS+ server. This is to help ensure that the TACACS+ server remains accessible in case one of the connected stack members is removed from the switch stack. |
TACACS+ provides for separate and modular authentication, authorization, and accounting facilities. TACACS+ allows for a single access control server (the TACACS+ daemon) to provide each service—authentication, authorization, and accounting—independently. Each service can be tied into its own database to take advantage of other services available on that server or on the network, depending on the capabilities of the daemon.
The goal of TACACS+ is to provide a method for managing multiple network access points from a single management service. Your switch can be a network access server along with other Cisco routers and access servers.
Authentication—Provides complete control of authentication through login and password dialog, challenge and response, and messaging support.
The authentication facility can conduct a dialog with the user (for example, after a username and password are provided, to challenge a user with several questions, such as home address, mother’s maiden name, service type, and social security number). The TACACS+ authentication service can also send messages to user screens. For example, a message could notify users that their passwords must be changed because of the company’s password aging policy.
Authorization—Provides fine-grained control over user capabilities for the duration of the user’s session, including but not limited to setting autocommands, access control, session duration, or protocol support. You can also enforce restrictions on what commands a user can execute with the TACACS+ authorization feature.
Accounting—Collects and sends information used for billing, auditing, and reporting to the TACACS+ daemon. Network managers can use the accounting facility to track user activity for a security audit or to provide information for user billing. Accounting records include user identities, start and stop times, executed commands (such as PPP), number of packets, and number of bytes.
The TACACS+ protocol provides authentication between the switch and the TACACS+ daemon, and it ensures confidentiality because all protocol exchanges between the switch and the TACACS+ daemon are encrypted.
You need a system running the TACACS+ daemon software to use TACACS+ on your switch.
When the connection is established, the switch contacts the TACACS+ daemon to obtain a username prompt to show to the user. The user enters a username, and the switch then contacts the TACACS+ daemon to obtain a password prompt. The switch displays the password prompt to the user, the user enters a password, and the password is then sent to the TACACS+ daemon.
TACACS+ allows a dialog between the daemon and the user until the daemon receives enough information to authenticate the user. The daemon prompts for a username and password combination, but can include other items, such as the user’s mother’s maiden name.
The switch eventually receives one of these responses from the TACACS+ daemon:
ACCEPT—The user is authenticated and service can begin. If the switch is configured to require authorization, authorization begins at this time.
REJECT—The user is not authenticated. The user can be denied access or is prompted to retry the login sequence, depending on the TACACS+ daemon.
ERROR—An error occurred at some time during authentication with the daemon or in the network connection between the daemon and the switch. If an ERROR response is received, the switch typically tries to use an alternative method for authenticating the user.
CONTINUE—The user is prompted for additional authentication information.
After authentication, the user undergoes an additional authorization phase if authorization has been enabled on the switch. Users must first successfully complete TACACS+ authentication before proceeding to TACACS+ authorization.
If TACACS+ authorization is required, the TACACS+ daemon is again contacted, and it returns an ACCEPT or REJECT authorization response. If an ACCEPT response is returned, the response contains data in the form of attributes that direct the EXEC or NETWORK session for that user and the services that the user can access:
To configure your switch to support TACACS+ you must identify the host or hosts maintaining the TACACS+ daemon and define the method lists for TACACS+ authentication. You can optionally define method lists for TACACS+ authorization and accounting. A method list defines the sequence and methods to be used to authenticate, to authorize, or to keep accounts on a user. You can use method lists to designate one or more security protocols to be used, thus ensuring a backup system if the initial method fails. The software uses the first method listed to authenticate, to authorize, or to keep accounts on users; if that method does not respond, the software selects the next method in the list. This process continues until there is successful communication with a listed method or the method list is exhausted.
TACACS+ and AAA are disabled by default.
To prevent a lapse in security, you cannot configure TACACS+ through a network management application. When enabled, TACACS+ can authenticate users accessing the switch through the CLI.
Note | Although TACACS+ configuration is performed through the CLI, the TACACS+ server authenticates HTTP connections that have been configured with a privilege level of 15. |
You can configure the switch to use a single server or AAA server groups to group existing server hosts for authentication. You can group servers to select a subset of the configured server hosts and use them for a particular service. The server group is used with a global server-host list and contains the list of IP addresses of the selected server hosts.
1.
enable
3.
tacacs-server
hosthostname[portinteger]
[timeoutinteger]
[keystring]
4.
aaa new-model
5.
aaa group server
tacacs+group-name
6.
serverip-address
9.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | tacacs-server
hosthostname[portinteger]
[timeoutinteger]
[keystring]
|
Identifies the IP host or hosts maintaining a TACACS+ server. Enter this command multiple times to create a list of preferred hosts. The software searches for hosts in the order in which you specify them.
|
Step 4 | aaa new-model
|
Enables AAA. |
Step 5 | aaa group server
tacacs+group-name
|
(Optional) Defines the AAA server-group with a group name. This command puts the switch in a server group subconfiguration mode. |
Step 6 | serverip-address
|
(Optional) Associates a particular TACACS+ server with the defined server group. Repeat this step for each TACACS+ server in the AAA server group. Each server in the group must be previously defined in Step 2. |
Step 7 | end
Example: Switch(config)# end | |
Step 8 | show running-config
Example: Switch# show running-config | |
Step 9 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
To configure AAA authentication, you define a named list of authentication methods and then apply that list to various ports. The method list defines the types of authentication to be performed and the sequence in which they are performed; it must be applied to a specific port before any of the defined authentication methods are performed. The only exception is the default method list (which, by coincidence, is named default). The default method list is automatically applied to all ports except those that have a named method list explicitly defined. A defined method list overrides the default method list.
A method list describes the sequence and authentication methods to be queried to authenticate a user. You can designate one or more security protocols to be used for authentication, thus ensuring a backup system for authentication in case the initial method fails. The software uses the first method listed to authenticate users; if that method fails to respond, the software selects the next authentication method in the method list. This process continues until there is successful communication with a listed authentication method or until all defined methods are exhausted. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops, and no other authentication methods are attempted.
Note | To secure the switch for HTTP access by using AAA methods, you must configure the switch with the ip http authentication aaa global configuration command. Configuring AAA authentication does not secure the switch for HTTP access by using AAA methods. |
1.
enable
3.
aaa new-model
4.
aaa authentication
login{default|list-name}method 1[method 2...]
5.
line[console|tty|vty]line-number[ending-line-number]
6.
login
authentication{default|list-name}
9.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | aaa new-model
|
Enables AAA. |
Step 4 | aaa authentication
login{default|list-name}method 1[method 2...]
|
Creates a login authentication method list.
Select one of these methods:
|
Step 5 | line[console|tty|vty]line-number[ending-line-number]
|
Enters line configuration mode, and configure the lines to which you want to apply the authentication list. |
Step 6 | login
authentication{default|list-name}
|
|
Step 7 | end
Example: Switch(config)# end | |
Step 8 | show running-config
Example: Switch# show running-config | |
Step 9 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
AAA authorization limits the services available to a user. When AAA authorization is enabled, the switch uses information retrieved from the user’s profile, which is located either in the local user database or on the security server, to configure the user’s session. The user is granted access to a requested service only if the information in the user profile allows it.
You can use the aaa authorization global configuration command with the tacacs+ keyword to set parameters that restrict a user’s network access to privileged EXEC mode.
Note | Authorization is bypassed for authenticated users who log in through the CLI even if authorization has been configured. |
1.
enable
3.
aaa authorization network tacacs+
4.
aaa authorization exec
tacacs+
7.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | aaa authorization network tacacs+
|
Configures the switch for user TACACS+ authorization for all network-related service requests. |
Step 4 | aaa authorization exec
tacacs+
|
Configures the switch for user TACACS+ authorization if the user has privileged EXEC access. The exec keyword might return user profile information (such as autocommand information). |
Step 5 | end
Example: Switch(config)# end | |
Step 6 | show running-config
Example: Switch# show running-config | |
Step 7 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
The AAA accounting feature tracks the services that users are accessing and the amount of network resources that they are consuming. When AAA accounting is enabled, the switch reports user activity to the TACACS+ security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. This data can then be analyzed for network management, client billing, or auditing.
1.
enable
3.
aaa accounting network start-stop tacacs+
4.
aaa accounting exec start-stop tacacs+
7.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | aaa accounting network start-stop tacacs+
|
Enables TACACS+ accounting for all network-related service requests. |
Step 4 | aaa accounting exec start-stop tacacs+
|
Enables TACACS+ accounting to send a start-record accounting notice at the beginning of a privileged EXEC process and a stop-record at the end. |
Step 5 | end
Example: Switch(config)# end | |
Step 6 | show running-config
Example: Switch# show running-config | |
Step 7 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
The aaa accounting system guarantee-first command guarantees system accounting as the first record, which is the default condition. In some situations, users might be prevented from starting a session on the console or terminal connection until after the system reloads, which can take more than 3 minutes.
To establish a console or Telnet session with the router if the AAA server is unreachable when the router reloads, use the no aaa accounting system guarantee-first command.
To display TACACS+ server statistics, use the show tacacs privileged EXEC command.
RADIUS provides detailed accounting information and flexible administrative control over authentication and authorization processes. RADIUS is facilitated through AAA and can be enabled only through AAA commands.
RADIUS is a distributed client/server system that secures networks against unauthorized access. RADIUS clients run on supported Cisco routers and switches. Clients send authentication requests to a central RADIUS server, which contains all user authentication and network service access information. The RADIUS host is normally a multiuser system running RADIUS server software from Cisco (Cisco Secure Access Control Server Version 3.0), Livingston, Merit, Microsoft, or another software provider.
Note | We recommend a redundant connection between a switch stack and the RADIUS server. This is to help ensure that the RADIUS server remains accessible in case one of the connected stack members is removed from the switch stack. |
Networks with multiple-vendor access servers, each supporting RADIUS. For example, access servers from several vendors use a single RADIUS server-based security database. In an IP-based network with multiple vendors’ access servers, dial-in users are authenticated through a RADIUS server that has been customized to work with the Kerberos security system.
Turnkey network security environments in which applications support the RADIUS protocol, such as in an access environment that uses a smart card access control system. In one case, RADIUS has been used with Enigma’s security cards to validates users and to grant access to network resources.
Networks already using RADIUS you can add a Cisco switch containing a RADIUS client to the network. This might be the first step when you make a transition to a TACACS+ server.
Networks in which the user must only access a single service, by using RADIUS, you can control user access to a single host, to a single utility such as Telnet, or to the network through a protocol such as IEEE 802.1x.
Networks that require resource accounting, you can use RADIUS accounting independently of RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of services, showing the amount of resources (such as time, packets, bytes, and so forth) used during the session. An Internet service provider might use a freeware-based version of RADIUS access control and accounting software to meet special security and billing needs.
Multiprotocol access environments. RADIUS does not support AppleTalk Remote Access (ARA), NetBIOS Frame Control Protocol (NBFCP), NetWare Asynchronous Services Interface (NASI), or X.25 PAD connections.
Switch-to-switch or router-to-router situations. RADIUS does not provide two-way authentication. RADIUS can be used to authenticate from one device to a non-Cisco device if the non-Cisco device requires authentication.
Networks using a variety of services. RADIUS generally binds a user to one service model.
A standard RADIUS interface is typically used in a pulled model where the request originates from a network attached device and the response come from the queried servers. Catalyst switches support the RADIUS Change of Authorization (CoA) extensions defined in RFC 5176 that are typically used in a pushed model and allow for the dynamic reconfiguring of sessions from external authentication, authorization, and accounting (AAA) or policy servers.
To use the CoA interface, a session must already exist on the switch. CoA can be used to identify a session and enforce a disconnect request. The update affects only the specified session.
The request is initiated from a CoA client (typically a RADIUS or policy server) and directed to the switch that acts as a listener.
The Disconnect Request message, which is also referred to as Packet of Disconnect (POD), is supported by the switch for session termination.
To use the CoA interface, a session must already exist on the switch. CoA can be used to identify a session and enforce a disconnect request. The update affects only the specified session.
Attribute Number | Attribute Name |
---|---|
24 |
State |
31 |
Calling-Station-ID |
44 |
Acct-Session-ID |
80 |
Message-Authenticator |
101 |
Error-Cause |
Attribute Number | Attribute Name |
---|---|
201 |
Residual Session Context Removed |
202 |
Invalid EAP Packet (Ignored) |
401 |
Unsupported Attribute |
402 |
Missing Attribute |
403 |
NAS Identification Mismatch |
404 |
Invalid Request |
405 |
Unsupported Service |
406 |
Unsupported Extension |
407 |
Invalid Attribute Value |
501 |
Administratively Prohibited |
502 |
Request Not Routable (Proxy) |
503 |
Session Context Not Found |
504 |
Session Context Not Removable |
505 |
Other Proxy Processing Error |
506 |
Resources Unavailable |
507 |
Request Initiated |
508 |
Multiple Session Selection Unsupported |
The CoA Request response code can be used to convey a command to the switch.
Unless all session identification attributes included in the CoA message match the session, the switch returns a Disconnect-NAK or CoA-NAK with the “Invalid Attribute Value” error-code attribute.
If more than one session identification attribute is included in the message, all the attributes must match the session or the switch returns a Disconnect- negative acknowledgment (NAK) or CoA-NAK with the error code “Invalid Attribute Value.”
The packet format for a CoA Request code as defined in RFC 5176 consists of the fields: Code, Identifier, Length, Authenticator, and Attributes in Type:Length:Value (TLV) format.
The attributes field is used to carry Cisco VSAs.
If the authorization state is changed successfully, a positive acknowledgment (ACK) is sent. The attributes returned within CoA ACK will vary based on the CoA Request and are discussed in individual CoA Commands.
A negative acknowledgment (NAK) indicates a failure to change the authorization state and can include attributes that indicate the reason for the failure. Use show commands to verify a successful CoA.
To use the CoA interface, a session must already exist on the switch. CoA can be used to identify a session and enforce a disconnect request. The update affects only the specified session.
Command1 | Cisco VSA |
---|---|
Reauthenticate host |
Cisco:Avpair=“subscriber:command=reauthenticate” |
Terminate session |
This is a standard disconnect request that does not require a VSA. |
Bounce host port |
Cisco:Avpair=“subscriber:command=bounce-host-port” |
Disable host port |
Cisco:Avpair=“subscriber:command=disable-host-port” |
The AAA server typically generates a session reauthentication request when a host with an unknown identity or posture joins the network and is associated with a restricted access authorization profile (such as a guest VLAN). A reauthentication request allows the host to be placed in the appropriate authorization group when its credentials are known.
To initiate session authentication, the AAA server sends a standard CoA-Request message which contains a Cisco vendor-specific attribute (VSA) in this form:
Cisco:Avpair=“subscriber:command=reauthenticate” and one or more session identification attributes.
The current session state determines the switch response to the message. If the session is currently authenticated by IEEE 802.1x, the switch responds by sending an EAPoL2-RequestId message to the server.
If the session is currently authenticated by MAC authentication bypass (MAB), the switch sends an access-request to the server, passing the same identity attributes used for the initial successful authentication.
If session authentication is in progress when the switch receives the command, the switch terminates the process, and restarts the authentication sequence, starting with the method configured to be attempted first.
If the session is not yet authorized, or is authorized via guest VLAN, or critical VLAN, or similar policies, the reauthentication message restarts the access control methods, beginning with the method configured to be attempted first. The current authorization of the session is maintained until the reauthentication leads to a different authorization result.
It checkpoints the need for a re-authentication before returning an acknowledgment (ACK).
It initiates reauthentication for the appropriate session.
If authentication completes with either success or failure, the signal that triggered the reauthentication is removed from the stack member.
If the stack master fails before authentication completes, reauthentication is initiated after stack master switch-over based on the original command (which is subsequently removed).
If the stack master fails before sending an ACK, the new stack master treats the re-transmitted command as a new command.
There are three types of CoA requests that can trigger session termination. A CoA Disconnect-Request terminates the session, without disabling the host port. This command causes re-initialization of the authenticator state machine for the specified host, but does not restrict that host’s access to the network.
To restrict a host’s access to the network, use a CoA Request with the Cisco:Avpair="subscriber:command=disable-host-port" VSA. This command is useful when a host is known to be causing problems on the network, and you need to immediately block network access for the host. When you want to restore network access on the port, re-enable it using a non-RADIUS mechanism.
When a device with no supplicant, such as a printer, needs to acquire a new IP address (for example, after a VLAN change), terminate the session on the host port with port-bounce (temporarily disable and then re-enable the port).
This command is a standard Disconnect-Request.
If the session cannot be located, the switch returns a Disconnect-NAK message with the “Session Context Not Found” error-code attribute. If the session is located, the switch terminates the session. After the session has been completely removed, the switch returns a Disconnect-ACK.
If the switch fails-over to a standby switch before returning a Disconnect-ACK to the client, the process is repeated on the new active switch when the request is re-sent from the client. If the session is not found following re-sending, a Disconnect-ACK is sent with the “Session Context Not Found” error-code attribute.
This command is carried in a standard CoA-Request message that has this new VSA: Cisco:Avpair="subscriber:command=disable-host-port"
If the session cannot be located, the switch returns a CoA-NAK message with the “Session Context Not Found” error-code attribute. If the session is located, the switch disables the hosting port and returns a CoA-ACK message.
If the switch fails before returning a CoA-ACK to the client, the process is repeated on the new active switch when the request is re-sent from the client. If the switch fails after returning a CoA-ACK message to the client but before the operation has completed, the operation is restarted on the new active switch.
Note | A Disconnect-Request failure following command re-sending could be the result of either a successful session termination before change-over (if the Disconnect-ACK was not sent) or a session termination by other means (for example, a link failure) that occurred after the original command was issued and before the standby switch became active. |
This command is carried in a standard CoA-Request message that has this new VSA: Cisco:Avpair="subscriber:command=bounce-host-port"
If the session cannot be located, the switch returns a CoA-NAK message with the “Session Context Not Found” error-code attribute. If the session is located, the switch disables the hosting port for a period of 10 seconds, re-enables it (port-bounce), and returns a CoA-ACK.
If the switch fails before returning a CoA-ACK to the client, the process is repeated on the new active switch when the request is re-sent from the client. If the switch fails after returning a CoA-ACK message to the client but before the operation has completed, the operation is restarted on the new active switch.
No special handling is required for CoA Disconnect-Request messages in a switch stack.
Because the bounce-port command is targeted at a session, not a port, if the session is not found, the command cannot be executed.
The switch initiates a port-bounce (disables the port for 10 seconds, then re-enables it).
If the port-bounce is successful, the signal that triggered the port-bounce is removed from the standby stack master.
If the stack master fails before the port-bounce completes, a port-bounce is initiated after stack master change-over based on the original command (which is subsequently removed).
If the stack master fails before sending a CoA-ACK message, the new stack master treats the re-sent command as a new command.
Because the disable-port command is targeted at a session, not a port, if the session is not found, the command cannot be executed.
The switch attempts to disable the port.
If the port-disable operation is successful, the signal that triggered the port-disable is removed from the standby stack master.
If the stack master fails before the port-disable operation completes, the port is disabled after stack master change-over based on the original command (which is subsequently removed).
If the stack master fails before sending a CoA-ACK message, the new stack master treats the re-sent command as a new command.
This section describes how to configure your switch to support RADIUS. At a minimum, you must identify the host or hosts that run the RADIUS server software and define the method lists for RADIUS authentication. You can optionally define method lists for RADIUS authorization and accounting.
A method list defines the sequence and methods to be used to authenticate, to authorize, or to keep accounts on a user. You can use method lists to designate one or more security protocols to be used (such as TACACS+ or local username lookup), thus ensuring a backup system if the initial method fails. The software uses the first method listed to authenticate, to authorize, or to keep accounts on users; if that method does not respond, the software selects the next method in the list. This process continues until there is successful communication with a listed method or the method list is exhausted.
You should have access to and should configure a RADIUS server before configuring RADIUS features on your switch.
RADIUS and AAA are disabled by default.
To prevent a lapse in security, you cannot configure RADIUS through a network management application. When enabled, RADIUS can authenticate users accessing the switch through the CLI.
You identify RADIUS security servers by their hostname or IP address, hostname and specific UDP port numbers, or their IP address and specific UDP port numbers. The combination of the IP address and the UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. This unique identifier enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address.
%RADIUS-4-RADIUS_DEADmessage appears, and then the switch tries the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order that they are configured.)
A RADIUS server and the switch use a shared secret text string to encrypt passwords and exchange responses. To configure RADIUS to use the AAA security commands, you must specify the host running the RADIUS server daemon and a secret text (key) string that it shares with the switch.
The timeout, retransmission, and encryption key values can be configured globally for all RADIUS servers, on a per-server basis, or in some combination of global and per-server settings. To apply these settings globally to all RADIUS servers communicating with the switch, use the three unique global configuration commands: radius-server timeout, radius-server retransmit, and radius-server key. To apply these values on a specific RADIUS server, use the radius-server host global configuration command.
Note | If you configure both global and per-server functions (timeout, retransmission, and key commands) on the switch, the per-server timer, retransmission, and key value commands override global timer, retransmission, and key value commands. |
You can configure the switch to use AAA server groups to group existing server hosts for authentication.
1.
enable
3.
radius-server
host{hostname|ip-address}
[auth-portport-number]
[acct-portport-number]
[timeoutseconds]
[retransmitretires]
[keystrings]
6.
copy running-config
startup-config
Command or Action | Purpose | |||
---|---|---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. | ||
Step 2 | configure
terminal
Example: Switch# configure terminal | |||
Step 3 | radius-server
host{hostname|ip-address}
[auth-portport-number]
[acct-portport-number]
[timeoutseconds]
[retransmitretires]
[keystrings]
|
To configure the switch to recognize more than one host entry associated with a single IP address, enter this command as many times as necessary, making sure that each UDP port number is different. The switch software searches for hosts in the order in which you specify them. Set the timeout, retransmit, and encryption key values to use with the specific RADIUS host. | ||
Step 4 | end
Example: Switch(config)# end | |||
Step 5 | show running-config
Example: Switch# show running-config | |||
Step 6 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
To configure AAA authentication, you define a named list of authentication methods and then apply that list to various ports. The method list defines the types of authentication to be performed and the sequence in which they are performed; it must be applied to a specific port before any of the defined authentication methods are performed. The only exception is the default method list (which, by coincidence, is named default). The default method list is automatically applied to all ports except those that have a named method list explicitly defined.
A method list describes the sequence and authentication methods to be queried to authenticate a user. You can designate one or more security protocols to be used for authentication, thus ensuring a backup system for authentication in case the initial method fails. The software uses the first method listed to authenticate users; if that method fails to respond, the software selects the next authentication method in the method list. This process continues until there is successful communication with a listed authentication method or until all defined methods are exhausted. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops, and no other authentication methods are attempted.
Note | To secure the switch for HTTP access by using AAA methods, you must configure the switch with the ip http authentication aaa global configuration command. Configuring AAA authentication does not secure the switch for HTTP access by using AAA methods. |
1.
enable
3.
aaa new-model
4.
aaa authentication
login{default|
list-name}
lmethod
1[
lmethod
2...]
5.
line[console|tty|vty]line-number[ending-line-number]
6.
login
authentication{default|list-name}
9.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | aaa new-model
|
Enables AAA. |
Step 4 | aaa authentication
login{default|
list-name}
lmethod
1[
lmethod
2...]
|
Create a login authentication method list.
|
Step 5 | line[console|tty|vty]line-number[ending-line-number]
|
Enters line configuration mode, and configure the lines to which you want to apply the authentication list. |
Step 6 | login
authentication{default|list-name}
|
|
Step 7 | end
Example: Switch(config)# end | |
Step 8 | show running-config
Example: Switch# show running-config | |
Step 9 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
You can configure the switch to use AAA server groups to group existing server hosts for authentication. You select a subset of the configured server hosts and use them for a particular service. The server group is used with a global server-host list, which lists the IP addresses of the selected server hosts.
Server groups also can include multiple host entries for the same server if each entry has a unique identifier (the combination of the IP address and UDP port number), allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. If you configure two different host entries on the same RADIUS server for the same service, (for example, accounting), the second configured host entry acts as a fail-over backup to the first one.
You use the server group server configuration command to associate a particular server with a defined group server. You can either identify the server by its IP address or identify multiple host instances or entries by using the optional auth-port and acct-port keywords.
1.
enable
3.
radius-server
host{hostname|ip-address}
[auth-portport-number]
[acct-portport-number]
[timeoutseconds]
[retransmitretries]
[keystring]
4.
aaa new-model
5.
aaa group server
radiusgroup-name
6.
serverip-address
9.
copy running-config
startup-config
Command or Action | Purpose | |||
---|---|---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. | ||
Step 2 | configure
terminal
Example: Switch# configure terminal | |||
Step 3 | radius-server
host{hostname|ip-address}
[auth-portport-number]
[acct-portport-number]
[timeoutseconds]
[retransmitretries]
[keystring]
|
Specify the IP address or hostname of the remote RADIUS server host.
To configure the switch to recognize more than one host entry associated with a single IP address, enter this command as many times as necessary, making sure that each UDP port number is different. The switch software searches for hosts in the order in which you specify them. Set the timeout, retransmit, and encryption key values to use with the specific RADIUS host. | ||
Step 4 | aaa new-model
|
Enables AAA. | ||
Step 5 | aaa group server
radiusgroup-name
|
Defines the AAA server-group with a group name. This command puts the switch in a server group configuration mode. | ||
Step 6 | serverip-address
|
Associates a particular RADIUS server with the defined server group. Repeat this step for each RADIUS server in the AAA server group. Each server in the group must be previously defined in Step 2. | ||
Step 7 | end
Example: Switch(config)# end | |||
Step 8 | show running-config
Example: Switch# show running-config | |||
Step 9 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
AAA authorization limits the services available to a user. When AAA authorization is enabled, the switch uses information retrieved from the user’s profile, which is in the local user database or on the security server, to configure the user’s session. The user is granted access to a requested service only if the information in the user profile allows it.
You can use the aaa authorization global configuration command with the radius keyword to set parameters that restrict a user’s network access to privileged EXEC mode.
Use RADIUS for privileged EXEC access authorization if authentication was performed by using RADIUS.
Use the local database if authentication was not performed by using RADIUS.
Note | Authorization is bypassed for authenticated users who log in through the CLI even if authorization has been configured. |
1.
enable
3.
aaa authorization network radius
4.
aaa authorization exec radius
7.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | aaa authorization network radius
|
Configures the switch for user RADIUS authorization for all network-related service requests. |
Step 4 | aaa authorization exec radius
|
Configures the switch for user RADIUS authorization if the user has privileged EXEC access. The exec keyword might return user profile information (such as autocommand information). |
Step 5 | end
Example: Switch(config)# end | |
Step 6 | show running-config
Example: Switch# show running-config | |
Step 7 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
The AAA accounting feature tracks the services that users are using and the amount of network resources that they are consuming. When you enable AAA accounting, the switch reports user activity to the RADIUS security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. You can then analyze the data for network management, client billing, or auditing.
1.
enable
3.
aaa accounting network start-stop radius
4.
aaa accounting exec start-stop radius
7.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | aaa accounting network start-stop radius
|
Enables RADIUS accounting for all network-related service requests. |
Step 4 | aaa accounting exec start-stop radius
| Enables RADIUS accounting to send a start-record accounting notice at the beginning of a privileged EXEC process and a stop-record at the end. |
Step 5 | end
Example: Switch(config)# end | |
Step 6 | show running-config
Example: Switch# show running-config | |
Step 7 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
1.
enable
3.
radius-server keystring
4.
radius-server retransmit
retries
5.
radius-server timeout
seconds
6.
radius-server deadtime
minutes
9.
copy running-config
startup-config
Command or Action | Purpose | |||
---|---|---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. | ||
Step 2 | configure
terminal
Example: Switch# configure terminal | |||
Step 3 | radius-server keystring
|
Specifies the shared secret text string used between the switch and allRADIUS servers.
| ||
Step 4 | radius-server retransmit
retries
|
Specifies the number of times the switch sends each RADIUS request to the server before giving up. The default is 3; the range 1 to 1000. | ||
Step 5 | radius-server timeout
seconds
|
Specifies the number of seconds a switch waits for a reply to a RADIUS request before resending the request. The default is 5 seconds; the range is 1 to 1000. | ||
Step 6 | radius-server deadtime
minutes
|
Specifies the number of minutes a RADIUS server, which is not responding to authentication requests, to be skipped, thus avoiding the wait for the request to timeout before trying the next configured server. The default is 0; the range is 1 to 1440 minutes. | ||
Step 7 | end
Example: Switch(config)# end | |||
Step 8 | show running-config
Example: Switch# show running-config | |||
Step 9 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
The Internet Engineering Task Force (IETF) draft standard specifies a method for communicating vendor-specific information between the switch and the RADIUS server by using the vendor-specific attribute (attribute 26). Vendor-specific attributes (VSAs) allow vendors to support their own extended attributes not suitable for general use. The Cisco RADIUS implementation supports one vendor-specific option by using the format recommended in the specification. Cisco’s vendor-ID is 9, and the supported option has vendor-type 1, which is named cisco-avpair. The value is a string with this format:
protocol : attribute sep value *
Protocol is a value of the Cisco protocol attribute for a particular type of authorization. Attribute and value are an appropriate attribute-value (AV) pair defined in the Cisco TACACS+ specification, and sep is = for mandatory attributes and is * for optional attributes. The full set of features available for TACACS+ authorization can then be used for RADIUS.
Other vendors have their own unique vendor-IDs, options, and associated VSAs. For more information about vendor-IDs and VSAs, see RFC 2138, “Remote Authentication Dial-In User Service (RADIUS).”
1.
enable
3.
radius-server vsa
send[accounting|authentication]
6.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | radius-server vsa
send[accounting|authentication]
|
Enable the switch to recognize and use VSAs as defined by RADIUS IETF attribute 26.
If you enter this command without keywords, both accounting and authentication vendor-specific attributes are used. |
Step 4 | end
Example: Switch(config)# end | |
Step 5 | show running-config
Example: Switch# show running-config | |
Step 6 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
Although an IETF draft standard for RADIUS specifies a method for communicating vendor-proprietary information between the switch and the RADIUS server, some vendors have extended the RADIUS attribute set in a unique way. Cisco IOS software supports a subset of vendor-proprietary RADIUS attributes.
As mentioned earlier, to configure RADIUS (whether vendor-proprietary or IETF draft-compliant), you must specify the host running the RADIUS server daemon and the secret text string it shares with the switch. You specify the RADIUS host and secret text string by using the radius-server global configuration commands.1.
enable
3.
radius-server
host{hostname|ip-address}non-standard
4.
radius-server keystring
7.
copy running-config
startup-config
Command or Action | Purpose | |||
---|---|---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. | ||
Step 2 | configure
terminal
Example: Switch# configure terminal | |||
Step 3 | radius-server
host{hostname|ip-address}non-standard
|
Specifies the IP address or hostname of the remote RADIUS server host and identify that it is using a vendor-proprietary implementation of RADIUS. | ||
Step 4 | radius-server keystring
|
Specifies the shared secret text string used between the switch and the vendor-proprietary RADIUS server. The switch and the RADIUS server use this text string to encrypt passwords and exchange responses.
| ||
Step 5 | end
Example: Switch(config)# end | |||
Step 6 | show running-config
Example: Switch# show running-config | |||
Step 7 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
1.
enable
3.
aaa new-model
4.
aaa server radius dynamic-author
5.
client{ip-address|name}
[vrfvrfname]
[server-keystring]
6.
server-key[0|7]string
7.
portport-number
8.
auth-type{any|all|session-key}
9.
ignore session-key
10.
ignore server-key
11.
authentication command bounce-port
ignore
12.
authentication command disable-port
ignore
15.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | aaa new-model
|
Enables AAA. |
Step 4 | aaa server radius dynamic-author
|
Configures the switch as an authentication, authorization, and accounting (AAA) server to facilitate interaction with an external policy server. |
Step 5 | client{ip-address|name}
[vrfvrfname]
[server-keystring]
|
Enters dynamic authorization local server configuration mode and specify a RADIUS client from which a device will accept CoA and disconnect requests. |
Step 6 | server-key[0|7]string
|
Configures the RADIUS key to be shared between a device and RADIUS clients. |
Step 7 | portport-number
|
Specifies the port on which a device listens for RADIUS requests from configured RADIUS clients. |
Step 8 | auth-type{any|all|session-key}
|
Specifies the type of authorization the switch uses for RADIUS clients. The client must match all the configured attributes for authorization. |
Step 9 | ignore session-key
|
(Optional) Configures the switch to ignore the session-key. |
Step 10 | ignore server-key
|
(Optional) Configure the switch to ignore the server-key. |
Step 11 | authentication command bounce-port
ignore
|
(Optional) Configure the switch to ignore a CoA request to temporarily disable the port hosting a session. The purpose of temporarily disabling the port is to trigger a DHCP renegotiation from the host when a VLAN change occurs and there is no supplicant on the endpoint to detect the change. |
Step 12 | authentication command disable-port
ignore
|
(Optional) Configure the switch to ignore a nonstandard command requesting that the port hosting a session be administratively shut down. Shutting down the port results in termination of the session. Use standard CLI or SNMP commands to re-enable the port. |
Step 13 | end
Example: Switch(config)# end | |
Step 14 | show running-config
Example: Switch# show running-config | |
Step 15 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
The following Cisco IOS commands can be used to monitor and troubleshoot CoA functionality on the switch:
This feature allows access and authentication requests to be evenly across all RADIUS servers in a server group.
To display the RADIUS configuration, use the show running-config privileged EXEC command.
This section describes how to enable and configure the Kerberos security system, which authenticates requests for network resources by using a trusted third party.
For Kerberos configuration examples, see the “Kerberos Configuration Examples” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide.
For complete syntax and usage information for the commands used in this section, see the “Kerberos Commands” section in the “Security Server Protocols” chapter of the Cisco IOS Security Command Reference.
Kerberos is a secret-key network authentication protocol, which was developed at the Massachusetts Institute of Technology (MIT). It uses the Data Encryption Standard (DES) cryptographic algorithm for encryption and authentication and authenticates requests for network resources. Kerberos uses the concept of a trusted third party to perform secure verification of users and services. This trusted third party is called the key distribution center (KDC).
Kerberos verifies that users are who they claim to be and the network services that they use are what the services claim to be. To do this, a KDC or trusted Kerberos server issues tickets to users. These tickets, which have a limited lifespan, are stored in user credential caches. The Kerberos server uses the tickets instead of usernames and passwords to authenticate users and network services.
The Kerberos credential scheme uses a process called single logon. This process authenticates a user once and then allows secure authentication (without encrypting another password) wherever that user credential is accepted.
This software release supports Kerberos 5, which allows organizations that are already using Kerberos 5 to use the same Kerberos authentication database on the KDC that they are already using on their other network hosts (such as UNIX servers and PCs).
Term | Definition | ||
---|---|---|---|
Authentication |
A process by which a user or service identifies itself to another service. For example, a client can authenticate to a switch or a switch can authenticate to another switch. |
||
Authorization |
A means by which the switch identifies what privileges the user has in a network or on the switch and what actions the user can perform. |
||
Credential |
A general term that refers to authentication tickets, such as TGTs3 and service credentials. Kerberos credentials verify the identity of a user or service. If a network service decides to trust the Kerberos server that issued a ticket, it can be used in place of re-entering a username and password. Credentials have a default lifespan of eight hours. |
||
Instance |
|
||
KDC4 |
Key distribution center that consists of a Kerberos server and database program that is running on a network host. |
||
Kerberized |
A term that describes applications and services that have been modified to support the Kerberos credential infrastructure. |
||
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 server |
A daemon that is 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. |
||
KEYTAB5 |
A password that a network service shares with the KDC. In Kerberos 5 and later Kerberos versions, the network service authenticates an encrypted service credential by using the KEYTAB to decrypt it. In Kerberos versions earlier than Kerberos 5, KEYTAB is referred to as SRVTAB6. |
||
Principal |
Also known as a Kerberos identity, this is who you are or what a service is according to the Kerberos server.
|
||
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. The password is also shared with the user TGT. |
||
SRVTAB |
A password that a network service shares with the KDC. In Kerberos 5 or later Kerberos versions, SRVTAB is referred to as KEYTAB. |
||
TGT |
Ticket granting ticket that is 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. |
A Kerberos server can be a Catalyst switch that is configured as a network security server and that can authenticate remote users by using the Kerberos protocol. Although you can customize Kerberos in a number of ways, remote users attempting to access network services must pass through three layers of security before they can access network services.
The user opens an un-Kerberized Telnet connection to the boundary switch.
The switch prompts the user for a username and password.
The switch requests a TGT from the KDC for this user.
The KDC sends an encrypted TGT that includes the user identity to the switch.
A remote user who initiates a un-Kerberized Telnet session and authenticates to a boundary switch is inside the firewall, but the user must still authenticate directly to the KDC before getting access to the network services. The user must authenticate to the KDC because the TGT that the KDC issues is stored on the switch and cannot be used for additional authentication until the user logs on to the switch.
This section describes the second layer of security through which a remote user must pass. The user must now authenticate to a KDC and obtain a TGT from the KDC to access network services.
For instructions about how to authenticate to a KDC, see the “Obtaining a TGT from a KDC” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide.
This section describes the third layer of security through which a remote user must pass. The user with a TGT must now authenticate to the network services in a Kerberos realm.
For instructions about how to authenticate to a network service, see the “Authenticating to Network Services” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide.
So that remote users can authenticate to network services, you must configure the hosts and the KDC in the Kerberos realm to communicate and mutually authenticate users and network services. To do this, you must identify them to each other. You add entries for the hosts to the Kerberos database on the KDC and add KEYTAB files generated by the KDC to all hosts in the Kerberos realm. You also create entries for the users in the KDC database.
For instructions, see the “Kerberos Configuration Task List” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide.
You can configure AAA to operate without a server by setting the switch to implement AAA in local mode. The switch then handles authentication and authorization. No accounting is available in this configuration.
1.
enable
3.
aaa new-model
4.
aaa authentication
logindefault
local
5.
aaa authorization exec
local
6.
aaa authorization network
local
7.
usernamename[privilegelevel]
{passwordencryption-type password}
10.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | aaa new-model
|
Enables AAA. |
Step 4 | aaa authentication
logindefault
local
|
Sets the login authentication to use the local username database. The default keyword applies the local user database authentication to all ports. |
Step 5 | aaa authorization exec
local
|
Configures user AAA authorization, checks the local database, and allows the user to run an EXEC shell. |
Step 6 | aaa authorization network
local
|
Configures user AAA authorization for all network-related service requests. |
Step 7 | usernamename[privilegelevel]
{passwordencryption-type password}
|
Enters the local database, and establishes a username-based authentication system. Repeat this command for each user.
|
Step 8 | end
Example: Switch(config)# end | |
Step 9 | show running-config
Example: Switch# show running-config | |
Step 10 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
For SSH configuration examples, see the “SSH Configuration Examples” section in the “Configuring Secure Shell” section in the “Other Security Features” chapter of the Cisco IOS Security Configuration Guide.
Note | We recommend a redundant connection between a switch stack and the RADIUS server. This is to help ensure that the RADIUS server remains accessible in case one of the connected stack members is removed from the switch stack. |
SSH functions the same in IPv6 as in IPv4. For IPv6, SSH supports IPv6 addresses and enables secure, encrypted connections with remote IPv6 nodes over an IPv6 transport.
SSH is a protocol that provides a secure, remote connection to a device. SSH provides more security for remote connections than Telnet does by providing strong encryption when a device is authenticated. This software release supports SSH Version 1 (SSHv1) and SSH Version 2 (SSHv2).
The SSH feature has an SSH server and an SSH integrated client, which are applications that run on the switch. You can use an SSH client to connect to a switch running the SSH server. The SSH server works with the SSH client supported in this release and with non-Cisco SSH clients. The SSH client also works with the SSH server supported in this release and with non-Cisco SSH servers.
The switch supports an SSHv1 or an SSHv2 server.
The switch supports an SSHv1 client.
SSH supports the Data Encryption Standard (DES) encryption algorithm, the Triple DES (3DES) encryption algorithm, and password-based user authentication.
Note | This software release does not support IP Security (IPSec). |
The switch supports Rivest, Shamir, and Adelman (RSA) authentication.
SSH supports only the execution-shell application.
The SSH server and the SSH client are supported only on DES (56-bit) and 3DES (168-bit) data encryption software.
The switch supports the Advanced Encryption Standard (AES) encryption algorithm with a 128-bit key, 192-bit key, or 256-bit key. However, symmetric cipher AES to encrypt the keys is not supported.
This section describes how to configure your switch to support SSH.
An RSA key pair generated by a SSHv1 server can be used by an SSHv2 server, and the reverse.
If the SSH server is running on a stack master and the stack master fails, the new stack master uses the RSA key pair generated by the previous stack master.
If you get CLI error messages after entering the crypto key generate rsa global configuration command, an RSA key pair has not been generated. Reconfigure the hostname and domain, and then enter the crypto key generate rsa command.
No host name specifiedmight appear. If it does, you must configure a hostname by using the hostname global configuration command.
No domain specifiedmight appear. If it does, you must configure an IP domain name by using the ip domain-name global configuration command.
When configuring the local authentication and authorization authentication method, make sure that AAA is disabled on the console.
Configure a hostname and IP domain name for the switch. Follow this procedure only if you are configuring the switch as an SSH server.
Generate an RSA key pair for the switch, which automatically enables SSH. Follow this procedure only if you are configuring the switch as an SSH server.
Configure user authentication for local or remote access. This step is required.
1.
enable
3.
hostnamehostname
4.
ip domain-namedomain_name
5.
crypto key generate
rsa
7.
show ip ssh
8.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | hostnamehostname
|
Configures a hostname for your switch. |
Step 4 | ip domain-namedomain_name
|
Configures a host domain for your switch. |
Step 5 | crypto key generate
rsa
|
Enable the SSH server for local and remote authentication on the switch and generate an RSA key pair. We recommend that a minimum modulus size of 1024 bits. When you generate RSA keys, you are prompted to enter a modulus length. A longer modulus length might be more secure, but it takes longer to generate and to use. |
Step 6 | end
Example: Switch(config)# end | |
Step 7 | show ip ssh
|
Shows the version and configuration information for your SSH server. |
Step 8 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
1.
enable
3.
ip ssh version[1|2]
4.
ip ssh{timeoutseconds|authentication-retriesnumber}
5.
line
vtyline_number[ending_line_number]transport
input ssh
7.
show ip ssh
8.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | ip ssh version[1|2]
|
If you do not enter this command or do not specify a keyword, the SSH server selects the latest SSH version supported by the SSH client. For example, if the SSH client supports SSHv1 and SSHv2, the SSH server selects SSHv2. |
Step 4 | ip ssh{timeoutseconds|authentication-retriesnumber}
|
Repeat this step when configuring both parameters. |
Step 5 | line
vtyline_number[ending_line_number]transport
input ssh
|
|
Step 6 | end
Example: Switch(config)# end | |
Step 7 | show ip ssh
|
Shows the version and configuration information for your SSH server. |
Step 8 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
Command | Purpose |
---|---|
show ip ssh |
Shows the version and configuration information for the SSH server. |
show ssh |
Shows the status of the SSH server. |
For more information about these commands, see the “Secure Shell Commands” section in the “Other Security Features” chapter of the Cisco IOS Security Command Reference.
This section describes how to configure Secure Socket Layer (SSL) Version 3.0 support for the HTTP 1.1 server and client. SSL provides server authentication, encryption, and message integrity, as well as HTTP client authentication, to allow secure HTTP communications.
On a secure HTTP connection, data to and from an HTTP server is encrypted before being sent over the Internet. HTTP with SSL encryption provides a secure connection to allow such functions as configuring a switch from a Web browser. Cisco's implementation of the secure HTTP server and secure HTTP client uses an implementation of SSL Version 3.0 with application-layer encryption. HTTP over SSL is abbreviated as HTTPS; the URL of a secure connection begins with https:// instead of http://.
The primary role of the HTTP secure server (the switch) is to listen for HTTPS requests on a designated port (the default HTTPS port is 443) and pass the request to the HTTP 1.1 Web server. The HTTP 1.1 server processes requests and passes responses (pages) back to the HTTP secure server, which, in turn, responds to the original request.
The primary role of the HTTP secure client (the web browser) is to respond to Cisco IOS application requests for HTTPS User Agent services, perform HTTPS User Agent services for the application, and pass the response back to the application.
Certificate authorities (CAs) manage certificate requests and issue certificates to participating network devices. These services provide centralized security key and certificate management for the participating devices. Specific CA servers are referred to as trustpoints.
When a connection attempt is made, the HTTPS server provides a secure connection by issuing a certified X.509v3 certificate, obtained from a specified CA trustpoint, to the client. The client (usually a Web browser), in turn, has a public key that allows it to authenticate the certificate.
For secure HTTP connections, we highly recommend that you configure a CA trustpoint. If a CA trustpoint is not configured for the device running the HTTPS server, the server certifies itself and generates the needed RSA key pair. Because a self-certified (self-signed) certificate does not provide adequate security, the connecting client generates a notification that the certificate is self-certified, and the user has the opportunity to accept or reject the connection. This option is useful for internal network topologies (such as testing).
If the switch is not configured with a hostname and a domain name, a temporary self-signed certificate is generated. If the switch reboots, any temporary self-signed certificate is lost, and a new temporary new self-signed certificate is assigned.
If the switch has been configured with a host and domain name, a persistent self-signed certificate is generated. This certificate remains active if you reboot the switch or if you disable the secure HTTP server so that it will be there the next time you re-enable a secure HTTP connection.
Note | The certificate authorities and trustpoints must be configured on each device individually. Copying them from other devices makes them invalid on the switch. |
If a self-signed certificate has been generated, this information is included in the output of the show running-config privileged EXEC command.
A CipherSuite specifies the encryption algorithm and the digest algorithm to use on a SSL connection. When connecting to the HTTPS server, the client Web browser offers a list of supported CipherSuites, and the client and server negotiate the best encryption algorithm to use from those on the list that are supported by both. For example, Netscape Communicator 4.76 supports U.S. security with RSA Public Key Cryptography, MD2, MD5, RC2-CBC, RC4, DES-CBC, and DES-EDE3-CBC.
For the best possible encryption, you should use a client browser that supports 128-bit encryption, such as Microsoft Internet Explorer Version 5.5 (or later) or Netscape Communicator Version 4.76 (or later). The SSL_RSA_WITH_DES_CBC_SHA CipherSuite provides less security than the other CipherSuites, as it does not offer 128-bit encryption.
SSL_RSA_WITH_DES_CBC_SHA—RSA key exchange (RSA Public Key Cryptography) with DES-CBC for message encryption and SHA for message digest
SSL_RSA_WITH_RC4_128_MD5—RSA key exchange with RC4 128-bit encryption and MD5 for message digest
SSL_RSA_WITH_RC4_128_SHA—RSA key exchange with RC4 128-bit encryption and SHA for message digest
SSL_RSA_WITH_3DES_EDE_CBC_SHA—RSA key exchange with 3DES and DES-EDE3-CBC for message encryption and SHA for message digest
RSA (in conjunction with the specified encryption and digest algorithm combinations) is used for both key generation and authentication on SSL connections. This usage is independent of whether or not a CA trustpoint is configured.
This section describes how to configure secure HTTP servers and clients.
When SSL is used in a switch cluster, the SSL session terminates at the cluster commander. Cluster member switches must run standard HTTP.
Before you configure a CA trustpoint, you should ensure that the system clock is set. If the clock is not set, the certificate is rejected due to an incorrect date.
In a switch stack, the SSL session terminates at the stack master.
For secure HTTP connections, we recommend that you configure an official CA trustpoint.
A CA trustpoint is more secure than a self-signed certificate.
1.
enable
3.
hostnamehostname
4.
ip domain-namedomain-name
5.
crypto key generate
rsa
6.
crypto ca trustpointname
7.
enrollment urlurl
8.
enrollment
http-proxyhost-nameport-number
9.
crl queryurl
10.
primaryurl
11.
exiturl
12.
crypto ca authenticationname
13.
crypto ca enrollname
15.
show crypto ca trustpoints
16.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | hostnamehostname
|
Specifies the hostname of the switch (required only if you have not previously configured a hostname). The hostname is required for security keys and certificates. |
Step 4 | ip domain-namedomain-name
|
Specifies the IP domain name of the switch (required only if you have not previously configured an IP domain name). The domain name is required for security keys and certificates. |
Step 5 | crypto key generate
rsa
|
(Optional) Generates an RSA key pair. RSA key pairs are required before you can obtain a certificate for the switch. RSA key pairs are generated automatically. You can use this command to regenerate the keys, if needed. |
Step 6 | crypto ca trustpointname
|
Specifies a local configuration name for the CA trustpoint and enter CA trustpoint configuration mode. |
Step 7 | enrollment urlurl
|
Specifies the URL to which the switch should send certificate requests. |
Step 8 | enrollment
http-proxyhost-nameport-number
|
(Optional) Configures the switch to obtain certificates from the CA through an HTTP proxy server. |
Step 9 | crl queryurl
|
Configures the switch to request a certificate revocation list (CRL) to ensure that the certificate of the peer has not been revoked. |
Step 10 | primaryurl
|
(Optional) Specifies that the trustpoint should be used as the primary (default) trustpoint for CA requests. |
Step 11 | exiturl
|
Exits CA trustpoint configuration mode and return to global configuration mode. |
Step 12 | crypto ca authenticationname
|
Authenticates the CA by getting the public key of the CA. Use the same name used in Step 5. |
Step 13 | crypto ca enrollname
|
Obtains the certificate from the specified CA trustpoint. This command requests a signed certificate for each RSA key pair. |
Step 14 | end
Example: Switch(config)# end | |
Step 15 | show crypto ca trustpoints
|
Verifies the configuration. |
Step 16 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
If you are using a certificate authority for certification, you should use the previous procedure to configure the CA trustpoint on the switch before enabling the HTTP server. If you have not configured a CA trustpoint, a self-signed certificate is generated the first time that you enable the secure HTTP server. After you have configured the server, you can configure options (path, access list to apply, maximum number of connections, or timeout policy) that apply to both standard and secure HTTP servers.
1.
enable
2.
show ip http server status
4.
ip http secure-server
5.
ip http secure-portport-number
6.
ip http secure-ciphersuite {[3des-ede-cbc-sha] [rc4-128-md5]
[rc4-128-sha] [des-cbc-sha]}
7.
ip http secure-client-auth
8.
ip http secure-trustpointname
9.
ip http pathpath-name
10.
ip http access-classaccess-list-number
11.
ip http max-connectionsvalue
12.
ip http timeout-policy idlesecondslifesecondsrequestsvalue
14.
ip http server secure status
15.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | show ip http server status
|
(Optional) Displays the status of the HTTP server to determine if the secure HTTP server feature is supported in the software. |
Step 3 | configure
terminal
Example: Switch# configure terminal | |
Step 4 | ip http secure-server
|
Enables the HTTPS server if it has been disabled. The HTTPS server is enabled by default. |
Step 5 | ip http secure-portport-number
|
(Optional) Specifies the port number to be used for the HTTPS server. The default port number is 443. Valid options are 443 or any number in the range 1025 to 65535. |
Step 6 | ip http secure-ciphersuite {[3des-ede-cbc-sha] [rc4-128-md5]
[rc4-128-sha] [des-cbc-sha]}
|
(Optional) Specifies the CipherSuites (encryption algorithms) to be used for encryption over the HTTPS connection. If you do not have a reason to specify a particularly CipherSuite, you should allow the server and client to negotiate a CipherSuite that they both support. This is the default. |
Step 7 | ip http secure-client-auth
|
(Optional) Configures the HTTP server to request an X.509v3 certificate from the client for authentication during the connection process. The default is for the client to request a certificate from the server, but the server does not attempt to authenticate the client. |
Step 8 | ip http secure-trustpointname
|
Specifies the CA trustpoint to use to get an X.509v3 security certificate and to authenticate the client certificate connection. |
Step 9 | ip http pathpath-name
|
(Optional) Sets a base HTTP path for HTML files. The path specifies the location of the HTTP server files on the local system (usually located in system flash memory). |
Step 10 | ip http access-classaccess-list-number
|
(Optional) Specifies an access list to use to allow access to the HTTP server. |
Step 11 | ip http max-connectionsvalue
|
(Optional) Sets the maximum number of concurrent connections that are allowed to the HTTP server. The range is 1 to 16; the default value is 5. |
Step 12 | ip http timeout-policy idlesecondslifesecondsrequestsvalue
|
|
Step 13 | end
Example: Switch(config)# end | |
Step 14 | ip http server secure status
|
Displays the status of the HTTP secure server to verify the configuration. |
Step 15 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
The standard HTTP client and secure HTTP client are always enabled. A certificate authority is required for secure HTTP client certification. This procedure assumes that you have previously configured a CA trustpoint on the switch. If a CA trustpoint is not configured and the remote HTTPS server requires client authentication, connections to the secure HTTP client fail.
1.
enable
3.
ip http client secure-trustpointname
4.
ip http client secure-ciphersuite {[3des-ede-cbc-sha]
[rc4-128-md5] [rc4-128-sha] [des-cbc-sha]}
6.
ishow ip http client secure status
7.
copy running-config
startup-config
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example:
Switch> enable
|
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 | configure
terminal
Example: Switch# configure terminal | |
Step 3 | ip http client secure-trustpointname
|
(Optional) Specifies the CA trustpoint to be used if the remote HTTP server requests client authentication. Using this command assumes that you have already configured a CA trustpoint by using the previous procedure. The command is optional if client authentication is not needed or if a primary trustpoint has been configured. |
Step 4 | ip http client secure-ciphersuite {[3des-ede-cbc-sha]
[rc4-128-md5] [rc4-128-sha] [des-cbc-sha]}
|
(Optional) Specifies the CipherSuites (encryption algorithms) to be used for encryption over the HTTPS connection. If you do not have a reason to specify a particular CipherSuite, you should allow the server and client to negotiate a CipherSuite that they both support. This is the default. |
Step 5 | end
Example: Switch(config)# end | |
Step 6 | ishow ip http client secure status
|
Displays the status of the HTTP secure server to verify the configuration. |
Step 7 | copy running-config
startup-config
Example:
Switch# copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
Command | Purpose |
---|---|
show ip http client secure status |
Shows the HTTP secure client configuration. |
show ip http server secure status |
Shows the HTTP secure server configuration. |
show running-config |
Shows the generated self-signed certificate for secure HTTP connections. |
The Secure Copy Protocol (SCP) feature provides a secure and authenticated method for copying switch configurations or switch image files. SCP relies on Secure Shell (SSH), an application and a protocol that provides a secure replacement for the Berkeley r-tools.
For SSH to work, the switch needs an RSA public/private key pair. This is the same with SCP, which relies on SSH for its secure transport.
Note | When using SCP, you cannot enter the password into the copy command. You must enter the password when prompted. |
To configure the Secure Copy feature, you should understand these concepts.
The behavior of SCP is similar to that of remote copy (rcp), which comes from the Berkeley r-tools suite, except that SCP relies on SSH for security. SCP also requires that authentication, authorization, and accounting (AAA) authorization be configured so the router can determine whether the user has the correct privilege level.
A user who has appropriate authorization can use SCP to copy any file in the Cisco IOS File System (IFS) to and from a switch by using the copy command. An authorized administrator can also do this from a workstation.
For information about how to configure and verify SCP, see the “Secure Copy Protocol” section in the Cisco IOS Security Configuration Guide: Securing User Services.
This example shows how to change the enable password to l1u2c3k4y5. The password is not encrypted and provides access to level 15 (traditional privileged EXEC mode access):
Switch(config)# enable password l1u2c3k4y5
This example shows how to configure the encrypted password $1$FaD0$Xyti5Rkls3LoyxzS8 for privilege level 2:
Switch(config)# enable secret level 2 5 $1$FaD0$Xyti5Rkls3LoyxzS8
This example shows how to set the Telnet password to let45me67in89:
Switch(config)# line vty 10 Switch(config)# password let45me67in89
This example shows how to set the configure command to privilege level 14 and define SecretPswd14 as the password users must enter to use level 14 commands:
Switch(config)# privilege exec level 14 configure Switch(config)# enable password level 14 SecretPswd14
This example shows how to configure one RADIUS server to be used for authentication and another to be used for accounting:
Switch(config)# radius-server host 172.29.36.49 auth-port 1612 key rad1 Switch(config)# radius-server host 172.20.36.50 acct-port 1618 key rad2
This example shows how to configure host1 as the RADIUS server and to use the default ports for both authentication and accounting:
Switch(config)# radius-server host host1
In this example, the switch is configured to recognize two different RADIUS group servers (group1 and group2). Group1 has two different host entries on the same RADIUS server configured for the same services. The second host entry acts as a fail-over backup to the first entry.
Switch(config)# radius-server host 172.20.0.1 auth-port 1000 acct-port 1001 Switch(config)# radius-server host 172.10.0.1 auth-port 1645 acct-port 1646 Switch(config)# aaa new-model Switch(config)# aaa group server radius group1 Switch(config)# server 172.20.0.1 auth-port 1000 acct-port 1001 Switch(config)# exit Switch(config)# aaa group server radius group2 Switch(config)# server 172.20.0.1 auth-port 2000 acct-port 2001 Switch(config)# exit
This example shows how to specify a vendor-proprietary RADIUS host and to use a secret key of rad124 between the switch and the server:
Switch(config)# radius-server host 172.20.30.15 nonstandard Switch(config)# radius-server key rad124