Testing the current Cisco IOS AAA configuration interactively, from the command line.
This command is useful, when debugging AAA configuration made on a given component that runs IOS, router or switch. No needless login routine needed.
Usually 2 separate terminal sessions are needed when configuring or debugging AAA, on whatever component. One terminal is needed for the debug output, and also to have a session to not shot yourself in the knee while configuring AAA, the 2-nd terminal session is needed to initiate a user AAA session.
You do not mess around with AAA configuration on routers, switches, linux or windows nodes. This is universally true, AAA configuration needs to be alweay dealt with care. Everyone made at least once an experience, with misconfigured AAA and its consequences.
Run IOS AAA tests using the currently running SSH or telnet session. Test if this command is available, in the current used firmware. If it is not, then the image does not have this test feature.
Testing in this netlab using following IOS version. This is already a pretty dated firmware, so chances are good Cisco has put this test aaa command into its firmware, shipping as default:
Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.2(4)S3, RELEASE SOFTWARE (fc1)
List available test aaa commmands:
accounting AAA accounting tests aes-encrypted Test AES Encrypted routine authentication AAA Client authentication test authorization AAA Client authorization test group AAA Server Group Keyword stop Stop non-blocking AAA Server Group Testing
TACACS+ authentication testing, username cisco and password the same. There are 3 options to choose from:
legacy Code path through legacy new-code Code path through new-code port Port send as part of request
This is the output using the legacy option:
Attempting authentication test to server-group tacacs+ using tacacs+ User was successfully authenticated.
This is the output using the new-code option, this option shows the reply-message.The reply-message reveals the name of the use AAA software used at the backend.
Sending password User successfully authenticated USER ATTRIBUTES username 0 'cisco' reply-message 0 ' Welcome to TACACS+NG Password:
Testing the port option:
port Port send as part of request
Not sure where port would be used. It is inclueded int the test aaa group IOS command, maybe you will have a use case for this. If yes then let me know, I'll update this entry then.
To make the AAA almost complete, IOS has the same option testing AAA using RADIUS or the Diameter protocol . Use the test aaa group ? command:
WORD AAA Server group name diameter Test list of all Diameter hosts radius Test list of all Radius hosts tacacs+ Test list of all Tacacs+ hosts
Ask yourself which AAA protocols are missing in this list. Ask youself why they eventually are missing. Not focusing on the implementation side from the vendor.
Cisco IOS-XR and NX-OS might have similar CLI commands for AAA configuration testing.
Configuration described here is one file only. This is netlab purpose only. The TACACS+ daemon has no connections to LDAP/AD/RADIUS etc. Backends are optional and can be added easy any time.
To keep this simple one file configuration modular and manageable over time. The tac_plus-ng.cfg configuration will be split up in following parts:
- devices
- groups
- users
Includes described in the docs - 4.2. Configuration directives. This way the configuration could be automated. Easier to manage small bits and pieces, not a hudge file.
Directory structure created in the tac_plus main directory /etc/tac_plus-ng/
. ├── devices ├── groups └── users
This is much like the what you would do using ansible too.
Configuration directory view:
. ├── group │ └── group.cfg ├── devices │ └── IPv4only.cfg ├── tac_plus-ng.cfg └── users └── 99-cisco.cfg
TACACS+
This netlab is using the TAC_PLUS-NG deamon project from Event-driven servers.
Version of TACACS+NG:
The configuration used in this example is from previous netlab 05 - Configuring TACACS+NG authentication for freeRtr.
Using previouos netlab configuration example create following:
Having configured EXOS authentication using the TACACS+ daemon successfully, in a previous blog entry, it should be a easy to add the authorization.
TACACS+ authentication
Once authentication is enabled on the EXOS router, configuration lines:
configure tacacs primary server 192.0.2.1 4949 client-ip 10.100.100.103 vr VR-Default
configure tacacs primary shared-secret 123-my_tacacs_key
configure tacacs fallback local
enable tacacs
...Ready. EXOS AAA authentication finished.
The verification part is explained in the above linked blog entry.
TACACS+ authorization
Authorization is easy configured once authentication works, this is true. But not, if lacking configuration experience on given component.
Configuration issue
Now using this configuration, it would seem logical to configure further like shown:
tacacs Configure TACACS+ Server tacacs-accounting Configure TACACS+ Accounting Server
Yea, even tacacs-accounting is shown as configuration option. So where is the authorization part? Using this method there is no way to configure TACACS+ authorization using the menu:
fallback Fallback authentication option when client IP is not in server's list of clients primary primary server priv-lvl Privilege level attribute of authorization request. secondary secondary server timeout TACACS+ server timeout
This is a dead end. When verifying the using the show session command, it says it is disabled.
CLI # Login Time User Type Auth Auth Location ================================================================================ 1 Sun Aug 6 14:34:12 2023 admin console local dis serial *4 Sun Aug 6 14:37:10 2023 cisco telnet TACACS+dis 10.100.100.10
So there is something very specific missing, after troubleshooting for some time, I left it this way being convinced this is for sure a appliance bug, and did not invest any time in searching for a solution.
TACACS+ configuration using ExtremeXOS (EXOS). This is about configuring authentication using the TACACS+ protocol. Authorization and Accounting are easy to set up once Authentication is working, but are not part of this netlab.
This is a configuration from scratch. EXOS usage for the first time, no experience at all. TACACS+ EXOS authentication.
The official EXOS appliance is available here, or can be simply installed using the GNS3 marketplace or the GNS-gui import appliance function.
IP addressing
The IP addressing used in this netlab. 3 appliances:
| Node | Function | IP address |
|---|---|---|
| R103 | EXOS router | 10.100.100.103/24 |
| AAA-49 | TACACS+ server | 192.0.2.1 |
| node-10 | TACACS+ client | 10.100.100.10 |
Connections in the netlab from node-10 to R103 using telnet and SSH protocol.
TACACS+
This netlab is using the TAC_PLUS-NG server project from Event-driven servers.
Version of TACACS+NG:
TACACS server IP settings:
| Setting | Value |
|---|---|
| IP | 192.0.2.1 |
| TCP port | 4949 |
| TACACS+ key | 123-my_tacacs_key |
Preconfigured tac_plus-ng.cfg settings for user authentication:
| Method | Option | User | Password |
|---|---|---|---|
| ASCII | login | cisco | cisco |
| PAP | pap | cisco | auth-pap |
| CHAP | chap | cisco | auth-chap |
There is no option to use PAP authentication in EXOS in TACACS+. PAP authentication works using RADIUS only. CHAP authentication for RADIUS is not implemented yet in EXOS.
The basic TACACS+NG configuration used in this netlab, has been set up in
This is a overview of the most popular command line crypto hash generation tools available on the linux platform, especially gentoo. There are probably much more tools for that purpose, but these are used here. It was hard to find a tool that generates blowfish hashes out of the box. There are hardly tools for that, one of the most popular tools is shipped with the apache2 server. If you find additonal toold especially for bcrypt, write me an email, I'll update the list.
These tools work Out of the box.
htpasswd
The one and only linux tool that generates Blowfish hash out of the box after the installation. httppasswd generates $2y prefixed Blowfish hashes. The prefix is not interesting in sense of encryption. Every implementation works the same, if done correctly. The prefix is to distinguish between bugged and fixed hashes among already created. Apache specific and related to the used implementation. If you sight a different prefix, it is related to its implementation on a specific platform or version of the software used.
Usage: htpasswd [-cimBdpsDv] [-C cost] passwordfile username htpasswd -b[cmBdpsDv] [-C cost] passwordfile username password htpasswd -n[imBdps] [-C cost] username htpasswd -nb[mBdps] [-C cost] username password -c Create a new file. -n Don't update file; display results on stdout. -b Use the password from the command line rather than prompting for it. -i Read password from stdin without verification (for script usage). -m Force MD5 encryption of the password (default). -B Force bcrypt encryption of the password (very secure). -C Set the computing time used for the bcrypt algorithm (higher is more secure but slower, default: 5, valid: 4 to 17). -d Force CRYPT encryption of the password (8 chars max, insecure). -s Force SHA encryption of the password (insecure). -p Do not encrypt the password (plaintext, insecure). -D Delete the specified user. -v Verify password for the specified user. On other systems than Windows and NetWare the '-p' flag will probably not work. The SHA algorithm does not use a salt and is less secure than the MD5 algorithm.
13 rounds is now the default set in the templates of the linux distribution used here (gentoo). Here a example how to generate a hash, with -cost of 15, sometimes referred as rounds:
user@host % htpasswd -bnBC 15 "" password | tr -d ':\n'
$2y$15$38yZWnqA5TklswRQfMzFUeyq/S4jc2ZEpB3.8Kq.M0HBL1zERFEZW%
Testing authentication with 15 rounds. Test it, there is no silver bullet for every hardware platform (CPU). Using rounds is a thing of give and take, the question here is, how long can the user wait for a successful authentication. The authentication delay using 15 rounds is already long. This is the reason for using cost 10 in the netlabs. This example has already a very noticeable delay during authentication. -cost 15 is expensive. Try it out creating a local test user, and replacing the standard SHA-512 to Blowfish hash generated with that cost. Then authenticate using SSH on localhost for a test.
mkpasswd
mkpasswd has the libcrypt standard hashes included:
Available methods: sha512crypt SHA-512 sha256crypt SHA-256 md5crypt MD5 descrypt standard 56 bit DES-based crypt(3)
Bcrypt is missing from that list.
SHA-512
3DES
DES or 3DES, the is the question, not sure which one is created, I hope 3DES:
OpenSSL
OpenSSL has the same amount of amount of crypto hashes like mkpasswd, and includes some extra options either for the architecture or the software used:
Usage: passwd [options] General options: -help Display this summary Input options: -in infile Read passwords from file -noverify Never verify when reading password from terminal -stdin Read passwords from stdin Output options: -quiet No warnings -table Format output as table -reverse Switch table columns Cryptographic options: -salt val Use provided salt -6 SHA512-based password algorithm -5 SHA256-based password algorithm -apr1 MD5-based password algorithm, Apache variant -1 MD5-based password algorithm -aixmd5 AIX MD5-based password algorithm Random state options: -rand val Load the given file(s) into the random number generator -writerand outfile Write random data to the specified file Provider options: -provider-path val Provider load path (must be before 'provider' argument if required) -provider val Provider to load (can be specified multiple times) -propquery val Property query used when fetching algorithms Parameters: password Password text to digest (optional)
Configuring and using freeRtr as an AAA appliance. While there are many commercial AAA appliances that eat huge amounts of CPU and RAM and storage if ran in GNS3. There is a lack of easy to use AAA appliances, and these that are offered in the GNS3 store, are not handy. Here is an approach configuring a AAA appliance without getting into to much into details on applications and operating systems and software dependencies. Actually this tiny AAA appliance is available in the GNS3 store, the only thing that is lacking is a easy setup and documentation. No hard feelings on lacking documentation, if everything else is working perfectly behind the lines.
It make no difference if AAA is ran using a big commercial appliance or using freeRtr. The protocols and the debugging process are the same. Only the configuration is different. Using the explained approach the AAA appliance will be ready in 5 minutes, literally. No needless waiting for the GUI to open up and no web interfaces needed, no certification warnings, no smart browsers preventing you from connecting to the control plane. Everything is done using the command line interface CLI.
Here in particular as a RADIUS daemon. Setup is for authentication and authorisation . There are a few ways to configure authorisation. This is the 2-nd easy way to configure authorisation by assigning a NAS default preset, the priv-lvl. Assigning priv-lvl works with following NAS or network operating systems:
- IOS (Cisco) Vendor ID = 9
- RGOS (Ruijie networks) Vendor ID = 4881
- EXOS (Extreme networks) Vendor ID = 6307
But using RADIUS Vendor Specific Attributes (VSA)'s this explained approach will work only for Cisco IOS. Swapping the Vendor ID and the Vendor type prefix should get you going to migrate this to other vendors. Honestly I did not try it out, yet.
Terms
These are the technical terms used here. The AAA RADIUS will be referred as AAA daemon:
- AAA daemon - AAA appliance
- NAC - Network Access Client
- NAS - Network Access Server
AAA is either RADIUS or TACACS+. Here AAA stands for RADIUS.
Configuration
Configuration of the AAA appliance, specifically how to configure Authentication and Authorisation, and how both parts of the freeRtr configuration work together.
A basic setup. One broadcast domain, network topology with following IP addressing:
| Node | Function | Term | IP address |
|---|---|---|---|
| node-10 | Telnet client | NAC | 10.100.100.10 |
| AAA-49 | RADIUS daemon | daemon | 10.100.100.49/24 |
| R101 | IOS router | NAS | 10.100.100.101/24 |
Using the previous blog entry Using freeRtr as an GNS3 AAA appliance freeRtr configuration, this netlab explains the configuration of VyOS and configuring AAA using the RADIUS protocol VyOS is a free available firewall appliance. VyOS uses the RADIUS VSA's of Cisco IOS. In the login VyOS documentation there is a remark pointing out exactly this, here is a citation in case this remark will be removed or rewritten:
If you want to have admin users to authenticate via RADIUS it is essential to sent the
Cisco-AV-Pair shell:priv-lvl=15attribute. Without the attribute you will only get regular, non privilegued, system users.
Using this particular piece of information the authentication and authorization configuration process will be easy to handle. Either the authenticating user gets the privilege level at the authentication and will be authorized to configure, or not.
VyOS recently implemented also the AAA TACACS+ protocol, this document focuses only using AAA using RADIUS. One minor note before moving on to netlab. You can use only one protocol for AAA at time on a NAS, either RADIUS is used OR TACACS+ is used. It is not possible to use both at same time. There might be some few exceptions for networking gear operating system but until now I have not spot or discovered any.
Terms
Using term server in this context is problematic and leads to misunderstanding. These are the technical terms used here. The AAA RADIUS will be referred as AAA daemon:
- AAA daemon - AAA appliance
- NAC - Network Access Client
- NAS - Network Access Server
Configuration
Most basic setup. One broadcast domain, network topology with following IP addressing:
| Node | Function | Term | IP address |
|---|---|---|---|
| node-10 | Telnet client | NAC | 10.100.100.10 |
| AAA-49 | RADIUS daemon | daemon | 10.100.100.49/24 |
| R106 | VyOS firewall | NAS | 10.100.100.106/24 |