Re: Best practices for implementing Cisco ACS?

["Robert MacDonald" <Robert.MacDonald () Haworth com>]

Adrian,
 
Depends on what your looking to accomplish on what devices. With the
newer Cisco devices, you can pretty much control the device completely.
The older devices(1900, 2800, etc.) don't have as much support, but at
least you have some fucntionality (basic AAA, auth, reporting, etc.)
 
Some of the newer IOS's allow you to drop whole chunks of commands
to a different enable level so that you don't have to specify each and every
command with parameters. This works so well, that when an admin doesn't
have access to higher enabled commands, they don't even show in the
show run/config outputs. This is great for hiding local user and password
definitions.
 
Then you have the IOS, CAT-OS, VPN3k/5k and PIX differences. On
the current VPN3k(at least the ones we have, 3030, 3015 & 3005), you
need to add the administrative user on the concentrator in addition to the
CS user database/external authentication. If they don't match, you don't
get in - annoying, usually when you change the password on one and forget
the other.
 
It's hard to give examples here, since the details are a combination of
commands on the device and CS-ACS user/group setup specifics (in our
configurations.) You can in many cases, do all of the dirty work with
commands on the device, but this becomes administratively a PITA from
the POV of having to visit(telnet/ssh) to each device and make changes. A
good combination of basic commands on the device and then the rest
defined from with the CS-ACS browser based system and delivered or
checked from the CS-ACS server(s) has been far easier to work with.
 
For example - IOS devices: see attached. This is one of my earlier test
layouts.
 
We use a series of ACS systems to natively & via proxy perform authentication
and redundancy. We can take systems offline during the work day for
patching/upgrading without effecting the user community.
 
I did a ton of testing ( & still have a ton more) to see what my limits were to
many of the commands. I have systems that are locked down to even the
console port. I do have local backup for all administrator that gives basic
fucntionality if we had a serious outage. This is via a mix of local users with
varying levels of permissions. TACACS+ is used where-ever possible. It
keeps the whole telnet transmission encrypted over the wire. RADIUS does
not do this AFAIR. We do a fair amount of RADIUS authentication to the
man diverse user/password databases(e.g. Netware, NT Domain/AD, etc.)
 
It may/maynot be obvious, but you should use SSH or the like when
communicating to devices/systems that require a more secure transmission
method. Most notibly those via public networks.
 
BTW, the 'Fine Manual' is OK. It gives all of the specifics to get started. It's
just not a clear as some would like. The examples could be more verbose
on the what your limits are when it comes to what it can/cannot do. In the end,
following the 'fine manual' examples and testing produces far more information
and usually it sticks in your head much longer.
 
There. A whole lot of words and I probably didn't say what you wanted.
 
Best of Luck!
Robert

-----Original Message----- 
From: Adrian DuPre [mailto:adrian.dupre () zimmer com] 
Sent: Wed 10/20/2004 3:28 PM 
To: security-basics () securityfocus com 



Has anyone successfully (or not-so-successfully) implemented Cisco ACS
for granular control of router access?  We're looking to define access
levels for local/remote IT staff based on job function.  What
tips/tricks/resources/best practices did you find?  (Aside from the
"Fine Manual")

Thanks in advance,
-Adrian

Attachment: AAA-IOS.txt
Description: AAA-IOS.txt