Basic AAA Configuration on IOS
By stretch | Monday, September 27, 2010 at 1:18 a.m. UTC
Cisco IOS supports minimal password authentication at the console/VTY line and privilege exec boundaries, through the use of static, locally defined passwords. For example:
enable secret 5 $1$J19J$Q2jB2AM64H0U001nHStLW1 ! no aaa new-model ! line con 0 password 7 0532091A0C595D1D3B00351D190900 login line vty 0 15 password 7 152B0419293F38300A36172D010212 login
While easily implemented, this approach is far from ideal for a production network. For much more robust and easily managed authentication schemes, IOS supports the Authentication, Authorization, and Accounting (AAA) model, using the RADIUS or TACACS+ protocols to centralize these functions on dedicated AAA servers.
This article will look at deploying a typical IOS router AAA configuration which must meet two requirements:
- All users logging into the router must authenticate with a username and password to one of two redundant TACACS+ servers.
- Users must be able to log in using a backup local user account stored on the router only if neither TACACS+ server is reachable.
This article assumes that all back-end AAA server configuration has been completed and is working.
Configuring AAA on IOS for general administrative access entails four basic steps:
- Enable the "new model" of AAA.
- Configure the server(s) to be used for AAA (e.g. TACACS+ servers).
- Define authentication and authorization method lists.
- Enforce AAA authentication on the relevant lines (e.g. console and VTY lines).
Step 0: Create a backup user account
Although not technically a part of AAA configuration, we want to ensure a backup user account exists in the event the AAA servers become unreachable, so that we can still log in to the router.
Router(config)# username BackupAdmin privilege 15 secret MySecretPassword
Step 1: Enabling AAA
The new AAA model of authentication is enabled with a single command, which unlocks all other aaa
commands on the command line interface. Note that this command will break non-AAA line and enable passwords.
Router(config)# aaa new-model
Step 2: Configuring the TACACS+ servers
Next we need to configure the addresses of the AAA servers we want to use. This example shows the configuration of TACACS+ servers, but the concept applies to RADIUS servers as well.
There are two approaches to configuring TACACS+ servers. In the first, servers are specified in global configuration mode using the command tacacs-server
to specify an IP address and shared secret key for each server:
Router(config)# tacacs-server host 192.168.1.3 key MySecretKey1 Router(config)# tacacs-server host 192.168.2.3 key MySecretKey2
This approach is sufficient for many deployments, but is problematic if you want to reference only a subset of the defined servers for a certain AAA function. For example, suppose you want to use one TACACS+ server for control plane authentication on the router itself, and the second server for authenticating PPP connections. In this case, you would assign the servers to named AAA server groups:
Router(config)# aaa group server tacacs+ LoginAuth Router(config-sg-tacacs+)# server 192.168.1.3 Router(config)# aaa group server tacacs+ PPPAuth Router(config-sg-tacacs+)# server 192.168.2.3
Note that if using server groups, the servers are still defined with tacacs-server
in global configuration mode. (Servers can optionally be defined only within a group by using the command private-server
under group configuration.)
Step 3: Define the AAA method lists
Next we need to define a method list which instructs the router to use AAA authentication for terminal logins.
Router(config)# aaa authentication login default group tacacs+ local
This is a rather lengthy command, so let's work through it one bit at a time. aaa authentication login
specifies that the following parameters are to be used for user login authentication. The word default
is used in lieu of a custom name for the list (you can only define one default list for each AAA function).
The rest of the line specifies authentication methods. group tacacs+
means "use all configured TACACS+ servers." If you defined a named server group in step two, use the name of that group in place of the word tacacs+
here. local
defines a secondary authentication mechanism; it instructs the router to fail over to locally defined user accounts if none of the authentication servers in the first method are reachable. (Note that this only happens if the servers are unreachable; a response from a server denying authentication will not trigger a fail-over to local authentication.)
The above method list handles only the authentication aspect of AAA. By itself, this list only allows us to authenticate as a user with privilege level 1 (user exec mode). To communicate a heightened privilege level (e.g. privilege level 15, or "enable mode") from the TACACS+ server, we also need to define an authorization method list for IOS shell creation.
Router(config)# aaa authorization exec default group tacacs+ local
You can see that the authorization method list follows the same logic as our first list, the only difference being that this list is used for exec (shell) authorization rather than login authentication.
Step 4: Enforcing AAA authentication on terminal lines
This last step has actually been done for us already by enabling AAA in step one. However, if we were to create a custom authentication method list for these lines, we would use the command below, substituting the method list name for the word default
.
Router(config)# line console 0 Router(config-line)# login authentication default Router(config)# line vty 0 15 Router(config-line)# login authentication default
These commands will not appear in the running configuration if the default method list is specified.
At this point, we should have a fully functional AAA configuration for console authentication and authorization.
stretch@Sandbox ~ $ telnet 192.168.1.132 Trying 192.168.1.132... Connected to 192.168.1.132. Escape character is '^]'. Username: jstretch Password: Router#
Notice that upon logging in I was immediately placed into privileged exec mode without having to use the command enable
. This is our authorization method list at work. And remember, if the TACACS+ servers become unreachable, we can log into the router using the local user account we created in step zero.
The completed AAA configuration is included below.
aaa new-model ! aaa authentication login default group tacacs+ local aaa authorization exec default group tacacs+ local ! username BackupAdmin privilege 15 secret 5 $1$qLGb$VQ6BdqCEpzGZqPeC779Uh1 ! tacacs-server host 192.168.1.3 key 7 062B1612494D1B1C113C17125D tacacs-server host 192.168.2.3 key 7 143A0B380907382E3003362C70
UPDATE: I've added a packet capture of the TACACS+ authentication and authorization requests made by the router during a user login.
Posted in Security
Comments
September 27, 2010 at 1:32 a.m. UTC
I should point out that rather than using a tacacs authorization line, you could simply have an enable "user" in your tacacs_plus.conf file called $enab15$, which would dictate the routers enable password.
You'd use this in your IOS config:
aaa authentication enable default group tacacs+ local
Check out our good friend @brandoncarroll's Cisco Access Control Security: AAA Administration Services book for lots more information on AAA.
September 27, 2010 at 1:42 a.m. UTC
What's the advantage of using enable authentication? Seems like you would still have to type "enable" to reach privilege exec mode. Is it just a way of getting around a limitation in tac_plus?
September 27, 2010 at 1:52 a.m. UTC
You talk about tacacs+, but what about those that already have radius setup instead of tacacs+
September 27, 2010 at 2:03 a.m. UTC
@Calvin: I guess you'll just have to read the configuration guide. :) Although like I said, the AAA configurations for TACACS+ and RADIUS are very similar.
September 27, 2010 at 3:55 a.m. UTC
@stretch Yes, you'd need to type the enable command. I suppose there's no real advantage of doing that, besides the ability to have multiple enable levels. I guess it's just an option for having more granular authentication.
Or, perhaps a scenario where you have many people who can log into your routers, but only a select few who can configure them? Of course that could be done with in your tac_plus configuration, but this way might be a bit easier to configure and manage.
Obviously not saying my suggestion is the way to go, I just wanted to mention the option.
@Calvin It's as simple as:
radius-server host x.x.x.x keyand changing the aaa line to:
aaa authentication login default group radius local
Hope that helps.
September 27, 2010 at 4:44 a.m. UTC
I figured I'd also give an example of a tac_plus.conf file, for those who may want to go that route.
On a FreeBSD system, simply use:
cd /usr/ports/net/tac_plus4 && make install
Once installed, configure your /usr/local/etc/tac_plus.conf file:
# /usr/local/etc/tac_plus.conf # Your TACACS+ key here. You need to specify this in your IOS config too. key="7e@#fsdf*6Sf3a!" # Set TACACS+ log file location accounting file = /var/log/tacacs.log # Create a user, make them a member of "netadmins" user=tacacsuser { name = "TACACS User" login = des "a8Dpo4M5FR30s" member = netadmins } # Set IOS enable password user=$enab15$ { login = des "5Ro7GV4eq2Arc" } # Create the "netadmins" group, with default permit command authorization group=netadmins { default service = permit }
Add tac_plus to your /etc/rc.conf:
echo 'tac_plus_enable = "YES"' >> /etc/rc.conf
Then start tac_plus:
/usr/local/etc/rc.d/tac_plus start
Enjoy!
September 27, 2010 at 7:24 a.m. UTC
YouMustBeBored :-)
September 27, 2010 at 9:11 a.m. UTC
For those with a sec policy that requires the secondary authentication of the enable password having the $enab levels centralised on the tacacs server makes it easier to manage/expire/update. Still need those onboard ones for fallback
September 27, 2010 at 10:45 a.m. UTC
Just wanted to add that while the TACACS+ protocol is secure the Radius isn't. Therefore it is very easy to sniff the payload of the Radius communication and grab whatever is in there.
However Radius is often the de facto protocol if the authentication/authorisation is against Active Directory through the Microsoft IAS.
September 27, 2010 at 11:57 a.m. UTC
Thanks for another great article. Two points:
- I avoided the $enab15$ user in our config as it is a known username. We adopted the same approach that Stretch advocates and it works well.
- IIRC we did have some issues whereby using two tacacs servers resulted in our being locked out on network failure. The device tried them in turn ad infinitum. Has anyone else experienced this?
- ASAs and WLCs work a little differently. I wrote this up a couple of years ago: http://users.ox.ac.uk/~guym/. I now opt for tacacs first, then local but other than that our config hasn't changed much and still works with later ASA images.
September 27, 2010 at 12:59 p.m. UTC
Hi,
are there any free tacacs servers?
I used Cisco ACS and it works well but it is to expensive.
September 28, 2010 at 8:30 a.m. UTC
Some comments. It's a bit confusing to use default method. The better practice is using named methods for defined purposes. This makes a configuration to be easy to understand.
For me advantage of tacacs is accounting ability. It's not covered in the article. You can know not only who is managing equipment, but also what is done on it.
aaa accounting commands 15 VTY start-stop group tacacs+
September 28, 2010 at 9:42 a.m. UTC
Nice, I'm working through CCNA Security.
Thanks for the blog.
September 28, 2010 at 11:59 a.m. UTC
Bits of experience from environment I work in:
You can type or paste aaa configuration (source-interface, tacacs-server host(s), aaa commands) first - except for "tacacs-server key ". Leave this as last one. This way you can add whole aaa command set without fear of being stopped as unathorised in the middle due to AAA already taking place. It won't let you finish configuration unless you re-log with valid tacacs username and password. There is no communication with server if you do not put key in. This applies mostly to templates you paste configs from and methods you or your customer wants to use.
If for some reason tacacs server is running on different port put basic command first "tacacs-server host 192.168.1.1" and after finishing configuration change it to "tacacs-server host 192.168.1.1 port 4949" else you get error message not allowing you to configure port in first step.
Also it's good to have some sort of backdoor while configuring it, because with misconfigured aaa you can easily lock out of your router. This is no problem when router is sitting in front of you or you have tech support on site, but sometimes you're working remotely without somebody being physically present there. Find some way to squeeze "no aaa new-model" in and start again, eg. via snmp or opening second session with config mode. Worst case put "reload in 10" before you start fiddling with aaa.
September 28, 2010 at 12:03 p.m. UTC
Free TACACS server here
October 5, 2010 at 7:00 a.m. UTC
How to make the router not to ask for username at terminal lines ?
October 21, 2010 at 3:59 p.m. UTC
Hi there,
If you use the aaa authentication enable list in conjunction with RADIUS and cisco catalyst switches, i find that the failover to the local account will not work. Even if the switch is isolated from the network.
Using just the login list like you have here for tacacs+ works equally well with radius.
cheers,
nikonau
February 17, 2014 at 11:52 a.m. UTC
Hi Team,
I have two Cisco ACS .i want to configure primary and secondary on router.
Kindly share the configuartion.
Cureent configuration i have configur
tacas server 1.1.1.1 key * tacacs server 2.2.2.2 key
but that one is not working as failover.if one down i we are not able to login via secondary..
Share configuration both on router and ACS gui.
Tusahr Naik tushar14029@ gmail.com
March 20, 2014 at 2:43 p.m. UTC
"The word default is used in lieu of a custom name for the list" This is true but I have seen another explanation of the use of default - as in this is the default list, which may also be true, but misses and important fact and that is, according to Cisco "using the list default in the aaa authentication login command, login authentication is automatically applied for all login connections (such as tty, vty, ! console and aux)."
I take from this that if I name my list "default" then then "aaa authentication command " applies to all places where login is possible.
Just to complicate things I note that with just AAA New-Model, a local user, but no AAA authentication login ..... statement, login still works.
May 29, 2014 at 7:21 a.m. UTC
All of this looks good, only I would add the testing capability to the overall methodology to allow for immediate feedback for the user without needing to test by using another login.
"test aaa group tacacs+ username password legacy"
August 10, 2014 at 5:54 a.m. UTC
Is the AAA configuration for cisco MDS 9xxx series differs from the default aaa config? I have pretty much applied an identical script as shown above, but it does not work, any ideas?
September 3, 2015 at 2:54 p.m. UTC
anyway to let both the local and tacas work together. which mean that while the tacas is reachable, we still able to login use local user/password?
September 29, 2016 at 2:29 p.m. UTC
Congratulations Jeremy !
Your post is really good.
October 18, 2016 at 5:29 p.m. UTC
I learn so much from your blogs and discussions boards. Your explanation are well easy to comprehend. This site has contributed greatly to my success.
Thank you Jeremy