[c-nsp] Deploying RADIUS for user logins ?

[Justin Shore]

kevin gannon wrote:
> I am looking at deploying RADIUS to manage user logins to thousands of
> Cisco boxes. Currently access is via telnet and a mix of usernames/passwords.

Are you partial to RADIUS?  If not then I would highly recommend 
TACACS+.  RADIUS only encrypts the transmitted password whereas TACACS+ 
encrypts the entire payload (protocol control commands and everything 
else).  That's a big boost for security.  RADIUS also combines 
authentication and authorization which means you can't customize EXEC 
commands on a user basis.  TACACS+ gives you full AAA.  I would 
recommend TACACS+ and I use it myself.  If you want mass user auth such 
as what you'd get from a PPPoX install, dialup or even a large 802.1X 
environment then you should look at using RADIUS to fill those needs 
(and only those needs).  That said a lot of people use RADIUS for 
everything because that's what they had handy when they wanted to 
implement AAA.  It sounds like you have a clean environment, though. 
I'd look at TACACS+.

> Do not want to end up having to physically visit large numbers of sites if
> we end up locked out of the boxes. Also dont want to do it all by hand.

You can script it easily enough if you have RANCID already set up.  I 
deployed it with a simple bash shell script and clogin from RANCID. 
Assuming you're going to do TACACS+ (RADIUS would be similar) here's a 
working AAA config:

conf t
aaa new-model
!
! I don't use auth on my console.  You could use local auth if you
! want.  Using AAA may complicate matters if you don't use local
! auth as a backup.
aaa authentication login console none

! Note the user of "local" below.  This is important because it will
! give you the ability to use a local userid & password if your AAA
! server is unavailable due to DoS, failure or routing issue, thus
! saving your a trip to the remote site to console into the router,
! assuming your don't have a OOB solution already in place.
aaa authentication login netauth group tacacs+ local
aaa authorization exec default none
aaa accounting delay-start
aaa accounting exec netacc start-stop group tacacs+
aaa accounting commands 15 netacc stop-only group tacacs+
aaa accounting connection netacc start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
aaa session-id common
!
! IMPORTANT:  Create a local backup admin user for use when the AAA
! server is down or not reachable.  Lock this userid/password away
! in a safe place for a rainy day.  You should be able to remove all
! other local userids once AAA is confirmed to be working.
username LOCALADMINUSER privilege 15 secret 5 blahblahblah
!
! Source your TACACS packets for a secure loopback
ip tacacs source-interface Loopback0
!
! IP of your AAA server goes here
tacacs-server host aaa.bbb.ccc.ddd
!
! I've had fairly consistent issues pasting in the encrypted key.
! That's why I only deploy it with the unencrypted key now.
tacacs-server key 0 UNENCRYPTED-KEY
!
! Just in case it's enabled, disable it.
no tacacs-server directed-request
!
line vty 0 15
  accounting commands 15 netacc
  accounting exec netacc
  login authentication netauth
!
! Add any other lines you want to secure with AAA here.
!
! HTTP auth requires authorization keys to be passed so you have to
! configure your AAA server for that as well.
end
wr


Stick that in a file on your RANCID box.  Point clogin to the commands 
with the -x option and watch the output as it runs.  Run it on a small 
number of test devices first and then turn it loose on the network. 
Most of the commands above will be fairly uniform across all platforms. 
  You might want to run the line vty commands first on VTYs 0-4 and then 
0-15, just in case you have a device without the extended VTY support. 
You'll also need to change the tacacs source-interface argument for 
devices that don't have Lo0 (such as L2 switches with a management 
VLAN).  Those were the basic problems I run into each time I deploy AAA 
in a new network.

You should also come up with a method of generating TACACS keys.  You 
could use 1 key per POP or 1 key for the entire network.  Personally I 
use a unique key per device.  It's probably overkill but it works for 
me.  I use a unique strings taken from each device (process board ID for 
example), stick it in a text file, and then perform a md5sum on that 
file.  The resulting 32 character string of random characters makes for 
a nice key.  It's also reproducible in a pinch.  It's overkill but I've 
gotten in the habit of doing it that way.  Most people probably use 1 
key per POP.  There isn't any support for key-chains in Cisco's TACACS+ 
implementation yet so changing the key yearly (not a bad idea) would 
require some coordination.

The only other thing I'd say is that you need to harden the AAA server 
to only allow tcp/49 (or udp&tcp 1812/1813 for RADIUS) from trusted 
loopback subnets or individual devices.  I've seen a fair bit of 
scanning for AAA servers over the last few months.  Ideally the AAA 
server would have a private interface dedicated for those function or be 
behind a firewall.

Justin