Filter
Top Products
2-18
Configuration Guide for Cisco Secure ACS 4.2
OL-14390-02
Chapter 2 Deploy the Access Control Servers
Additional Topics
A small network with a small number of network devices may require only one or two individuals to
administer it. Local authentication on the device is usually sufficient. If you require more granular
control than what authentication can provide, some means of authorization is necessary. As discussed
earlier, controlling access by using privilege levels can be cumbersome. ACS reduces this problem.
In large enterprise networks, with many devices to administer, the use of ACS practically becomes a
necessity. Because administration of many devices requires a larger number of network administrators,
with varying levels of access, the use of local control is simply not a viable way to track network-device
configuration changes that are required when changing administrators or devices.
The use of network management tools, such as CiscoWorks, helps to ease this burden; but, maintaining
security is still an issue. Because ACS can comfortably handle up to 300,000 users, the number of
network administrators that ACS supports is rarely an issue. If a large remote-access population is using
RADIUS for AAA support, the corporate IT team should consider separate TACACS+ authentication by
using ACS for the administrative team. Separate TACACS+ authentication would isolate the general user
population from the administrative team and reduce the likelihood of inadvertent access to network
devices. If the use of TACACS+ is not a suitable solution, using TACACS+ for administrative (shell or
exec) logins, and RADIUS for remote network access, provides sufficient security for the network
devices.
Separation of Administrative and General Users
You should prevent the general network user from accessing network devices. Even though the general
user may not intend to gain unauthorized access, inadvertent access could accidentally disrupt network
access. AAA and ACS provide the means to separate the general user from the administrative user.
The easiest and recommended method to perform such separation is to use RADIUS for the general
remote-access user and TACACS+ for the administrative user. One issue is that an administrator may
also require remote network access, like the general user. If you use ACS, this issue poses no problem.
The administrator can have RADIUS and TACACS+ configurations in ACS. By using authorization,
RADIUS users can set PPP (or other network access protocols) as the permitted protocol. Under
TACACS+, only the administrator would be configured to have shell (exec) access.
For example, if the administrator is dialing in to the network as a general user, a AAA client would use
RADIUS as the authenticating and authorizing protocol, and the PPP protocol would be authorized. In
turn, if the same administrator remotely connects to a AAA client to make configuration changes, the
AAA client would use the TACACS+ protocol for authentication and authorization. Because this
administrator is configured on ACS with permission for shell under TACACS+, the administrator would
be authorized to log in to that device. This does require that the AAA client have two separate
configurations on ACS, one for RADIUS and one for TACACS+.
An example of a AAA client configuration under IOS that effectively separates PPP and shell logins is:
aaa new-model
tacacs-server host ip-address
tacacs-server key secret-key
radius-server host ip-address
radius-server key secret-key
aaa authentication ppp default group radius
aaa authentication login default group tacacs+ local
aaa authentication login console none
aaa authorization network default group radius
aaa authorization exec default group tacacs+ none
aaa authorization command 15 default group tacacs+ none
username user password password
line con 0
login authentication console