Earlier version of
ACS was based on membership of user groups; user group defines access
restriction and permission for the users who are members of the group. Since
authorization was tied up with user groups all members will have access
policies and restrictions all the time. This type authorization suitable for
simple polices in which identity is only condition. If we want user should have
different permission on different condition (like location, date and time). The
ACS 5.1 rule based policy model is based on rule of the form:
IF
then
In ACS5.1 we define conditions
and results as global, shared objects. You define them once and then
reference them when you create rules. ACS 5.1 uses the term policy elements for these shared
objects, and they are the building blocks for creating rules.
Table
below shows how the various policy elements define all the information that the
old group contained.
Table 3-1 Information in Policy Elements
|
Information
in ACS 4.x Group
|
Information
in ACS 5.1 Policy Element
|
|
|
•
AD group membership and attributes
•
LDAP group membership and attributes
•
ACS internal identity groups and attributes
|
|
|
•
Time and date conditions
|
|
|
|
A policy is a set of rules that ACS 5.1 uses to evaluate an
access request and return a decision. For example, the set of rules in an:
- Authorization
policy returns the authorization decision for a given access request.
- Identity
policy decide how to authenticate and acquire identity attributes for a
given access request.
ACS 5.1 organizes the sequence of independent policies (a
policy workflow) into an access service, which it uses to process an access
request. We can create multiple access services to process different kinds of
access request, for example device administration or network access.
Access service contain the identity and authorization
policies for handling incoming service request, by default ACS provides one
access service (Default Network Access) for handling Radius network access request and another (Default Devices Admin)
TACACS device admin request. Typically each access service will have two
policies step an identity policy to select the identity store use to
authenticate the user and authorization policy to granting permission.
We can define simple polices which applies single result to
all request without any conditions and rule-based polices which are complex
polices that test various conditions.
Key Benefits
- Powerful
and flexible policy model
- Authorization
is not tied to single group membership.
- Different
authorization under different condition (e.g. Time, location etc).
- Network
devices groups can be structured hierarchically to simplify policy
administration.
- Enhanced
management and troubleshooting:
- Centralized
collection and reporting for activity and health information
- Incremental
replication
- Installation
and management interface for software updates.
Within the context of two major AAA protocol – RADIUS &
TACACS+ ACS provides the following basic area of functionality.
Under
the framework of the RADIUS protocol, ACS controls the wired and wireless
access by users and host machines to the network and manages the accounting of
the network resources used. ACS supports
- multiple
RADIUS-based authentication methods that include PAP, CHAP, MSCHAPv1,
MSCHAPv2, and many members of the EAP family of protocols, such as
EAP-MD5, LEAP, PEAP, EAP-FAST, and EAP-TLS. In association with PEAP or
EAP-FAST, ACS also supports EAP-MSCHAPv2 and EAP-GTC.
- Under the
framework of the TACACS+ protocol, ACS facilitates the administrative
management of Cisco & non-Cisco network devices such as switches,
wireless access points, router and gateway, as well as of services and
entities such as dialup, VPN and firewall.
- Cisco ACS
5.1 is policy management system for supporting comprehensive,
identity-based access control and security. It support for 802.1x and
support for NAC RADIUS. And also supports device administration through
TACACS+.
- It is
available in two form factors
- Linux
Appliance: One rack-unit (1Ru) security-hardened, Linux-based appliance
- Virtual
Appliance: Software application and operation system image for installing
on VMware ESX 3.5.
- All primary and secondary ACS
servers can process AAA requests. The primary ACS server is also the
default log collector for the Monitoring and Report Viewer, you can
configure any ACS server to be the log collector.
