-
User Guide for the Cisco Secure Access Control System 5.0
-
Table of Contents
-
Preface
-
Introducing ACS 5.0
-
Migrating from ACS 4.x to ACS 5.0
-
ACS 5.0 Policy Model
-
Common Scenarios Using ACS
-
Understanding My Workspace
-
Managing Network Resources
-
Managing User and Identity Stores
-
Managing Policy Elements
-
Managing Access Policies
-
Monitoring and Reporting
-
Managing Reports in the Monitoring & Report Viewer
-
Monitoring & Report Viewer Troubleshooting
-
Monitoring & Report Viewer System Operations
-
Managing System Administrators
-
Configuring System Operations
-
Managing System Administration Configurations
-
Understanding Logging
-
Using the Web Interface
-
AAA Protocols
-
Authentication in ACS 5.0
-
Index
-
Feedback
Table Of Contents
Migrating From ACS 4.x to ACS 5.0
Features Not Available in ACS 5.0
Migrating from ACS 4.x to ACS 5.0
Functionality Mapping from ACS 4.x to ACS 5.0
Downloading ACS 4.x to 5.0 Migration Files
Migrating From ACS 4.x to ACS 5.0
This section contains the following topics:
•
Features Not Available in ACS 5.0
•
•
•
New Functionality in ACS
ACS 5.0 provides major new architecture and functionality, including:
•
•
•
•
•
•
•
Related Topics
•
•
•
•
Features Not Available in ACS 5.0
The following features, which were available in ACS 4.2, are not available in ACS 5.0:
•
•
•
•
•
•
•
•
•
•
•
See the following tables for additional information about features available in ACS 4.2 and ACS 5.0:
•
•
•
•
Related Topics
•
•
Migrating from ACS 4.x to ACS 5.0
ACS 5.0 introduces a new policy model that differs from that of ACS 4.x. ACS 4.x stores policy and authentication information, such as TACACS+ command sets, in the user and user group records. In ACS 5.0, policy and authentication information are independent shared components that you use as building blocks when you configure policies.
The most efficient way to make optimal use of the new policy model is to rebuild policies by using the building blocks, or policy elements, of the new policy model. This method entails creating appropriate identity groups, network device groups (NDGs), conditions, authorization profiles, and rules.
ACS 5.0 provides a migration utility to migrate data from an ACS 4.x Windows machine to an ACS 5.0 Linux machine. The migration process for ACS 5.0 requires, in some cases, administrative support to consolidate and manually resolve data before you import the data to ACS 5.0. This process is different from the upgrade process from versions of ACS 3.x to ACS 4.x, where the ACS 4.x system works the same way as ACS 3.x, and no administrative support is required.
Use the migration utility to migrate these ACS 4.x data entities:
•
•
•
•
•
•
•
•
•
•
•
•
•
The migration utility processes data in three phases:
1.
2.
3.
You can run the analysis and export phases independently, several times, to ensure that the data is appropriate for the import phase. You run the import phase after your data passes the analysis and export phases.
You must deploy a separate ACS 4.x server with the current configuration for the migration in addition to your production ACS 4.x server and an ACS 5.0 appliance. In this way, you can continue running your ACS 4.x production server while you migrate data to ACS 5.0.
For information about using the migration utility, see ACS 5.0 Migration Guide.
After migrating your data, you can reconstruct your policies with the migrated objects. See Functionality Mapping from ACS 4.x to ACS 5.0 for more information.
Related Topics
•
Functionality Mapping from ACS 4.x to ACS 5.0
In ACS 5.0, you define authorizations, shell profiles, attributes, and other policy elements as independent, reusable objects, and not as part of the user or group definition.
Table 2-5 describes where you configure identities, network resources, and policy elements in ACS 5.0. Use this table to view and modify your migrated data identities. See Chapter 3, "ACS 5.0 Policy Model" for an overview of the ACS 5.0 policy model.
Table 2-5 Functionality Mapping from ACS 4.x to ACS 5.0
Network device groups
Network Configuration page
Network Resources > Network Device Groups
See Creating, Duplicating, and Editing Network Device Groups, page 6-2.
You can use NDGs as conditions in policy rules.
(ACS 5.0 does not support NDG shared password. After migration, member devices contain the NDG shared password information.)
Network devices and AAA clients
Network Configuration page
Network Resources > Network Devices and AAA Clients
—
User groups
Group Setup page
Users and Identity Stores > Identity Groups
You can use identity groups as conditions in policy rules.
Internal users
User Setup page
Users and Identity Stores > Internal Identity Stores > Users
ACS 5.0 authenticates internal users against the internal identity store only. Migrated users that used an external database for authentication have a default authentication password that they must change on first access.
Internal hosts
Network Access Profiles > Authentication
Users and Identity Stores > Internal Identity Stores > Hosts
You can use the internal hosts in identity policies for Host Lookup.
Identity attributes (user-defined fields)
Interface Configuration > User Data Configuration
System Administration > Dictionaries > Identity > User
Defined identity attribute fields appear in the User Properties page; you can use them as conditions in access service policies.
Command sets (command authorization sets)
One of the following:
•
•
•
Policy Elements > Authorization and Permissions > Device Administration > Command Set
See Creating, Duplicating, and Editing Command Sets for Device Administration, page 8-16.
You can add command sets as results in authorization policy rules in a device administration access service.
Shell exec parameters
User Setup page
System Administration > Dictionaries > Identity > User
Defined identity attribute fields appear in the User Properties page; you can use them as conditions in access service policies.
Shell profiles (shell exec parameters or shell command authorization sets)
Group Setup page
Policy Elements > Authorization and Permissions > Device Administration > Shell Profile
See Creating, Duplicating, and Editing a Shell Profile for Device Administration, page 8-12.
You can add shell profiles as results in authorization policy rules in a device administration access service.
Date and time condition (Time of Day Access)1
Group Setup page
Policy Elements > Session Conditions > Date and Time
See Creating, Duplicating, and Editing a Date and Time Condition, page 8-2.
You can add date and time conditions to a policy rule in the Service Selection policy or in an authorization policy in an access service.
RADIUS Attributes1
One of the following:
•
•
•
Policy Elements > Authorization and Permissions > Network Access > Authorization Profile > Common Tasks tab
or
Policy Elements > Authorization and Permissions > Network Access > Authorization Profile > RADIUS Attributes tab
See Creating, Duplicating, and Editing Authorization Profiles for Network Access, page 8-6.
You configure RADIUS attributes as part of a network access authorization profile. You can add authorization profiles as results in an authorization policy in a network access service.
Downloadable ACLs
Shared Profile Components
Policy Elements > Authorization and Permissions > Named Permission Objects > Downloadable ACLs
See Creating, Duplicating, and Editing Downloadable ACLs, page 8-18.
You can add downloadable ACLs (DACLs) to a network access authorization profile. After you create the authorization profile, you can add it as a result in an authorization policy in a network access service.
1 You cannot migrate these data entities. You must recreate them in ACS 5.0.
Related Topics
•
•
Downloading ACS 4.x to 5.0 Migration Files
To download migration application files and the migration guide for ACS 5.0:
Step 1
The Migration from 4.x page appears.
Step 2
Step 3