Category: Access Control

AAA command authorization gotchas

Once upon a time, AAA command authorization in Cisco IOS queried the TACACS+ server for every single command a user entered. Rules have changed drastically in the meantime (at least for IOS release 12.4):

  • Non-privileged show commands are executed without TACACS+ authorization. Privileged show commands (show running or show archive log config) are still authorized.
  • Some commands that can be executed in non-privileged (aka disable) mode (enable, disable, help, logout) are authorized only if you configure aaa authorization commands 0 methods regardless of the current privilege level.
  • Other commands (for example, ping) are authorized based on the current privilege level.

For example, if you’ve configured AAA command authorization only for privilege level 15, the ping command will be authorized if you’re working in enable mode, but not otherwise.

  • Command authorization is not performed on console unless you’ve configured aaa authorization console.
read more see 6 comments

SSH works without AAA

I was always under impression that you have to configure AAA (even if you have local passwords) if you want to use SSH on a Cisco router. Based on the comment made by shef I tried various options and found out that SSH works without AAA (at least in IOS releases 12.4 and 12.2SRC). In both cases, you can configure AAA authentication (using AAA servers or local passwords) or local username/password authentication (you can also use enhanced password security).
read more see 13 comments

Identifying TACACS+ failure

I've got an interesting question from Colin a while ago:

I would like to generate a different prompt during the login to the router if the TACACS+ server has failed, indicating to the network operators that they have to log-in with the special (local) username, not with the TACACS+ authenticated username/password.

Fortunately he was running TACACS+ which supplies its own prompts during the authentication phase (the solution would not work with RADIUS). If you change the local authentication prompts, you'll get the prompts from TACACS+ server if it's reachable from the router (the AAA authentication is performed via TACACS+ server) and the local prompts if the TACACS+ server has failed (the AAA authentication is performed via any other mechanism). Here's a sample configuration:

aaa new-model
aaa authentication login REMOTE group tacacs+ local
!
aaa authentication fail-message #
Local authentication failed. 
#
aaa authentication password-prompt "Enter local password:"
aaa authentication username-prompt "Enter local username:"
!
user a secret b
!
line vty 0 4
 login authentication REMOTE




see 11 comments

Change the username/password prompt with AAA

TACACS+ protocol introduced with the IOS AAA architecture had great provisions for customizing the whole login process (user-defined banners, prompts ...). Unfortunately, it never really took off and most AAA solutions deployed today rely on RADIUS servers that cannot control the login process itself (the RADIUS server can only check the username/password pair for validity).

To change the login prompts when using RADIUS servers, use the aaa authentication [banner|fail-message|password-prompt|username-prompt] text configuration command.
read more add comment

One-time passwords on Cisco routers

Cisco routers preconfigured for SDM have default username/password cisco/cisco. As many users forget to disable or change the default username after configuring their router with SDM, they could end up with an exposed router.

Cisco has patched this vulnerability in IOS release 12.4(11)T that includes the one-time password/secret option of the username command, allowing you to define a username/password combination that can be used only once.
read more see 5 comments

Configure local authentication with AAA

This should be a no-brainer for anyone preparing for the CCIE lab exam (I'll not elaborate why, but you could guess), but here it is for the benefits of everyone else: if you want to enable AAA on Cisco IOS but still retain local usernames (at least for the console access), this is how you do it:
  • Define local usernames with username xxx password yyy command (I would prefer the secret option if your IOS supports it).
  • Configure aaa new-model.
  • Configure a named AAA authentication list with the aaa authentication login MyList local.
  • Attach the named AAA authentication list to the console line with the login authentication MyList command.
If you want to use the local usernames only as a fallback mechanism in case the AAA servers fail or become unreachable, you could use the aaa authentication login MyList group [radius|tacacs+|name] local command.

Note: this article is part of You've asked for it series.
see 5 comments

Local usernames with no password

There are two ways you can configure local usernames without a password:
  • By using the username user command without the password option, you create a username that has a blank password (the operator has to press ENTER at the Password: prompt)
  • With the username user nopassword command, you create a user where the operator will not be prompted for the password at all.
Hopefully, you would use such usernames only with the autocommand option to give guest users a short overview of the router's operation (for example, display the interface status).

Note: this article is part of You've asked for it series.
add comment

Executing a command upon user login

Cisco IOS long had the autocommand option by which you could attach any command to a username and have it execute after successful login. For example, username x autocommand show ip interface brief command would configure the router to display the interface status after someone would log in as user x.

After the autocommand is executed, the user is logged out and the session is disconnected, unless you configure the username user nohangup option, which causes the session to remain active, giving the operator another login prompt.
see 9 comments

Enhanced password security for local usernames

Cisco IOS long had the ability to define local users that could be used to authenticate incoming telnet sessions or dial-up connections (using PAP or CHAP). Until IOS release 12.3, the passwords assigned to local usernames were encrypted using the weak (type 7) reversible encryption. With crack tools widely available on the Internet, there's obviously almost no protection offered by this encryption type.

With IOS release 12.3, Cisco introduced enhanced password security and the new username user secret password command which uses strong (type 5) encryption, making local user passwords secure. Of course, such usernames cannot be used in scenarios where you need access to cleartext password (for example, CHAP authentication).
add comment
Page 2 of 4
Sidebar