Cisco Systems CSACS3415K9 User Manual

User Guide for Cisco Secure Access Control System 5.4

November 2013
Americas Headquarters
Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000
800 553-NETS (6387)
Text Part Number: OL-26225-01
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
User Guide for Cisco Secure Access Control System 5.4
© 2012 Cisco Systems, Inc. All rights reserved.

CONTENTS

Preface xxiii
Audience xxiii
Document Conventions xxiii
Documentation Updates xxiv
Related Documentation xxiv
Obtaining Documentation and Submitting a Service Request xxv
CHAPTER
CHAPTER
1 Introducing ACS 5.4 1-1
Overview of ACS 1-1
ACS Distributed Deployment 1-2
ACS 4.x and 5.4 Replication 1-2
ACS Licensing Model 1-3
ACS Management Interfaces 1-3
ACS Web-based Interface 1-4 ACS Command Line Interface 1-4 ACS Programmatic Interfaces 1-5
Hardware Models Supported by ACS 1-5
2 Migrating from ACS 4.x to ACS 5.4 2-1
Overview of the Migration Process 2-2
Migration Requirements 2-2 Supported Migration Versions 2-2
Before You Begin 2-3
Downloading Migration Files 2-3
CHAPTER
OL-26225-01
Migrating from ACS 4.x to ACS 5.4 2-3
Functionality Mapping from ACS 4.x to ACS 5.4 2-5
Common Scenarios in Migration 2-7
Migrating from ACS 4.2 on CSACS 1120 to ACS 5.4 2-7 Migrating from ACS 3.x to ACS 5.4 2-8 Migrating Data from Other AAA Servers to ACS 5.4 2-8
3 ACS 5.x Policy Model 3-1
Overview of the ACS 5.x Policy Model 3-1
User Guide for Cisco Secure Access Control System 5.4
iii
Contents
Policy Terminology 3-3 Simple Policies 3-4 Rule-Based Policies 3-4 Types of Policies 3-5
Access Services 3-6
Identity Policy 3-9 Group Mapping Policy 3-11 Authorization Policy for Device Administration 3-11
Processing Rules with Multiple Command Sets 3-11 Exception Authorization Policy Rules 3-12
Service Selection Policy 3-12
Simple Service Selection 3-12 Rules-Based Service Selection 3-13 Access Services and Service Selection Scenarios 3-13 First-Match Rule Tables 3-14
Policy Conditions 3-16 Policy Results 3-16
CHAPTER
Authorization Profiles for Network Access 3-16
Processing Rules with Multiple Authorization Profiles 3-17
Policies and Identity Attributes 3-17
Policies and Network Device Groups 3-18
Example of a Rule-Based Policy 3-18
Flows for Configuring Services and Policies 3-19
4 Common Scenarios Using ACS 4-1
Overview of Device Administration 4-2
Session Administration 4-3 Command Authorization 4-4 TACACS+ Custom Services and Attributes 4-5
Password-Based Network Access 4-5
Overview of Password-Based Network Access 4-5 Password-Based Network Access Configuration Flow 4-7
Certificate-Based Network Access 4-9
Overview of Certificate-Based Network Access 4-9 Using Certificates in ACS 4-10
Certificate-Based Network Access 4-10 Authorizing the ACS Web Interface from Your Browser Using a Certificate 4-11 Validating an LDAP Secure Authentication Connection 4-12
iv
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Agentless Network Access 4-12
Overview of Agentless Network Access 4-12 Host Lookup 4-13 Authentication with Call Check 4-14
Process Service-Type Call Check 4-15 PAP/EAP-MD5 Authentication 4-15 Agentless Network Access Flow 4-16 Adding a Host to an Internal Identity Store 4-17 Configuring an LDAP External Identity Store for Host Lookup 4-17 Configuring an Identity Group for Host Lookup Network Access Requests 4-18 Creating an Access Service for Host Lookup 4-18
Configuring an Identity Policy for Host Lookup Requests 4-19
Configuring an Authorization Policy for Host Lookup Requests 4-20
VPN Remote Network Access 4-20
Supported Authentication Protocols 4-21 Supported Identity Stores 4-21 Supported VPN Network Access Servers 4-22 Supported VPN Clients 4-22 Configuring VPN Remote Access Service 4-22
Contents
CHAPTER
ACS and Cisco Security Group Access 4-23
Adding Devices for Security Group Access 4-24 Creating Security Groups 4-24 Creating SGACLs 4-25 Configuring an NDAC Policy 4-25 Configuring EAP-FAST Settings for Security Group Access 4-26 Creating an Access Service for Security Group Access 4-26 Creating an Endpoint Admission Control Policy 4-27 Creating an Egress Policy 4-27 Creating a Default Policy 4-28
RADIUS and TACACS+ Proxy Requests 4-29
Supported Protocols 4-30 Supported RADIUS Attributes 4-31 TACACS+ Body Encryption 4-31 Connection to TACACS+ Server 4-31 Configuring Proxy Service 4-32
5 Understanding My Workspace 5-1
OL-26225-01
Welcome Page 5-1
Task Guides 5-2
User Guide for Cisco Secure Access Control System 5.4
v
Contents
My Account Page 5-2
Login Banner 5-3
Using the Web Interface 5-3
Accessing the Web Interface 5-4
Logging In 5-4 Logging Out 5-5
Understanding the Web Interface 5-5
Web Interface Design 5-6 Navigation Pane 5-7 Content Area 5-8
Importing and Exporting ACS Objects through the Web Interface 5-18
Supported ACS Objects 5-18 Creating Import Files 5-21
Downloading the Template from the Web Interface 5-21 Understanding the CSV Templates 5-22 Creating the Import File 5-22
CHAPTER
CHAPTER
Common Errors 5-25
Concurrency Conflict Errors 5-25 Deletion Errors 5-26 System Failure Errors 5-27
Accessibility 5-27
Display and Readability Features 5-27 Keyboard and Mouse Features 5-28 Obtaining Additional Accessibility Information 5-28
6 Post-Installation Configuration Tasks 6-1
Configuring Minimal System Setup 6-1
Configuring ACS to Perform System Administration Tasks 6-2
Configuring ACS to Manage Access Policies 6-4
Configuring ACS to Monitor and Troubleshoot Problems in the Network 6-4
7 Managing Network Resources 7-1
Network Device Groups 7-2
Creating, Duplicating, and Editing Network Device Groups 7-2 Deleting Network Device Groups 7-3 Creating, Duplicating, and Editing Network Device Groups Within a Hierarchy 7-4 Deleting Network Device Groups from a Hierarchy 7-5
vi
Network Devices and AAA Clients 7-5
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Viewing and Performing Bulk Operations for Network Devices 7-6 Exporting Network Devices and AAA Clients 7-7 Performing Bulk Operations for Network Resources and Users 7-8 Exporting Network Resources and Users 7-10 Creating, Duplicating, and Editing Network Devices 7-10
Configuring Network Device and AAA Clients 7-11 Displaying Network Device Properties 7-14 Deleting Network Devices 7-17
Configuring a Default Network Device 7-17
Working with External Proxy Servers 7-19
Creating, Duplicating, and Editing External Proxy Servers 7-19 Deleting External Proxy Servers 7-21
Working with OCSP Services 7-21
Creating, Duplicating, and Editing OCSP Servers 7-22 Deleting OCSP Servers 7-24
Contents
CHAPTER
8 Managing Users and Identity Stores 8-1
Overview 8-1
Internal Identity Stores 8-1 External Identity Stores 8-2
Identity Stores with Two-Factor Authentication 8-3 Identity Groups 8-3 Certificate-Based Authentication 8-3 Identity Sequences 8-4
Managing Internal Identity Stores 8-4
Authentication Information 8-5 Identity Groups 8-6
Creating Identity Groups 8-6
Deleting an Identity Group 8-7 Managing Identity Attributes 8-7
Standard Attributes 8-8
User Attributes 8-8
Host Attributes 8-9 Configuring Authentication Settings for Users 8-9 Creating Internal Users 8-11 Deleting Users from Internal Identity Stores 8-15 Viewing and Performing Bulk Operations for Internal Identity Store Users 8-15 Creating Hosts in Identity Stores 8-16 Deleting Internal Hosts 8-18
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
vii
Contents
Viewing and Performing Bulk Operations for Internal Identity Store Hosts 8-18 Management Hierarchy 8-19
Attributes of Management Hierarchy 8-19 Configuring AAA Devices for Management Hierarchy 8-19 Configuring Users or Hosts for Management Hierarchy 8-20 Configuring and Using UserIsInManagement Hierarchy Attribute 8-20 Configuring and Using HostIsInManagement Hierarchy Attributes 8-21
Managing External Identity Stores 8-22
LDAP Overview 8-22
Directory Service 8-23 Authentication Using LDAP 8-23 Multiple LDAP Instances 8-23 Failover 8-24 LDAP Connection Management 8-24 Authenticating a User Using a Bind Connection 8-24 Group Membership Information Retrieval 8-25 Attributes Retrieval 8-25 Certificate Retrieval 8-26 Creating External LDAP Identity Stores 8-26 Configuring an External LDAP Server Connection 8-27 Configuring External LDAP Directory Organization 8-29 Deleting External LDAP Identity Stores 8-33 Configuring LDAP Groups 8-33 Viewing LDAP Attributes 8-34
Leveraging Cisco NAC Profiler as an External MAB Database 8-34
Enabling the LDAP Interface on Cisco NAC Profiler to Communicate with ACS 8-35 Configuring NAC Profile LDAP Definition in ACS for Use in Identity Policy 8-37 Troubleshooting MAB Authentication with Profiler Integration 8-41
Microsoft AD 8-41
Machine Authentication 8-43 Attribute Retrieval for Authorization 8-44 Group Retrieval for Authorization 8-44 Certificate Retrieval for EAP-TLS Authentication 8-44 Concurrent Connection Management 8-44 User and Machine Account Restrictions 8-44 Machine Access Restrictions 8-45 Distributed MAR Cache 8-46 Dial-In Permissions 8-47 Callback Options for Dial-In users 8-48 Joining ACS to an AD Domain 8-49
viii
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Configuring an AD Identity Store 8-49
Selecting an AD Group 8-53
Configuring AD Attributes 8-54
Configuring Machine Access Restrictions 8-56 RSA SecurID Server 8-57
Configuring RSA SecurID Agents 8-58
Creating and Editing RSA SecurID Token Servers 8-59 RADIUS Identity Stores 8-63
Supported Authentication Protocols 8-63
Failover 8-64
Password Prompt 8-64
User Group Mapping 8-64
Groups and Attributes Mapping 8-64
RADIUS Identity Store in Identity Sequence 8-65
Authentication Failure Messages 8-65
Username Special Format with Safeword Server 8-65
User Attribute Cache 8-66
Creating, Duplicating, and Editing RADIUS Identity Servers 8-66
Contents
CHAPTER
Configuring CA Certificates 8-71
Adding a Certificate Authority 8-72 Editing a Certificate Authority and Configuring Certificate Revocation Lists 8-73 Deleting a Certificate Authority 8-74 Exporting a Certificate Authority 8-75
Configuring Certificate Authentication Profiles 8-75
Configuring Identity Store Sequences 8-77
Creating, Duplicating, and Editing Identity Store Sequences 8-78 Deleting Identity Store Sequences 8-80
9 Managing Policy Elements 9-1
Managing Policy Conditions 9-1
Creating, Duplicating, and Editing a Date and Time Condition 9-3 Creating, Duplicating, and Editing a Custom Session Condition 9-5 Deleting a Session Condition 9-6 Managing Network Conditions 9-6
Importing Network Conditions 9-8
Exporting Network Conditions 9-9
Creating, Duplicating, and Editing End Station Filters 9-9
Creating, Duplicating, and Editing Device Filters 9-12
Creating, Duplicating, and Editing Device Port Filters 9-15
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
ix
Contents
Managing Authorizations and Permissions 9-17
Creating, Duplicating, and Editing Authorization Profiles for Network Access 9-18
Specifying Authorization Profiles 9-19 Specifying Common Attributes in Authorization Profiles 9-19
Specifying RADIUS Attributes in Authorization Profiles 9-22 Creating and Editing Security Groups 9-24 Creating, Duplicating, and Editing a Shell Profile for Device Administration 9-24
Defining General Shell Profile Properties 9-26
Defining Common Tasks 9-26
Defining Custom Attributes 9-29 Creating, Duplicating, and Editing Command Sets for Device Administration 9-29 Creating, Duplicating, and Editing Downloadable ACLs 9-32 Deleting an Authorizations and Permissions Policy Element 9-33 Configuring Security Group Access Control Lists 9-34
CHAPTER
10 Managing Access Policies 10-1
Policy Creation Flow 10-1
Network Definition and Policy Goals 10-2 Policy Elements in the Policy Creation Flow 10-3 Access Service Policy Creation 10-4 Service Selection Policy Creation 10-4
Customizing a Policy 10-4
Configuring the Service Selection Policy 10-5
Configuring a Simple Service Selection Policy 10-6 Service Selection Policy Page 10-6 Creating, Duplicating, and Editing Service Selection Rules 10-8 Displaying Hit Counts 10-10 Deleting Service Selection Rules 10-10
Configuring Access Services 10-11
Editing Default Access Services 10-11 Creating, Duplicating, and Editing Access Services 10-12
Configuring General Access Service Properties 10-13
Configuring Access Service Allowed Protocols 10-16
Configuring Access Services Templates 10-20 Deleting an Access Service 10-21
Configuring Access Service Policies 10-22
Viewing Identity Policies 10-22
Viewing Rules-Based Identity Policies 10-24 Configuring Identity Policy Rule Properties 10-25
User Guide for Cisco Secure Access Control System 5.4
x
OL-26225-01
Configuring a Group Mapping Policy 10-27 Configuring Group Mapping Policy Rule Properties 10-29 Configuring a Session Authorization Policy for Network Access 10-30 Configuring Network Access Authorization Rule Properties 10-32 Configuring Device Administration Authorization Policies 10-33 Configuring Device Administration Authorization Rule Properties 10-34 Configuring Device Administration Authorization Exception Policies 10-34 Configuring Shell/Command Authorization Policies for Device Administration 10-35 Configuring Authorization Exception Policies 10-36 Creating Policy Rules 10-38 Duplicating a Rule 10-39 Editing Policy Rules 10-39 Deleting Policy Rules 10-40
Configuring Compound Conditions 10-41
Compound Condition Building Blocks 10-41 Types of Compound Conditions 10-42 Using the Compound Expression Builder 10-45
Contents
CHAPTER
Security Group Access Control Pages 10-46
Egress Policy Matrix Page 10-46 Editing a Cell in the Egress Policy Matrix 10-47 Defining a Default Policy for Egress Policy Page 10-47 NDAC Policy Page 10-48 NDAC Policy Properties Page 10-49 Network Device Access EAP-FAST Settings Page 10-51
Maximum User Sessions 10-51
Max Session User Settings 10-52 Max Session Group Settings 10-52 Max Session Global Setting 10-53 Purging User Sessions 10-54 Maximum User Session in Distributed Environment 10-55 Maximum User Session in Proxy Scenario 10-56
11 Monitoring and Reporting in ACS 11-1
Authentication Records and Details 11-2
Dashboard Pages 11-2
OL-26225-01
Working with Portlets 11-4
Working with Authentication Lookup Portlet 11-5
Running Authentication Lookup Report 11-6
Configuring Tabs in the Dashboard 11-6
User Guide for Cisco Secure Access Control System 5.4
xi
Contents
Adding Tabs to the Dashboard 11-6
Adding Applications to Tabs 11-7 Renaming Tabs in the Dashboard 11-7 Changing the Dashboard Layout 11-8 Deleting Tabs from the Dashboard 11-8
CHAPTER
12 Managing Alarms 12-1
Understanding Alarms 12-1
Evaluating Alarm Thresholds 12-2 Notifying Users of Events 12-3
Viewing and Editing Alarms in Your Inbox 12-3
Understanding Alarm Schedules 12-9
Creating and Editing Alarm Schedules 12-9 Assigning Alarm Schedules to Thresholds 12-10 Deleting Alarm Schedules 12-11
Creating, Editing, and Duplicating Alarm Thresholds 12-11
Configuring General Threshold Information 12-13 Configuring Threshold Criteria 12-14
Passed Authentications 12-14
Failed Authentications 12-16
Authentication Inactivity 12-18
TACACS Command Accounting 12-19
TACACS Command Authorization 12-20
ACS Configuration Changes 12-21
ACS System Diagnostics 12-22
ACS Process Status 12-23
ACS System Health 12-24
ACS AAA Health 12-25
RADIUS Sessions 12-26
Unknown NAD 12-27
External DB Unavailable 12-28
RBACL Drops 12-29
NAD-Reported AAA Downtime 12-31 Configuring Threshold Notifications 12-32
xii
Deleting Alarm Thresholds 12-33
Configuring System Alarm Settings 12-34
Understanding Alarm Syslog Targets 12-35
Creating and Editing Alarm Syslog Targets 12-35 Deleting Alarm Syslog Targets 12-36
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Contents
CHAPTER
13 Managing Reports 13-1
Working with Favorite Reports 13-3
Adding Reports to Your Favorites Page 13-3 Viewing Favorite-Report Parameters 13-4 Editing Favorite Reports 13-5 Running Favorite Reports 13-5 Deleting Reports from Favorites 13-6
Sharing Reports 13-6
Working with Catalog Reports 13-7
Available Reports in the Catalog 13-7 Running Catalog Reports 13-11 Deleting Catalog Reports 13-12 Running Named Reports 13-13
Understanding the Report_Name Page 13-14 Enabling RADIUS CoA Options on a Device 13-17 Changing Authorization and Disconnecting Active RADIUS Sessions 13-18 Customizing Reports 13-19 Restoring Reports 13-20
Viewing Reports 13-20
About Standard Viewer 13-21 About Interactive Viewer 13-21 About the Interactive Viewer Context Menus 13-21 Navigating Reports 13-22
Using the Table of Contents 13-23 Exporting Report Data 13-24 Printing Reports 13-26 Saving Report Designs in Interactive Viewer 13-26
Formatting Reports in Interactive Viewer 13-27
Editing Labels 13-27 Formatting Labels 13-28 Formatting Data 13-28 Resizing Columns 13-29 Changing Column Data Alignment 13-29 Formatting Data in Columns 13-29 Formatting Data in Aggregate Rows 13-30 Formatting Data Types 13-30 Formatting Numeric Data 13-31 Formatting Fixed or Scientific Numbers or Percentages 13-32 Formatting Custom Numeric Data 13-33
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
xiii
Contents
Formatting String Data 13-33 Formatting Custom String Data 13-33 Formatting Date and Time 13-35 Formatting Custom Date and Time 13-35 Formatting Boolean Data 13-36 Applying Conditional Formats 13-37 Setting Conditional Formatting for Columns 13-38 Deleting Conditional Formatting 13-40 Setting and Removing Page Breaks in Detail Columns 13-40 Setting and Removing Page Breaks in a Group Column 13-41
Organizing Report Data 13-41
Displaying and Organizing Report Data 13-42 Reordering Columns in Interactive Viewer 13-42 Removing Columns 13-44 Hiding or Displaying Report Items 13-44 Hiding Columns 13-45 Displaying Hidden Columns 13-45 Merging Columns 13-45 Selecting a Column from a Merged Column 13-47 Sorting Data 13-47 Sorting a Single Column 13-47 Sorting Multiple Columns 13-47 Grouping Data 13-49 Adding Groups 13-50 Grouping Data Based on Date or Time 13-50 Removing an Inner Group 13-51 Creating Report Calculations 13-52
Understanding Supported Calculation Functions 13-53 Understanding Supported Operators 13-61 Using Numbers and Dates in an Expression 13-61 Using Multiply Values in Calculated Columns 13-62 Adding Days to an Existing Date Value 13-62
Subtracting Date Values in a Calculated Column 13-63 Working with Aggregate Data 13-63 Creating an Aggregate Data Row 13-65 Adding Additional Aggregate Rows 13-66 Deleting Aggregate Rows 13-67
xiv
Hiding and Filtering Report Data 13-67
Hiding or Displaying Column Data 13-67
Displaying Repeated Values 13-68
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Hiding or Displaying Detail Rows in Groups or Sections 13-68
Working with Filters 13-69
Types of Filter Conditions 13-70 Setting Filter Values 13-71 Creating Filters 13-72 Modifying or Clearing a Filter 13-73 Creating a Filter with Multiple Conditions 13-73
Deleting One Filter Condition in a Filter that Contains Multiple Conditions 13-75 Filtering Highest or Lowest Values in Columns 13-75
Understanding Charts 13-76
Modifying Charts 13-77
Filtering Chart Data 13-77
Changing Chart Subtype 13-78
Changing Chart Formatting 13-78
Contents
CHAPTER
CHAPTER
14 Troubleshooting ACS with the Monitoring and Report Viewer 14-1
Available Diagnostic and Troubleshooting Tools 14-1
Connectivity Tests 14-1 ACS Support Bundle 14-1 Expert Troubleshooter 14-2
Performing Connectivity Tests 14-3
Downloading ACS Support Bundles for Diagnostic Information 14-4
Working with Expert Troubleshooter 14-6
Troubleshooting RADIUS Authentications 14-6 Executing the Show Command on a Network Device 14-10 Evaluating the Configuration of a Network Device 14-10 Comparing SGACL Policy Between a Network Device and ACS 14-12 Comparing the SXP-IP Mappings Between a Device and its Peers 14-12 Comparing IP-SGT Pairs on a Device with ACS-Assigned SGT Records 14-15 Comparing Device SGT with ACS-Assigned Device SGT 14-16
15 Managing System Operations and Configuration in the Monitoring and Report Viewer 15-1
Configuring Data Purging and Incremental Backup 15-3
Configuring NFS Staging 15-7
OL-26225-01
Restoring Data from a Backup 15-7
Viewing Log Collections 15-8
Log Collection Details Page 15-10
Recovering Log Messages 15-12
User Guide for Cisco Secure Access Control System 5.4
xv
Contents
Viewing Scheduled Jobs 15-12
Viewing Process Status 15-14
Viewing Data Upgrade Status 15-15
Viewing Failure Reasons 15-15
Editing Failure Reasons 15-15
Specifying E-Mail Settings 15-16
Configuring SNMP Preferences 15-16
Understanding Collection Filters 15-17
Creating and Editing Collection Filters 15-17 Deleting Collection Filters 15-18
Configuring System Alarm Settings 15-18
Configuring Alarm Syslog Targets 15-18
Configuring Remote Database Settings 15-18
Changing the Port Numbers for Oracle Database 15-20
CHAPTER
16 Managing System Administrators 16-1
Understanding Administrator Roles and Accounts 16-2
Understanding Authentication 16-3
Configuring System Administrators and Accounts 16-3
Understanding Roles 16-3
Assigning Roles 16-3 Assigning Static Roles 16-4
Assigning Dynamic Roles 16-4 Permissions 16-4 Predefined Roles 16-5 Changing Role Associations 16-6 Administrator Accounts and Role Association 16-6
Recovery Administrator Account 16-7
Creating, Duplicating, Editing, and Deleting Administrator Accounts 16-7
Viewing Predefined Roles 16-9
Viewing Role Properties 16-10
Configuring Authentication Settings for Administrators 16-10
Configuring Session Idle Timeout 16-12
xvi
Configuring Administrator Access Settings 16-13
Working with Administrative Access Control 16-14
Administrator Identity Policy 16-15
Viewing Rule-Based Identity Policies 16-16
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Configuring Identity Policy Rule Properties 16-18 Administrator Authorization Policy 16-19 Configuring Administrator Authorization Policies 16-19 Configuring Administrator Authorization Rule Properties 16-20 Administrator Login Process 16-21
Resetting the Administrator Password 16-22
Changing the Administrator Password 16-22
Changing Your Own Administrator Password 16-22 Resetting Another Administrator’s Password 16-23
Contents
CHAPTER
17 Configuring System Operations 17-1
Understanding Distributed Deployment 17-2
Activating Secondary Servers 17-3 Removing Secondary Servers 17-4 Promoting a Secondary Server 17-4 Understanding Local Mode 17-4 Understanding Full Replication 17-5 Specifying a Hardware Replacement 17-5
Scheduled Backups 17-6
Creating, Duplicating, and Editing Scheduled Backups 17-6
Backing Up Primary and Secondary Instances 17-8
Synchronizing Primary and Secondary Instances After Backup and Restore 17-9
Editing Instances 17-9
Viewing and Editing a Primary Instance 17-9 Viewing and Editing a Secondary Instance 17-13 Deleting a Secondary Instance 17-13
Activating a Secondary Instance 17-14
Registering a Secondary Instance to a Primary Instance 17-14
OL-26225-01
Deregistering Secondary Instances from the Distributed System Management Page 17-17
Deregistering a Secondary Instance from the Deployment Operations Page 17-17
Promoting a Secondary Instance from the Distributed System Management Page 17-18
Promoting a Secondary Instance from the Deployment Operations Page 17-19
Replicating a Secondary Instance from a Primary Instance 17-19
Replicating a Secondary Instance from the Distributed System Management Page 17-20 Replicating a Secondary Instance from the Deployment Operations Page 17-20 Changing the IP address of a Primary Instance from the Primary Server 17-21 Failover 17-22
Using the Deployment Operations Page to Create a Local Mode Instance 17-23
User Guide for Cisco Secure Access Control System 5.4
xvii
Contents
Creating, Duplicating, Editing, and Deleting Software Repositories 17-24 Managing Software Repositories from the Web Interface and CLI 17-25
CHAPTER
18 Managing System Administration Configurations 18-1
Configuring Global System Options 18-1
Configuring TACACS+ Settings 18-1 Configuring EAP-TLS Settings 18-2 Configuring PEAP Settings 18-3 Configuring EAP-FAST Settings 18-3 Generating EAP-FAST PAC 18-4
Configuring RSA SecurID Prompts 18-4
Managing Dictionaries 18-5
Viewing RADIUS and TACACS+ Attributes 18-5 Creating, Duplicating, and Editing RADIUS Vendor-Specific Attributes 18-6 Creating, Duplicating, and Editing RADIUS Vendor-Specific Subattributes 18-7 Viewing RADIUS Vendor-Specific Subattributes 18-9 Configuring Identity Dictionaries 18-10 Creating, Duplicating, and Editing an Internal User Identity Attribute 18-10 Configuring Internal Identity Attributes 18-11 Deleting an Internal User Identity Attribute 18-12 Creating, Duplicating, and Editing an Internal Host Identity Attribute 18-13 Deleting an Internal Host Identity Attribute 18-13 Adding Static IP address to Users in Internal Identity Store 18-14
xviii
Configuring Local Server Certificates 18-14
Adding Local Server Certificates 18-14
Importing Server Certificates and Associating Certificates to Protocols 18-15 Generating Self-Signed Certificates 18-16 Generating a Certificate Signing Request 18-17 Binding CA Signed Certificates 18-18 Editing and Renewing Certificates 18-18 Deleting Certificates 18-19 Exporting Certificates 18-20 Viewing Outstanding Signing Requests 18-20
Configuring Logs 18-21
Configuring Remote Log Targets 18-21 Deleting a Remote Log Target 18-23 Configuring the Local Log 18-24 Deleting Local Log Data 18-24 Configuring Logging Categories 18-24
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Configuring Global Logging Categories 18-25 Configuring Per-Instance Logging Categories 18-29 Configuring Per-Instance Security and Log Settings 18-30
Configuring Per-Instance Remote Syslog Targets 18-31 Displaying Logging Categories 18-32 Configuring the Log Collector 18-33 Viewing the Log Message Catalog 18-33
Licensing Overview 18-34
Types of Licenses 18-34
Installing a License File 18-35
Viewing the Base License 18-36 Upgrading the Base Server License 18-37
Viewing License Feature Options 18-38
Adding Deployment License Files 18-39
Contents
CHAPTER
Deleting Deployment License Files 18-40
Available Downloads 18-40
Downloading Migration Utility Files 18-41 Downloading UCP Web Service Files 18-41 Downloading Sample Python Scripts 18-41 Downloading Rest Services 18-42
19 Understanding Logging 19-1
About Logging 19-1
Using Log Targets 19-2 Logging Categories 19-2 Global and Per-Instance Logging Categories 19-4 Log Message Severity Levels 19-4 Local Store Target 19-5
Critical Log Target 19-7 Remote Syslog Server Target 19-8 Monitoring and Reports Server Target 19-10 Viewing Log Messages 19-10 Debug Logs 19-11
APPENDIX
OL-26225-01
ACS 4.x Versus ACS 5.4 Logging 19-12
A AAA Protocols A-1
Typical Use Cases A-1
Device Administration (TACACS+) A-1
User Guide for Cisco Secure Access Control System 5.4
xix
Contents
Session Access Requests (Device Administration [TACACS+]) A-2 Command Authorization Requests A-2
Network Access (RADIUS With and Without EAP) A-2
RADIUS-Based Flow Without EAP Authentication A-3 RADIUS-Based Flows with EAP Authentication A-3
Access Protocols—TACACS+ and RADIUS A-5
Overview of TACACS+ A-5
Overview of RADIUS A-6
RADIUS VSAs A-6 ACS 5.4 as the AAA Server A-7 RADIUS Attribute Support in ACS 5.4 A-8
RADIUS Attribute Rewrite Operation A-9
RADIUS Access Requests A-11
APPENDIX
B Authentication in ACS 5.4 B-1
Authentication Considerations B-1
Authentication and User Databases B-1
PAP B-2
RADIUS PAP Authentication B-3
EAP B-3
EAP-MD5 B-5
Overview of EAP-MD5 B-5 EAP- MD5 Flow in ACS 5.4 B-5
EAP-TLS B-5
Overview of EAP-TLS B-6
User Certificate Authentication B-6 PKI Authentication B-7
PKI Credentials B-8
PKI Usage B-8 Fixed Management Certificates B-9 Importing Trust Certificates B-9
Acquiring Local Certificates B-9
Importing the ACS Server Certificate B-10 Initial Self-Signed Certificate Generation B-10
Certificate Generation B-10 Exporting Credentials B-11 Credentials Distribution B-12
Hardware Replacement and Certificates B-12 Securing the Cryptographic Sensitive Material B-12
xx
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Private Keys and Passwords Backup B-13
EAP-TLS Flow in ACS 5.4 B-13
PEAPv0/1 B-14
Overview of PEAP B-15
Supported PEAP Features B-15
PEAP Flow in ACS 5.4 B-17
Creating the TLS Tunnel B-18 Authenticating with MSCHAPv2 B-19
EAP-FAST B-19
Overview of EAP-FAST B-19
EAP-FAST Benefits B-21
EAP-FAST in ACS 5.4 B-21
About Master-Keys B-22 About PACs B-22 Provisioning Modes B-23 Types of PACs B-23 ACS-Supported Features for PACs B-25 Master Key Generation and PAC TTLs B-27
EAP-FAST for Allow TLS Renegotiation B-27 EAP-FAST Flow in ACS 5.4. B-27 EAP-FAST PAC Management B-28
Key Distribution Algorithm B-29
EAP-FAST PAC-Opaque Packing and Unpacking B-29
Revocation Method B-29
PAC Migration from ACS 4.x B-29
Contents
OL-26225-01
EAP Authentication with RADIUS Key Wrap B-30
EAP-MSCHAPv2 B-30
Overview of EAP-MSCHAPv2 B-31
MSCHAPv2 for User Authentication B-31
MSCHAPv2 for Change Password B-31
Windows Machine Authentication Against AD B-31 EAP- MSCHAPv2 Flow in ACS 5.4 B-32
CHAP B-32
LEAP B-32
Certificate Attributes B-32
Certificate Binary Comparison B-33
Rules Relating to Textual Attributes B-33 Certificate Revocation B-34
Machine Authentication B-35
User Guide for Cisco Secure Access Control System 5.4
xxi
Contents
Authentication Protocol and Identity Store Compatibility B-36
APPENDIX
G
LOSSARY
I
NDEX
C Open Source License Acknowledgements C-1
Notices C-1
OpenSSL/Open SSL Project C-1
License Issues C-1
C-3
xxii
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01

Preface

Revised: November 13, 2013
This guide describes how to use Cisco Secure Access Control System (ACS) 5.4.
Audience
This guide is for security administrators who use ACS, and who set up and maintain network and application security.
Document Conventions
This guide uses the convention whereby the symbol ^ represents the key labeled Control. For example, the key combination ^z means hold down the Control key while you press the z key.
Command descriptions use these conventions:
Examples that contain system prompts denote interactive sessions, indicating the commands that
you should enter at the prompt. The system prompt indicates the current level of the EXEC command interpreter. For example, the prompt level, and the prompt privileged level usually requires a password.
Router> indicates that you should be at the user
Router# indicates that you should be at the privileged level. Access to the
OL-26225-01
Commands and keywords are in boldface font.
Arguments for which you supply values are in italic font.
Elements in square brackets ([ ]) are optional.
Alternative keywords of which you must choose one are grouped in braces ({}) and separated by
vertical bars (|).
Examples use these conventions:
Terminal sessions and sample console screen displays are in screen font.
Information you enter is in boldface screen font.
Nonprinting characters, such as passwords, are in angle brackets (< >).
Default responses to system prompts are in square brackets ([]).
An exclamation point (!) at the beginning of a line indicates a comment line.
User Guide for Cisco Secure Access Control System 5.4
xxiii
Caution Means reader be careful. You are capable of doing something that might result in equipment damage or
loss of data.
Timesaver Means the described action saves time. You can save time by performing the action described in the
paragraph.
Note Means reader take note. Notes identify important information that you should reflect upon before
continuing, contain helpful suggestions, or provide references to materials not contained in the document.
Documentation Updates
Table 1 lists the updates to the User Guide for Cisco Secure Access Control System 5.4.
Preface
Table 1 Updates to the User Guide for Cisco Secure Access Control System 5.4
Date Description
9/26/2013 Fixed the following bugs:
CSCuh90646
CSCuj24445
10/30/2012 Updated the guide with Cisco 3415 Secure Access Control System information.
10/23/2012 Cisco Secure Access Control System, Release 5.4.
Related Documentation
Table 2 lists a set of related technical documentation available on Cisco.com. To find end-user
documentation for all products on Cisco.com, go to: http://www.cisco.com/go/techdocs.
Select Products > Security > Access Control and Policy > Policy and Access Management > Cisco Secure Access Control System.
Note It is possible for the printed and electronic documentation to be updated after original publication.
Therefore, you should also review the documentation on http://www.cisco.com for any updates.
xxiv
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Preface
Table 2 Product Documentation
Document Title Available Formats
Cisco Secure Access Control System In-Box Documentation and China ROHS Pointer Card
License and Documentation Guide for Cisco Secure Access Control System 5.4
Release Notes for Cisco Secure Access Control System 5.4
Migration Guide for Cisco Secure Access Control System 5.4
CLI Reference Guide for Cisco Secure Access Control System 5.4
Supported and Interoperable Devices and Software for Cisco Secure Access Control System 5.4
Installation and Upgrade Guide for Cisco Secure Access Control System 5.4
Software Developer’s Guide for Cisco Secure Access Control System 5.4
Regulatory Compliance and Safety Information for Cisco Secure Access Control System 5.4
http://www.cisco.com/en/US/products/ps9911/ products_licensing_information_listing.html
http://www.cisco.com/en/US/products/ps9911/ products_documentation_roadmaps_list.html
http://www.cisco.com/en/US/products/ps9911/ prod_release_notes_list.html
http://www.cisco.com/en/US/products/ps9911/ prod_installation_guides_list.html
http://www.cisco.com/en/US/products/ps9911/ prod_command_reference_list.html
http://www.cisco.com/en/US/products/ps9911/ products_device_support_tables_list.html
http://www.cisco.com/en/US/products/ps9911/ prod_installation_guides_list.html
http://www.cisco.com/en/US/products/ps9911/ products_programming_reference_guides_list.html
http://www.cisco.com/en/US/docs/net_mgmt/cisco_ secure_access_control_system/5.4/regulatory/comp liance/csacsrcsi.html
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What’s New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What’s New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
xxv
Preface
xxvi
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01

Introducing ACS 5.4

This section contains the following topics:
Overview of ACS, page 1-1
ACS Distributed Deployment, page 1-2
ACS Management Interfaces, page 1-3

Overview of ACS

ACS is a policy-based security server that provides standards-compliant Authentication, Authorization, and Accounting (AAA) services to your network. ACS facilitates the administrative management of Cisco and non-Cisco devices and applications.
As a dominant enterprise network access control platform, ACS serves as an integration point for network access control and identity management.
CHA PTER
1
ACS 5.x provides a rule-based policy model that allows you to control network access based on dynamic conditions and attributes. The rule-based policy is designed to meet complex access policy needs. For more information on the rule-based policy model in ACS, see Chapter 3, “ACS 5.x Policy Model.”
Within the greater context of two major AAA protocols—RADIUS and TACACS+—ACS provides the following basic areas 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 includes PAP, CHAP, MSCHAPv1, MSCHAPv2. It also supports 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, EAP-GTC, and EAP-TLS. For more information on authentication methods, see Authentication in ACS 5.4.
Under the framework of the TACACS+ protocol, ACS helps to manage Cisco and non-Cisco
network devices such as switches, wireless access points, routers, and gateways. It also helps to manage services and entities such as dialup, Virtual Private Network (VPN), and firewall.
ACS is the point in your network that identifies users and devices that try to connect to your network. This identity establishment can occur directly by using the ACS internal identity repository for local user authentication or by using external identity repositories.
For example, ACS can use Active Directory as an external identity repository, to authenticate a user to grant the user access to the network. For more information about creating identities and supported identity services, see Chapter 8, “Managing Users and Identity Stores.”
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
1-1

ACS Distributed Deployment

ACS provides advanced monitoring, reporting, and troubleshooting tools that help you administer and manage your ACS deployments. For more information on the monitoring, reporting, and troubleshooting capabilities of ACS, see Chapter 11, “Monitoring and Reporting in ACS.”.
For more information about using ACS for device administration and network access scenarios, see
Chapter 4, “Common Scenarios Using ACS.”
Cisco Secure ACS:
Enforces access policies for VPN and wireless users.
Provides simplified device administration.
Provides advanced monitoring, reporting, and troubleshooting tools.
There are several changes and enhancements in ACS 5.4 compared to ACS 5.3. For a complete list of new and changed features, see:
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.4/release/notes/ acs_54_rn.html.
Related Topics
ACS Distributed Deployment, page 1-2
Chapter 1 Introducing ACS 5.4
ACS Management Interfaces, page 1-3
ACS Distributed Deployment
ACS 5.4 is delivered preinstalled on a standard Cisco Linux-based appliance, and supports a fully distributed deployment.
An ACS deployment can consist of a single instance, or multiple instances deployed in a distributed manner, where all instances in a system are managed centrally. One ACS instance becomes the primary instance and you can register additional ACS instances to the primary instance as secondary instances. All instances have the configuration for the entire deployment, which provides redundancy for configuration data.
The primary instance centralizes the configuration of the instances in the deployment. Configuration changes made in the primary instance are automatically replicated to the secondary instance.
You can force a full replication to the secondary instance. Full replication is used when a new secondary instance is registered and in other cases when the replication gap between the secondary instance and the primary instance is significant.
Related Topic
ACS 4.x and 5.4 Replication, page 1-2
ACS 4.x and 5.4 Replication
In ACS 4.x, you must select the database object types (or classes) you wish to replicate from primary instance to the secondary instance. When you replicate an object, a complete configuration copy is made on the secondary instance.
In ACS 5.4, any configuration changes made in the primary instance are immediately replicated to the secondary instance. Only the configuration changes made since the last replication are propagated to the secondary instance.
User Guide for Cisco Secure Access Control System 5.4
1-2
OL-26225-01
Chapter 1 Introducing ACS 5.4
ACS 4.x did not provide incremental replication, only full replication, and there was service downtime for replication. ACS 5.4 provides incremental replications with no service downtime.
You can also force a full replication to the secondary instance if configuration changes do not replicate it. Full replication is used when a new secondary instance is registered and other cases when the replication gap between the secondary instance and the primary instance is significant.
Table 1 -1 lists some of the differences between ACS 4.x and 5.4 replication.
Table 1-1 Differences Between ACS 4.x and 5.4 Replication
ACS 4.x ACS 5.4
You can choose the data items to be replicated. You cannot choose the data items to be replicated.
Supports multi-level or cascading replication. Supports only a fixed flat replication. Cascading
Some data items, such as the external database configurations, are not replicated.

ACS Licensing Model

All data items, by default are replicated.
replication is not supported.
All data items are replicated except the database key, database certificate, and master keys. The server certificates, Certificate Signing Requests (CSRs), and private keys are replicated, but they are not shown in the interface.
For more information about setting up a distributed deployment, see Configuring System Operations,
page 17-1.
Note Replication does not work in ACS servers if you use the Cisco Overlay Transport Virtualization
technology in your Virtual Local Area Network.
Note Network Address Translation (NAT) is not supported in an ACS distributed deployment environment.
That is, if the network address of a primary or secondary instance is translated, then the database replication may not work properly, and it may display a shared secret mismatch error.
ACS Licensing Model
You must have a valid license to operate ACS; ACS prompts you to install a valid base license when you first access the web interface. Each server requires a unique base license in a distributed deployment.
For information about the types of licenses you can install, see Types of Licenses, page 18-34. For more information about licenses, see Licensing Overview, page 18-34.
Related Topic
ACS Distributed Deployment, page 1-2

ACS Management Interfaces

This section contains the following topics:
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
1-3
ACS Management Interfaces
ACS Web-based Interface, page 1-4
ACS Command Line Interface, page 1-4
ACS Programmatic Interfaces, page 1-5
ACS Web-based Interface
You can use the ACS web-based interface to fully configure your ACS deployment, and perform monitoring and reporting operations. The web interface provides a consistent user experience, regardless of the particular area that you are configuring.
The ACS web interface is supported on HTTPS-enabled Microsoft Internet Explorer versions from 6.x to 9.x and Mozilla Firefox versions from 3.x to 10.x.
The new web interface design and organization:
Reflects the new policy model, which is organized around the user’s view of policy administration.
The new policy model is easier to use, as it separates the complex interrelationships that previously existed among policy elements.
For example, user groups, network device groups (NDGs), network access filters, network access profiles, and so on.
Presents the configuration tasks in a logical order that you can follow for many common scenarios.
Chapter 1 Introducing ACS 5.4
For example, first you configure conditions and authorizations for policies in the Policy Elements drawer, and then you move on to the Policies drawer to configure the policies with the defined policy elements.
Provides new page functionality, such as sorting and filtering lists of items.
See “Using the Web Interface” section on page 5-3 for more information.
Related Topics
ACS Command Line Interface, page 1-4
ACS Command Line Interface
You can use the ACS command-line interface (CLI), a text-based interface, to perform some configuration and operational tasks and monitoring. Access to the ACS-specific CLI requires administrator authentication by ACS 5.4.
You do not need to be an ACS administrator or log into ACS 5.4 to use the non-ACS configuration mode. ACS configuration mode command sessions are logged to the diagnostics logs.
ACS 5.4 is shipped on the Cisco 1121 Secure Access Control System (CSACS-1121) or on the Cisco 3415 Secure Access Control System (CSACS-3415). The ADE-OS software supports these command modes:
EXEC—Use these commands to perform system-level operation tasks. For example, install, start,
and stop application; copy files and installations; restore backups; and display information.
1-4
In addition, certain EXEC mode commands have ACS-specific abilities. For example, start an ACS instance, display and export ACS logs, and reset an ACS configuration to factory default settings. Such commands are specifically mentioned in the documentation
ACS configuration—Use these commands to set the debug log level (enable or disable) for the ACS
management and runtime components, and show system settings.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 1 Introducing ACS 5.4
Configuration—Use these commands to perform additional configuration tasks for the appliance
server in an ADE-OS environment.
Note The CLI includes an option to reset the configuration that, when issued, resets all ACS configuration
information, but retains the appliance settings such as network configuration.
For information about using the CLI, see the Command Line Interface Reference Guide for Cisco Secure Access Control System 5.4.
Related Topic
ACS Web-based Interface, page 1-4
ACS Programmatic Interfaces
ACS 5.4 provides web services and command-line interface (CLI) commands that allow software developers and system integrators to programmatically access some ACS features and functions. ACS
5.4 also provides you access to the Monitoring and Report Viewer database that you can use to create custom applications to monitor and troubleshoot ACS.

Hardware Models Supported by ACS

The UCP web service allows users, defined in the ACS internal database, to first authenticate and then change their own password. ACS exposes the UCP web service to allow you to create custom web-based applications that you can deploy in your enterprise.
The Monitoring and Report Viewer web services allow you to create custom applications to track and troubleshoot events in ACS.
You can develop shell scripts using the CLI commands that ACS offers to perform create, read, update, and delete (CRUD) operations on ACS objects. You can also create an automated shell script to perform bulk operations.
The REST PI (Representational State Transfer Programming Interface) allows you to manage entities such as users, hosts, identity groups, network devices, network device groups, and network device group types on your own management applications and move these entities into ACS. This way you can define these entities and then use them on your own systems and on ACS.
For more information on how to access these web services and their functionalities, see
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.4/sdk/ acs_sdk.html.
Hardware Models Supported by ACS
Table 1 -2 shows the details of the hardware models supported by ACS 5.4.
Table 1-2 Hardware Models Supported by ACS 5.4
OL-26225-01
Config HDD RAM NIC
UCS 3415 500 GB 8 GB 2 x 2 (4-1 Gb)
IBM 1121 2 x 250GB 4GB 4X10,100,1000 RJ-45
CAM25-1-2-4. 2 x 250GB 4 x 1GB 2 x 1GE
VMware ESX i5.0 60 to 750 GB 4GB 2 NICs
User Guide for Cisco Secure Access Control System 5.4
1-5
Hardware Models Supported by ACS
Chapter 1 Introducing ACS 5.4
1-6
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
CHA PTER
2

Migrating from ACS 4.x to ACS 5.4

ACS 4.x stores policy and authentication information, such as TACACS+ command sets, in the user and user group records. In ACS 5.4, 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.4 provides a migration utility to transfer data from migration-supported versions of ACS 4.x to an ACS 5.4 machine. The ACS 5.4 migration process requires, in some cases, administrative intervention to manually resolve data before you import it to ACS 5.4.
This process is different from the process of upgrading 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 intervention is required.
The migration utility in ACS 5.4 supports multiple-instance migration that migrates all ACS 4.x servers in your deployment to ACS 5.4. For more information on multiple-instance migration, see
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.4/migration/ guide/migration_guide.html.
OL-26225-01
Upgrade refers to the process of transferring data from ACS 5.3 servers to ACS 5.4. For information on the upgrade process, refer to
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.4/installation/ guide/csacs_upg.html.
This chapter contains the following sections:
Overview of the Migration Process, page 2-2
Before You Begin, page 2-3
Downloading Migration Files, page 2-3
Migrating from ACS 4.x to ACS 5.4, page 2-3
Functionality Mapping from ACS 4.x to ACS 5.4, page 2-5
Common Scenarios in Migration, page 2-7
User Guide for Cisco Secure Access Control System 5.4
2-1

Overview of the Migration Process

Overview of the Migration Process
The Migration utility completes the data migration process in two phases:
Analysis and Export
Import
In the Analysis and Export phase, you identify the objects that you want to export into 5.4. The Migration utility analyses the objects, consolidates the data, and exports it.
After the Analysis and Export phase is complete, the Migration utility generates a report that lists any data compatibility errors, which you can manually resolve to successfully import these objects into 5.4.
The Analysis and Export phase is an iterative process that you can rerun many times to ensure that there are no errors in the data to be imported. After you complete the Analysis and Export phase, you can run the import phase to import data into ACS 5.4.
This section contains the following topics:
Migration Requirements, page 2-2
Supported Migration Versions, page 2-2
Chapter 2 Migrating from ACS 4.x to ACS 5.4
Migration Requirements
To run the Migration utility, you must deploy the following machines:
The source ACS 4.x machine—This machine can either be an ACS 4.x solution engine or a ACS for
Windows 4.x machine. The source machine must be running a migration-supported version of ACS. See Supported Migration Versions, page 2-2 for more information.
The migration machine—This machine must be a Windows platform that runs the same version of
ACS (including the patch) as the source machine. The migration machine cannot be an ACS production machine or an ACS appliance machine. It has to be a Windows server running ACS for Windows. The migration machine requires 2 GB RAM.
The target ACS 5.4 machine—Back up your ACS 5.4 configuration data and ensure that the
migration interface is enabled on ACS 5.4 before you begin the import process. We recommend that you import data into a fresh ACS 5.4 database. To enable the migration interface, from the ACS CLI, enter:
acs config-web-interface migration enable
Supported Migration Versions
ACS 5.4 supports migration from the following ACS 4.x versions:
ACS 4.1.1.24
ACS 4.1.4
ACS 4.2.0.124
2-2
ACS 4.2.1
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 2 Migrating from ACS 4.x to ACS 5.4
Note You must install the latest patch for the supported migration versions listed here. Also, if you have any
other version of ACS 4.x installed, you must upgrade to one of the supported versions and install the latest patch for that version before you can migrate to ACS 5.4.

Before You Begin

Before you migrate data from ACS 4.x to ACS 5.4, ensure that you:
Check for database corruption issues in the ACS 4.x source machine.
Have the same ACS versions on the source and migration machines (including the patch).
Have configured a single IP address on the migration machine.
Take a backup of the source ACS 4.x data.
Have full network connectivity between the migration machine and the ACS 5.4 server.
Have enabled the migration interface on the ACS 5.4 server.
Before You Begin
Use only the default superadmin account for ACS 5.4, acsadmin while running the Migration utility.
You cannot use the remote desktop to connect to the migration machine to run the Migration Utility. You must run the Migration Utility on the migration machine; or, use VNC to connect to the migration machine.
Note ACS 5.4 migration utility is not supported on Windows 2008 64 bit.

Downloading Migration Files

To download migration application files and the migration guide for ACS 5.4:
Step 1 Select System Administration > Downloads > Migration Utility.
The Migration from 4.x page appears.
Step 2 Click Migration application files, to download the application file you want to use to run the migration
utility.
Step 3 Click Migration Guide, to download Migration Guide for Cisco Secure Access Control System 5.4.

Migrating from ACS 4.x to ACS 5.4

You can migrate data from any of the migration-supported versions of ACS 4.x to ACS 5.4. The migration utility migrates the following ACS 4.x data entities:
Network Device Groups (NDGs)
AAA Clients and Network Devices
Internal Users
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
2-3
Migrating from ACS 4.x to ACS 5.4
User-Defined Fields (from the Interface Configuration section)
User Groups
Shared Shell Command Authorization Sets
User TACACS+ Shell Exec Attributes (migrated to user attributes)
Group TACACS+ Shell Exec Attributes (migrated to shell profiles)
User TACACS+ Command Authorization Sets
Group TACACS+ Command Authorization Sets
Shared, Downloadable ACLs
EAP-FAST Master Keys
Shared RADIUS Authorization Components (RACs)
RADIUS VSAs
Note The Migration utility does not migrate public key infrastructure (PKI) configuration data and does not
support certificate migration.
Chapter 2 Migrating from ACS 4.x to ACS 5.4
To migrate data from ACS 4.x to ACS 5.4:
Step 1 Upgrade the ACS 4.x version to a migration-supported version if your ACS 4.x server currently does not
run one of the migration-supported versions.
For a list of migration-supported ACS versions, see Supported Migration Versions, page 2-2.
Step 2 Install the same migration-supported version of ACS on the migration machine, which is a Windows
server.
Step 3 Back up the ACS 4.x data and restore it on the migration machine.
Step 4 Place the Migration utility on the migration machine.
You can get the Migration utility from the Installation and Recovery DVD.
Step 5 Run the Analyze and Export phase of the Migration utility on the migration machine.
Step 6 Resolve any issues in the Analyze and Export phase.
Step 7 Run the Import phase of the Migration utility on the migration machine.
The import phase imports data into the 5.4 server.
Note If you have a large internal database, then we recommend that you import the data into a standalone 5.x
primary server and not to a server that is connected to several secondary servers. After data migration is complete, you can register the secondary servers to the standalone 5.x primary server.
2-4
For detailed information about using the migration utility, refer to
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.4/migration/ guide/migration_guide.html.
After you migrate the data, you can reconstruct your policies with the migrated objects.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 2 Migrating from ACS 4.x to ACS 5.4

Functionality Mapping from ACS 4.x to ACS 5.4

Functionality Mapping from ACS 4.x to ACS 5.4
In ACS 5.4, 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 -1 describes where you configure identities, network resources, and policy elements in ACS 5.4.
Use this table to view and modify your migrated data identities. See Chapter 3, “ACS 5.x Policy Model” for an overview of the ACS 5.4 policy model.
Table 2-1 Functionality Mapping from ACS 4.x to ACS 5.4
To configure... In ACS 4.x, choose... In ACS 5.4, choose... Additional information for 5.4
Network device groups Network
Configuration page
Network devices and AAA clients
User groups Group Setup page Users and Identity Stores >
Network Configuration page
Network Resources > Network Device Groups
See Creating, Duplicating, and
Editing Network Device Groups, page 7-2.
Network Resources > Network Devices and AAA Clients
See Network Devices and AAA
Clients, page 7-5.
Identity Groups
You can use NDGs as conditions in policy rules.
ACS 5.4 does not support NDG shared password. After migration, member devices contain the NDG shared password information.
RADIUS KeyWrap keys (KEK and MACK) are migrated from ACS 4.x to ACS 5.4.
You can use identity groups as conditions in policy rules.
See Managing Identity
Attributes, page 8-7.
Internal users User Setup page Users and Identity Stores >
Internal Identity Stores > Users
See Managing Internal Identity
Stores, page 8-4.
Internal hosts Network Access
Profiles > Authentication
Identity attributes (user-defined fields)
Interface Configuration > User Data Configuration
Users and Identity Stores > Internal Identity Stores > Hosts
See Creating Hosts in Identity
Stores, page 8-16.
System Administration > Configuration > Dictionaries > Identity > Internal Users
See Managing Dictionaries,
page 18-5.
ACS 5.4 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.
You can use the internal hosts in identity policies for Host Lookup.
Defined identity attribute fields appear in the User Properties page. You can use them as conditions in access service policies.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
2-5
Chapter 2 Migrating from ACS 4.x to ACS 5.4
Functionality Mapping from ACS 4.x to ACS 5.4
Table 2-1 Functionality Mapping from ACS 4.x to ACS 5.4 (continued)
To configure... In ACS 4.x, choose... In ACS 5.4, choose... Additional information for 5.4
Command sets (command authorization sets)
One of the following:
Shared Profile
Components > Command Authorization Set
User Setup page
Group Setup page
Policy Elements > Authorization and Permissions > Device Administration > Command Set
See Creating, Duplicating, and
Editing Command Sets for Device Administration, page 9-29.
Shell exec parameters User Setup page System Administration >
Dictionaries > Identity > Internal Users
You can add command sets as results in authorization policy rules in a device administration access service.
Defined identity attribute fields appear in the User Properties page.
Shell profiles (shell exec
Group Setup page Policy Elements > Authorization parameters or shell command authorization sets)
Date and time condition (Time
Group Setup page Policy Elements > Session of Day Access)
You cannot migrate the date and time conditions. You have to recreate them in ACS 5.4.
RADIUS Attributes One of the following:
Shared Profile
Components > RADIUS Authorization Component
User Setup page
Group Setup page
You cannot migrate the
RADIUS attributes
from user and group
setups. You have to
recreate them in ACS
5.4.
See Managing Dictionaries,
page 18-5.
and Permissions > Device Administration > Shell Profile
See Creating, Duplicating, and
Editing a Shell Profile for Device Administration, page 9-24.
Conditions > Date and Time
See Creating, Duplicating, and
Editing a Date and Time Condition, page 9-3.
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 9-18.
You can use them as conditions in access service policies.
You can add shell profiles as results in authorization policy rules in a device administration access service.
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.
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.
2-6
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 2 Migrating from ACS 4.x to ACS 5.4

Common Scenarios in Migration

Table 2-1 Functionality Mapping from ACS 4.x to ACS 5.4 (continued)
To configure... In ACS 4.x, choose... In ACS 5.4, choose... Additional information for 5.4
Downloadable ACLs Shared Profile
Components
RADIUS VSA Interface
Configuration
Policy Elements > Authorization and Permissions > Named Permission Objects > Downloadable ACLs
See Creating, Duplicating, and
Editing Downloadable ACLs, page 9-32.
System Administration > Configuration > Dictionaries > Protocols > RADIUS > RADIUS VSA.
See Creating, Duplicating, and
Editing RADIUS Vendor-Specific Attributes, page 18-6.
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.
You configure RADIUS VSA 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.
Common Scenarios in Migration
The following are some of the common scenarios that you encounter while migrating to ACS 5.4:
Migrating from ACS 4.2 on CSACS 1120 to ACS 5.4, page 2-7
Migrating from ACS 3.x to ACS 5.4, page 2-8
Migrating Data from Other AAA Servers to ACS 5.4, page 2-8
Migrating from ACS 4.2 on CSACS 1120 to ACS 5.4
In your deployment, if you have ACS 4.2 on CSACS 1120 and you would like to migrate to ACS 5.4, you must do the following:
Step 1 Install Cisco Secure Access Control Server 4.2 for Windows on the migration machine.
Step 2 Back up the ACS 4.2 data on CSACS 1120.
Step 3 Restore the data in the migration machine.
Step 4 Run the Analysis and Export phase of the Migration utility on the migration machine.
Step 5 Install ACS 5.4 on CSACS 1120.
Step 6 Import the data from the migration machine to the CSACS 1120 that has ACS 5.4 installed.
OL-26225-01
See http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.4/migration/
guide/migration_guide.html for a detailed description of each of these steps.
User Guide for Cisco Secure Access Control System 5.4
2-7
Common Scenarios in Migration
Migrating from ACS 3.x to ACS 5.4
If you have ACS 3.x deployed in your environment, you cannot directly migrate to ACS 5.4. You must do the following:
Step 1 Upgrade to a migration-supported version of ACS 4.x. See Supported Migration Versions, page 2-2 for
a list of supported migration versions.
Step 2 Check the upgrade paths for ACS 3.x:
For the ACS Solution Engine, see:
http://www.cisco.com/en/US/docs/net_mgmt/ cisco_secure_access_control_server_for_solution_engine/4.1/installation/guide/solution_engine/ upgap.html#wp1120037
For ACS for Windows, see:
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/
4.2/installation/guide/windows/install.html#wp1102849
Step 3 Upgrade your ACS 3.x server to a migration-supported version of ACS 4.x.
Chapter 2 Migrating from ACS 4.x to ACS 5.4
After the upgrade, follow the steps that describe migrating from ACS 4.x to ACS 5.4. Refer to the Migration Guide for Cisco Secure Access Control System 5.4 for more information.
Migrating Data from Other AAA Servers to ACS 5.4
ACS 5.4 allows you to perform bulk import of various ACS objects through the ACS web interface and the CLI. You can import the following ACS objects:
Users
Hosts
Network Devices
Identity Groups
NDGs
Downloadable ACLs
Command Sets
ACS allows you to perform bulk import of data with the use of a comma-separated values (.csv) file. You must input data in the .csv file in the format that ACS requires. ACS provides a .csv template for the various objects that you can import to ACS 5.4. You can download this template from the web interface.
To migrate data from other AAA servers to ACS 5.4:
2-8
Step 1 Input data into .csv files.
For more information on understanding .csv templates, see
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.4/sdk/ cli_imp_exp.html#wp1064565.
Step 2 Set up your ACS 5.4 appliance.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 2 Migrating from ACS 4.x to ACS 5.4
Step 3 Perform bulk import of data into ACS 5.4.
For more information on performing bulk import of ACS objects, see
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.4/sdk/ cli_imp_exp.html#wp1056244.
The data from your other AAA servers is now available in ACS 5.4.
Common Scenarios in Migration
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
2-9
Common Scenarios in Migration
Chapter 2 Migrating from ACS 4.x to ACS 5.4
2-10
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
CHA PTER
3

ACS 5.x Policy Model

ACS 5.x is a policy-based access control system. The term policy model in ACS 5.x refers to the presentation of policy elements, objects, and rules to the policy administrator. ACS 5.x uses a rule-based policy model instead of the group-based model used in the 4.x versions.
This section contains the following topics:
Overview of the ACS 5.x Policy Model, page 3-1
Access Services, page 3-6
Service Selection Policy, page 3-12
Authorization Profiles for Network Access, page 3-16
Policies and Identity Attributes, page 3-17
Policies and Network Device Groups, page 3-18
Example of a Rule-Based Policy, page 3-18
Flows for Configuring Services and Policies, page 3-19
Note See Functionality Mapping from ACS 4.x to ACS 5.4, page 2-5 for a mapping of ACS 4.x concepts to
ACS 5.4.

Overview of the ACS 5.x Policy Model

The ACS 5.x rule-based policy model provides more powerful and flexible access control than is possible with the older group-based approach.
In the older group-based model, a group defines policy because it contains and ties together three types of information:
Identity information—This information can be based on membership in AD or LDAP groups or a
static assignment for internal ACS users.
Other restrictions or conditions—Time restrictions, device restrictions, and so on.
Permissions—VLANs or Cisco IOS privilege levels.
The ACS 5.x policy model is based on rules of the form:
If condition then result
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
3-1
Overview of the ACS 5.x Policy Model
For example, we use the information described for the group-based model:
If identity-condition, restriction-condition then authorization-profile
In ACS 5.4, you define conditions and results as global, shared objects. You define them once and then reference them when you create rules. ACS 5.4 uses the term policy elements for these shared objects, and they are the building blocks for creating rules.
Table 3 -1 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.4 Policy Element
Identity information
Other policy conditions
Permissions Authorization profiles
Chapter 3 ACS 5.x Policy Model
AD group membership and attributes
LDAP group membership and attributes
ACS internal identity groups and attributes
Time and date conditions
Custom conditions
A policy is a set of rules that ACS 5.x uses to evaluate an access request and return a decision. For example, the set of rules in an:
Authorization policy return 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.x organizes the sequence of independent policies (a policy workflow) into an access service, which it uses to process an access request. You can create multiple access services to process different kinds of access requests; for example, for device administration or network access. For more information, see Access Services, page 3-6.
You can define simple policies and rule-based policies. Rule-based policies are complex policies that test various conditions. Simple policies apply a single result to all requests without any conditions.
There are various types of policies:
For more information on the different types of policies, see Types of Policies, page 3-5.
For more information about policy model terminology, see Policy Terminology, page 3-3.
Related Topics
Policies and Identity Attributes, page 3-17
Flows for Configuring Services and Policies, page 3-19
3-2
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 3 ACS 5.x Policy Model
Overview of the ACS 5.x Policy Model
Policy Terminology
Table 3 -2 describes the rule-based policy terminology.
Table 3-2 Rule-Based Policy Terminology
Term Description
Access service Sequential set of policies used to process access requests. ACS 5.x allows you to define multiple
access services to support multiple, independent, and isolated sets of policies on a single ACS system.
There are two default access services: one for device administration (TACACS+ based access to the device shell or CLI) and one for network access (RADIUS-based access to network connectivity).
Policy element Global, shared object that defines policy conditions (for example, time and date, or custom
conditions based on user-selected attributes) and permissions (for example, authorization profiles). The policy elements are referenced when you create policy rules.
Authorization profile Basic permissions container for a RADIUS-based network access service, which is where you define
all permissions to be granted for a network access request.
VLANs, ACLs, URL redirects, session timeout or reauthorization timers, or any other RADIUS attributes to be returned in a response, are defined in the authorization profile.
Shell profile Basic permissions container for TACACS+ based device administration policy. This is where you
define permissions to be granted for a shell access request.
IOS privilege level, session timeout, and so on are defined in the shell profile.
Command set Contains the set of permitted commands for TACACS+ based, per-command authorization.
Policy Set of rules that are used to reach a specific policy decision. For example, how to authenticate and
what authorization to grant. For any policies that have a default rule, a policy is a first-match rules table with a default rule for any request which does not match any user-created rules.
Identity policy ACS 5.4 policy for choosing how to authenticate and acquire identity attributes for a given request.
ACS 5.4 allows two types of identity policies: a simple, static policy, or a rules-based policy for more complex situations.
Identity group mapping policy
Optional policy for mapping identity information collected from identity stores (for example, group memberships and user attributes) to a single ACS identity group.
This can help you normalize identity information and map requests to a single identity group, which is just a tag or an identity classification. The identity group can be used as a condition in authorization policy, if desired.
Authorization policy ACS 5.4 policy for assigning authorization attributes for access requests. Authorization policy
selects a single rule and populates the response with the contents of the authorization profiles referenced as the result of the rule.
Exception policy Special option for authorization policy, which allows you to define separately the set of conditions
and authorization results for authorization policy exceptions and waivers. If defined, the exception policy is checked before the main (standard) authorization policy.
Default rule Catchall rule in ACS 5.4 policies. You can edit this rule to specify a default result or authorization
action, and it serves as the policy decision in cases where a given request fails to match the conditions specified in any user-created rule.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
3-3
Overview of the ACS 5.x Policy Model
Simple Policies
You can configure all of your ACS policies as rule-based policies. However, in some cases, you can choose to configure a simple policy, which selects a single result to apply to all requests without conditions.
For example, you can define a rule-based authentication policy with a set of rules for different conditions; or, if you want to use the internal database for all authentications, you can define a simple policy.
Table 3 -3 helps you determine whether each policy type can be configured as a simple policy.
If you create and save a simple policy, and then change to a rule-based policy, the simple policy
If you have saved a rule-based policy and then change to a simple policy, ACS automatically uses
Related Topic
Types of Policies, page 3-5
Chapter 3 ACS 5.x Policy Model
becomes the default rule of the rule-based policy.
the default rule as the simple policy.
Rule-Based Policies
Rule-based policies have been introduced to overcome the challenges of identity-based policies. In earlier versions of ACS, although membership in a user group gives members access permissions, it also places certain restrictions on them.
When a user requests access, the user's credentials are authenticated using an identity store, and the user is associated with the appropriate user group. Because authorization is tied to user group, all members of a user group have the same access restrictions and permissions at all times.
With this type of policy (the simple policy), permissions are granted based on a user’s association with a particular user group. This is useful if the user’s identity is the only dominant condition. However, for users who need different permissions under different conditions, this policy does not work.
In ACS 5.x, you can create rules based on various conditions apart from identity. The user group no longer contains all of the information.
For example, if you want to grant an employee full access while working on campus, and restricted access while working remotely, you can do so using the rule-based policies in ACS 5.4.
You can base permissions on various conditions besides identity, and permissions are no longer associated with user groups. You can use session and environment attributes, such as access location, access type, health of the end station, date, time, and so on, to determine the type of access to be granted.
Authorization is now based on a set of rules:
If conditions then apply the respective permissions
With rule-based policies, conditions can consist of any combination of available session attributes, and permissions are defined in authorization profiles. You define these authorization profiles to include VLAN, downloadable ACLs, QoS settings, and RADIUS attributes.
3-4
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 3 ACS 5.x Policy Model
Types of Policies
Table 3 -3 describes the types of policies that you can configure in ACS.
The policies are listed in the order of their evaluation; any attributes that a policy retrieves can be used in any policy listed subsequently. The only exception is the Identity group mapping policy, which uses only attributes from identity stores.
Ta bl e 3 -3 A C S P o li cy Ty p es
Overview of the ACS 5.x Policy Model
Available Dictionaries for Conditions
identity store related
Available Result Types Attributes Retrieved
Access Service
Policy
Service Selection
Determines the access service to apply to an
Can Contain
1
Exception Policy?
Simple Rule-Based?
and
No Yes All except
incoming request.
Identity
Determines the identity source for authentication.
Identity Group Mapping
Defines mapping attributes
No Yes All except
identity store related
No Yes Only identity
store dictionaries
Identity Source, Failure options
Identity Group Identity Group for
and groups from external identity stores to ACS identity groups.
Network Access Authorization
Determines authorization and permissions for
Yes Rule-based
only
All dictionaries Authorization
Profile, Security Group Access
network access.
Device Administration Authorization
Yes Rule-based
only
All dictionaries Shell Profile,
Command Set
Determines authorization and permissions for device administration.
1. A simple policy specifies a single set of results that ACS applies to all requests; it is in effect a one-rule policy.
Identity Attributes; Identity Group for internal ID stores
external ID stores
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
3-5

Access Services

Access Services
Access services are fundamental constructs in ACS 5.x that allow you to configure access policies for users and devices that connect to the network and for network administrators who administer network devices.
In ACS 5.x, authentication and authorization requests are processed by access services. An access service consists of the following elements:
Identity Policy—Specifies how the user should be authenticated and includes the allowed
authentication protocols and the user repository to use for password validation.
Group Mapping Policy—Specifies if the user's ACS identity group should be dynamically
established based on user attributes or group membership in external identity stores. The user's identity group can be used as part of their authorization.
Authorization Policy—Specifies the authorization rules for the user.
The access service is an independent set of policies used to process an access request.
The ACS administrator might choose to create multiple access services to allow clean separation and isolation for processing different kinds of access requests. ACS provides two default access services:
Chapter 3 ACS 5.x Policy Model
Default Device Admin—Used for TACACS+ based access to device CLI
Default Network Access—Used for RADIUS-based access to network connectivity
You can use the access services as is, modify them, or delete them as needed. You can also create additional access services.
The TACACS+ protocol separates authentication from authorization; ACS processes TACACS+ authentication and authorization requests separately. Tabl e 3-4 describes additional differences between RADIUS and TACACS+ access services.
Table 3-4 Differences Between RADIUS and TACACS+ Access Services
Policy Type TACACS+ RADIUS
Identity Optional
1
Required
Group Mapping Optional Optional
Authorization Optional
1. For TACACS+, you must select either Identity or Authorization.
1
Required
For TACACS+, all policy types are optional; however, you must choose at least one policy type in a service. If you do not define an identity policy for TACACS+, ACS returns authentication failed for an authentication request.
Similarly, if you do not define an authorization policy and if ACS receives a session or command authorization request, it fails. For both RADIUS and TACACS+ access services, you can modify the service to add policies after creation.
3-6
Note Access services do not contain the service selection policy. Service selection rules are defined
independently.
You can maintain and manage multiple access services; for example, for different use cases, networks, regions, or administrative domains. You configure a service selection policy, which is a set of service selection rules to direct each new access request to the appropriate access service.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 3 ACS 5.x Policy Model
Table 3 -5 describes an example of a set of access services.
Table 3-5 Access Service List
Access Services
Access Service A for Device Administration
Access Service B for Access to 802.1X Agentless Hosts
Access Service C for Access from 802.1X Wired and Wireless Devices
Identity Policy A Identity Policy B Identity Policy C
Shell/Command Authorization
Session Authorization Policy B Session Authorization Policy C
Policy A
Table 3 -6 describes a service selection policy.
Table 3-6 Service Selection Policy
Rule Name Condition Result
DevAdmin protocol = TACACS+ Access Service A
Agentless Host Lookup = True Access Service C
Default Access Service B
If ACS 5.4 receives a TACACS+ access request, it applies Access Service A, which authenticates the request according to Identity Policy A. It then applies authorizations and permissions according to the shell/command authorization policy. This service handles all TACACS+ requests.
If ACS 5.4 receives a RADIUS request that it determines is a host lookup (for example, the RADIUS service-type attribute is equal to call-check), it applies Access Service C, which authenticates according to Identity Policy C. It then applies a session authorization profile according to Session Authorization Policy C. This service handles all host lookup requests (also known as MAC Auth Bypass requests).
Access Service B handles other RADIUS requests. This access service authenticates according to Identity Policy B and applies Session Authorization Policy B. This service handles all RADIUS requests except for host lookups, which are handled by the previous rule.
Access Service Templates
ACS contains predefined access services that you can use as a template when creating a new service. When you choose an access service template, ACS creates an access service that contains a set of policies, each with a customized set of conditions.
You can change the structure of the access service by adding or removing a policy from the service, and you can change the structure of a policy by modifying the set of policy conditions. See Configuring
Access Services Templates, page 10-20, for a list of the access service templates and descriptions.
RADIUS and TACACS+ Proxy Services
ACS 5.4 can function as a RADIUS, RADIUS proxy or TACACS+ proxy server.
As a RADIUS proxy server, ACS receives authentication and accounting requests from the NAS and
forwards the requests to the external RADIUS server.
As a TACACS+ proxy server, ACS receives authentication, authorization and accounting requests
from the NAS and forwards the requests to the external TACACS+ server.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
3-7
Access Services
Chapter 3 ACS 5.x Policy Model
ACS accepts the results of the requests and returns them to the NAS. You must configure the external RADIUS and TACACS+ servers in ACS for ACS to forward requests to them. You can define the timeout period and the number of connection attempts.
The ACS proxy remote target is a list of remote RADIUS and TACACS+ servers that contain the following parameters:
IP
Authentication port
Accounting port
Shared secret
Reply timeout
Number of retries
Connection port
Network timeout
The following information is available in the proxy service:
Remote RADIUS or TACACS+ servers list
Accounting proxy local/remote/both
Strip username prefix/suffix
When a RADIUS proxy server receives a request, it forwards it to the first remote RADIUS or TACACS+ server in the list. If the proxy server does not receive a response within the specified timeout interval and the specified number of retries, it forwards the request to the next RADIUS or TACACS+ server in the list.
When the first response arrives from any of the remote RADIUS or TACACS+ servers in the list, the proxy service processes it. If the response is valid, ACS sends the response back to the NAS.
Table 3 -7 lists the differences in RADIUS proxy service between ACS 4.2 and 5.4 releases.
Table 3-7 Differences in RADIUS and TACACS+ Proxy Service Between ACS 4.2 and 5.4
Feature ACS 5.4 ACS 4.2
Configurable timeout (RADIUS) Yes No
Configurable retry count (RADIUS) Yes No
Network timeout (TACACS+) Yes No
Authentication and accounting ports
Ye s Ye s
(RADIUS)
Connection port (TACACS+) Yes No
Proxy cycles detection Yes (For RADIUS only) No
Username stripping Yes Yes
Accounting proxy (local, remote, or both) Yes Yes
Account delay timeout support (RADIUS) No No
3-8
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 3 ACS 5.x Policy Model
ACS can simultaneously act as a proxy server to multiple external RADIUS and TACACS+ servers. For ACS to act as a proxy server, you must configure a RADIUS or TACACS+ proxy service in ACS. See
Configuring General Access Service Properties, page 10-13 for information on how to configure a
RADIUS proxy service.
For more information on proxying RADIUS and TACACS+ requests, see RADIUS and TACACS+ Proxy
Requests, page 4-29.
Related Topics
Identity Policy
Two primary mechanisms define the mechanism and source used to authenticate requests:
Access Services
Policy Terminology, page 3-3
Types of Policies, page 3-5
Flows for Configuring Services and Policies, page 3-19
Password-based—Authentication is performed against databases after the user enters a username
and password. Hosts can bypass this authentication by specifying a MAC address. However, for identity policy authentication, host lookup is also considered to be password-based.
Certificate-based—A client presents a certificate for authentication of the session. In ACS 5.4,
certificate-based authentication occurs when the PEAP-TLS or EAP-TLS protocol is selected.
In addition, databases can be used to retrieve attributes for the principal in the request.
The identity source is one result of the identity policy and can be one of the following types:
Deny Access—Access to the user is denied and no authentication is performed.
Identity Database—Single identity database. When a single identity database is selected as the result
of the identity policy, either an external database (LDAP or AD) or an internal database (users or hosts) is selected as the result.
The database selected is used to authenticate the user/host and to retrieve any defined attributes stored for the user/host in the database.
Certificate Authentication Profile—Contains information about the structure and content of the
certificate, and specifically maps certificate attribute to internal username. For certificate-based authentication, you must select a certificate authentication profile.
For certificate based requests, the entity which identifies itself with a certificate holds the private key that correlates to the public key stored in the certificate. The certificate authentication profile extends the basic PKI processing by defining the following:
The certificate attribute used to define the username. You can select a subset of the certificate attributes to populate the username field for the context of the request. The username is then used to identify the user for the remainder of the request, including the identification used in the logs.
The LDAP or AD database to use to verify the revocation status of the certificate. When you select an LDAP or AD database, the certificate data is retrieved from the LDAP or AD database and compared against the data entered by the client in order to provide additional verification of the client certificate.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
3-9
Access Services
Chapter 3 ACS 5.x Policy Model
Identity Sequence—Sequences of the identity databases. The sequence is used for authentication
and, if specified, an additional sequence is used to retrieve only attributes. You can select multiple identity methods as the result of the identity policy. You define the identity methods in an identity
sequence object, and the methods included within the sequence may be of any type.
There are two components to an identity sequence: one for authentication, and one for attribute retrieval. The administrator can select to perform authentication based on a certificate or an identity database or both.
If you choose to perform authentication based on a certificate, ACS selects a single certificate authentication profile.
If you choose to perform authentication based on an identity database, you must define a list of databases to be accessed in sequence until authentication succeeds. When authentication succeeds, any defined attributes within the database are retrieved.
In addition, you can define an optional list of databases from which additional attributes are retrieved. These additional databases can be accessed irrespective of whether password- or certificate-based authentication was used.
When certificate-based authentication is used, the username field is populated from a certificate attribute and is used to retrieve attributes. All databases defined in the list are accessed and, in cases
where a matching record for the user is found, the corresponding attributes, are retrieved.
Attributes can be retrieved for a user even if the user’s password is marked that it needs to be changed or if the user account is disabled. Even when you disable a user’s account, the user’s attributes are still available as a source of attributes, but not for authentication.
Failure Options
If a failure occurs while processing the identity policy, the failure can be one of three main types:
Authentication failed—ACS received an explicit response that the authentication failed. For
example, the wrong username or password was entered, or the user was disabled.
User/host not found—No such user/host was found in any of the authentication databases.
Process failed—There was a failure while accessing the defined databases.
All failures returned from an identity database are placed into one of the types above. For each type of failure, you can configure the following options:
Reject—ACS sends a reject reply.
Drop—No reply is returned.
Continue—ACS continues processing to the next defined policy in the service.
The Authentication Status system attribute retains the result of the identity policy processing. If you select to continue policy processing in the case of a failure, this attribute can be referred to as a condition in subsequent policy processing to distinguish cases in which identity policy processing did not succeed.
Because of restrictions on the underlying protocol being used, there are cases in which it is not possible to continue processing even if you select the Continue option. This is the case for PEAP, LEAP, and EAP-FAST; even if you select the Continue option, the request is rejected.
The following default values are used for the failure options when you create rules:
3-10
Authentication failed—The default is reject.
User/host not found—The default is reject.
Process failure—The default is drop.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 3 ACS 5.x Policy Model
Group Mapping Policy
The identity group mapping policy is a standard policy. Conditions can be based on attributes or groups retrieved from the external attribute stores only, or from certificates, and the result is an identity group within the identity group hierarchy.
If the identity policy accesses the internal user or host identity store, then the identity group is set directly from the corresponding user or host record. This processing is an implicit part of the group mapping policy.
Therefore, as part of processing in the group mapping policy, the default rule is only applied if both of the following conditions are true:
None of the rules in the group mapping table match.
The identity group is not set from the internal user or host record.
The results of the group mapping policy are stored in the IdentityGroup attribute in the System Dictionary and you can include this attribute in policies by selecting the Identity Group condition.
Authorization Policy for Device Administration
Access Services
Shell profiles determine access to the device CLI; command sets determine TACACS+ per command authorization. The authorization policy for a device administration access service can contain a single shell profile and multiple command sets.
Processing Rules with Multiple Command Sets
It is important to understand how ACS processes the command in the access request when the authorization policy includes rules with multiple command sets. When a rule result contains multiple command sets, and the rule conditions match the access request, ACS processes the command in the access request against each command set in the rule:
1. If a command set contains a match for the command and its arguments, and the match has Deny
Always, ACS designates the command set as Commandset-DenyAlways.
2. If there is no Deny Always for a command match in a command set, ACS checks all the commands
in the command set sequentially for the first match.
If the first match has Perm it , ACS designates the command set as Commandset-Permit.
If the first match has Deny, ACS designates the command set as Commandset-Deny.
3. If there is no match and “Permit any command that is not in the table below” is not checked (default,)
ACS designates the command set as Commandset-Deny.
4. If there is no match and “Permit any command that is not in the table below” is checked, ACS
designates the command set as Commandset-Permit.
5. After ACS has analyzed all the command sets, it authorizes the command:
OL-26225-01
a. If ACS designated any command set as Commandset-DenyAlways, ACS denies the command.
b. If there is no Commandset-DenyAlways, ACS permits the command if any command set is
Commandset-Permit; otherwise, ACS denies the command.
User Guide for Cisco Secure Access Control System 5.4
3-11

Service Selection Policy

Related Topics
Policy Terminology, page 3-3
Authorization Profiles for Network Access, page 3-16
Exception Authorization Policy Rules
A common real-world problem is that, in day-to-day operations, you often need to grant policy waivers or policy exceptions. A specific user might need special access for a short period of time; or, a user might require some additional user permissions to cover for someone else who is on vacation.
In ACS, you can define an exception policy for an authorization policy. The exception policy contains a separate set of rules for policy exception and waivers, which are typically ad hoc and temporary. The exception rules override the rules in the main rule table.
The exception rules can use a different set of conditions and results from those in the main policy. For example, the main policy might use Identity Group and Location as its conditions, while its related exception policy might use different conditions
By default, exception policies use a compound condition and a time and date condition. The time and date condition is particularly valuable if you want to make sure your exception rules have a definite starting and ending time.
Chapter 3 ACS 5.x Policy Model
An exception policy takes priority over the main policy. The exception policy does not require its own default rule; if there is no match in the exception policy, the main policy applies, which has its own default rule.
You can use an exception to address a temporary change to a standard policy. For example, if an administrator, John, in one group is on vacation, and an administrator, Bob, from another group is covering for him, you can create an exception rule that will give Bob the same access permissions as John for the vacation period.
Related Topics
Policy Terminology, page 3-3
Policy Conditions, page 3-16
Policy Results, page 3-16
Policies and Identity Attributes, page 3-17
Service Selection Policy
When ACS receives various access requests, it uses a service selection policy to process the request. ACS provides you two modes of service selection:
Simple Service Selection, page 3-12
Rules-Based Service Selection, page 3-13
Simple Service Selection
In the simple service selection mode, ACS processes all AAA requests with just one access service and does not actually select a service.
User Guide for Cisco Secure Access Control System 5.4
3-12
OL-26225-01
Chapter 3 ACS 5.x Policy Model
Rules-Based Service Selection
In the rules-based service selection mode, ACS decides which access service to use based on various configurable options. Some of them are:
AAA Protocol—The protocol used for the request, TACACS+ or RADIUS.
Request Attributes—RADIUS or TACACS+ attributes in the request.
Date and Time—The date and time ACS receives the request.
Network Device Group—The network device group that the AAA client belongs to.
ACS Server—The ACS server that receives this request.
AAA Client—The AAA client that sent the request.
Network condition objects—The network conditions can be based on
End Station—End stations that initiate and terminate connections.
Device—The AAA client that processes the request.
Device Port—In addition to the device, this condition also checks for the port to which the end station is associated with.
Service Selection Policy
For more information on policy conditions, see Managing Policy Conditions, page 9-1.
ACS comes preconfigured with two default access services: Default Device Admin and Default Network Access. The rules-based service selection mode is configured to use the AAA protocol as the selection criterion and hence when a TACACS+ request comes in, the Default Device Admin service is used and when a RADIUS request comes in, the Default Network Access service is used.
Access Services and Service Selection Scenarios
ACS allows an organization to manage its identity and access control requirements for multiple scenarios, such as wired, wireless, remote VPN, and device administration. The access services play a major role in supporting these different scenarios.
Access services allow the creation of distinct and separate network access policies to address the unique policy requirements of different network access scenarios. With distinct policies for different scenarios, you can better manage your organization's network.
For example, the default access services for device administration and network access reflect the typical distinction in policy that is required for network administrators accessing network devices and an organization's staff accessing the company’s network.
However, you can create multiple access services to distinguish the different administrative domains. For example, wireless access in the Asia Pacific regions can be administered by a different team than the one that manages wireless access for European users. This situation calls for the following access services:
APAC-wireless—Access service for wireless users in the Asia Pacific region.
OL-26225-01
Europe-wireless—Access service for wireless users in the European countries.
You can create additional access services to reduce complexity in policies within a single access service by creating the complex policy among multiple access services. For example, if a large organization wishes to deploy 802.1x network access, it can have the following access services:
802.1x—For machine, user password, and certificate-based authentication for permanent staff.
Agentless Devices—For devices that do not have an EAP supplicant, such as phones and printers.
Guest Access—For users accessing guest wireless networks.
User Guide for Cisco Secure Access Control System 5.4
3-13
Service Selection Policy
In this example, instead of creating the network access policy for 802.1x, agentless devices, and guest access in one access service, the policy is divided into three access services.
First-Match Rule Tables
ACS 5.4 provides policy decisions by using first-match rule tables to evaluate a set of rules. Rule tables contain conditions and results. Conditions can be either simple or compound. Simple conditions consist of attribute operator value and are either True or False. Compound conditions contain more complex conditions combined with AND or OR operators. See Policy Conditions, page 3-16 for more information.
The administrator selects simple conditions to be included in a policy. The conditions are displayed as columns in a rule table where the column headings are the condition name, which is usually the name of the attribute.
The rules are displayed under the column headings, and each cell indicates the operator and value that are combined with the attribute to form the condition. If ANY Figure 3-1 shows a column-based rule table with defined condition types.
Chapter 3 ACS 5.x Policy Model
Figure 3-1 Example Policy Rule Table
3-14
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 3 ACS 5.x Policy Model
Service Selection Policy
Column Description
Status You can define the status of a rule as enabled, disabled, or monitored:
Enabled—ACS evaluates an enabled rule, and when the rule conditions match the access request,
ACS applies the rule result.
Disabled—The rule appears in the rule table, but ACS skips this rule and does not evaluate it.
Monitor Only—ACS evaluates a monitored rule. If the rule conditions match the access request, ACS
creates a log record with information relating to the match.
ACS does not apply the result, and the processing continues to the following rules. Use this status during a running-in period for a rule to see whether it is needed.
Name Descriptive name. You can specify any name that describes the rule’s purpose. By default, ACS generates
rule name strings rule-number.
Conditions
Identity Group In this example, this is matching against one of the internal identity groups.
NDG: Location Location network device group. The two predefined NDGs are Location and Device Type.
Results
Shell Profile Used for device administration-type policies and contains permissions for TACACS+ shell access request,
such as Cisco IOS privilege level.
Hit Counts Displays the number of times a rule matched an incoming request since the last reset of the policy’s hit
counters. ACS counts hits for any monitored or enabled rule whose conditions all matched an incoming request. Hit counts for:
Enabled rules reflect the matches that occur when ACS processes requests.
Monitored rules reflect the counts that would result for these rules if they were enabled when ACS
processed the requests.
The primary server in an ACS deployment displays the hit counts, which represent the total matches for each rule across all servers in the deployment. On a secondary server, all hit counts in policy tables appear as zeroes.
The default rule specifies the policy result that ACS uses when no other rules exist, or when the attribute values in the access request do not match any rules.
ACS evaluates a set of rules in the first-match rule table by comparing the values of the attributes associated with the current access request with a set of conditions expressed in a rule.
If the attribute values do not match the conditions, ACS proceeds to the next rule in the rule table.
If the attribute values match the conditions, ACS applies the result that is specified for that rule, and
ignores all remaining rules.
If the attribute values do not match any of the conditions, ACS applies the result that is specified for
the policy default rule.
Related Topics
Policy Terminology, page 3-3
Policy Conditions, page 3-16
OL-26225-01
Policy Results, page 3-16
Exception Authorization Policy Rules, page 3-12
User Guide for Cisco Secure Access Control System 5.4
3-15

Authorization Profiles for Network Access

Policy Conditions
You can define simple conditions in rule tables based on attributes in:
Customizable conditions—You can create custom conditions based on protocol dictionaries and
identity dictionaries that ACS knows about. You define custom conditions in a policy rule page; you cannot define them as separate condition objects.
Standard conditions—You can use standard conditions, which are based on attributes that are always
available, such as device IP address, protocol, and username-related fields.
Related Topics
Policy Terminology, page 3-3
Policy Results, page 3-16
Exception Authorization Policy Rules, page 3-12
Policies and Identity Attributes, page 3-17
Policy Results
Chapter 3 ACS 5.x Policy Model
Policy rules include result information depending on the type of policy. You define policy results as independent shared objects; they are not related to user or user group definitions.
For example, the policy elements that define authorization and permission results for authorization policies include:
Identity source and failure options as results for identity policies. See Authorization Profiles for
Network Access, page 3-16.
Identity groups for group mapping. See Group Mapping Policy, page 3-11.
Authorization Profiles for Network Access, page 3-16.
Authorization Policy for Device Administration, page 3-11.
Security groups and security group access control lists (ACLs) for Cisco Security Group Access.
See ACS and Cisco Security Group Access, page 4-23.
For additional policy results, see Managing Authorizations and Permissions, page 9-17.
Related Topics
Policy Terminology, page 3-3
Policy Conditions, page 3-16
Exception Authorization Policy Rules, page 3-12
Policies and Identity Attributes, page 3-17
Authorization Profiles for Network Access
Authorization profiles define the set of RADIUS attributes that ACS returns to a user after successful authorization. The access authorization information includes authorization privileges and permissions, and other information such as downloadable ACLs.
User Guide for Cisco Secure Access Control System 5.4
3-16
OL-26225-01
Chapter 3 ACS 5.x Policy Model
You can define multiple authorization profiles as a network access policy result. In this way, you maintain a smaller number of authorization profiles, because you can use the authorization profiles in combination as rule results, rather than maintaining all the combinations themselves in individual profiles.
Processing Rules with Multiple Authorization Profiles
A session authorization policy can contain rules with multiple authorization profiles. The authorization profile contains general information (name and description) and RADIUS attributes only. When you use multiple authorization profiles, ACS merges these profiles into a single set of attributes. If a specific attribute appears:
In only one of the resulting authorization profiles, it is included in the authorization result.
Multiple times in the result profiles, ACS determines the attribute value for the authorization result
based on the attribute value in the profile that appears first in the result set.
For example, if a VLAN appears in the first profile, that takes precedence over a VLAN that appears in a 2nd or 3rd profile in the list.

Policies and Identity Attributes

Note If you are using multiple authorization profiles, make sure you order them in priority order.
The RADIUS attribute definitions in the protocol dictionary specify whether the attribute can appear only once in the response, or multiple times. In either case, ACS takes the values for any attribute from only one profile, irrespective of the number of times the values appear in the response. The only exception is the Cisco attribute value (AV) pair, which ACS takes from all profiles included in the result.
Related Topics
Policy Terminology, page 3-3
Authorization Policy for Device Administration, page 3-11
Policies and Identity Attributes
The identity stores contain identity attributes that you can use as part of policy conditions and in authorization results. When you create a policy, you can reference the identity attributes and user attributes.
This gives you more flexibility in mapping groups directly to permissions in authorization rules. When ACS processes a request for a user or host, the identity attributes are retrieved and can then be used in authorization policy conditions.
For example, if you are using the ACS internal users identity store, you can reference the identity group of the internal user or you can reference attributes of the internal user. (Note that ACS allows you to create additional custom attributes for the internal identity store records.)
If you are using an external Active Directory (AD), you can reference AD groups directly in authorization rules, and you can also reference AD user attributes directly in authorization rules. User attributes might include a user’s department or manager attribute.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
3-17

Policies and Network Device Groups

Related Topics
Managing Users and Identity Stores, page 8-1
Policy Terminology, page 3-3
Types of Policies, page 3-5
Policies and Network Device Groups
You can reference Network device groups (NDGs) as policy conditions. When the ACS receives a request for a device, the NDGs associated with that device are retrieved and compared against those in the policy table. With this method, you can group multiple devices and assign them the same policies. For example, you can group all devices in a specific location together and assign to them the same policy.
When ACS receives a request from a network device to access the network, it searches the network device repository to find an entry with a matching IP address. When a request arrives from a device that ACS identified using the IP address, ACS retrieves all NDGs associated with the device.
Related Topics
Managing Users and Identity Stores, page 8-1
Chapter 3 ACS 5.x Policy Model
Policy Terminology, page 3-3
Types of Policies, page 3-5

Example of a Rule-Based Policy

The following example illustrates how you can use policy elements to create policy rules.
A company divides its network into two regions, East and West, with network operations engineers at each site. They want to create an access policy that allows engineers:
Full access to the network devices in their region.
Read-only access to devices outside their region.
You can use the ACS 5.4 policy model to:
Define East and West network device groups, and map network devices to the appropriate group.
Define East and West identity groups, and map users (network engineers) to the appropriate group.
Define Full Access and Read Only authorization profiles.
Define Rules that allow each identity group full access or read-only access, depending on the
network device group location.
Previously, you had to create two user groups, one for each location of engineers, each with separate definitions for permissions, and so on. This definition would not provide the same amount of flexibility and granularity as in the rule-based model.
3-18
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 3 ACS 5.x Policy Model
Figure 3-2 illustrates what this policy rule table could look like.
Figure 3-2 Sample Rule-Based Policy

Flows for Configuring Services and Policies

Each row in the policy table represents a single rule.
Each rule, except for the last Default rule, contains two conditions, ID Group and Location, and a result, Authorization Profile. ID Group is an identity-based classification and Location is a nonidentity condition. The authorization profiles contain permissions for a session.
The ID Group, Location, and Authorization Profile are the policy elements.
Related Topics
Policy Terminology, page 3-3
Types of Policies, page 3-5
Access Services, page 3-6
Flows for Configuring Services and Policies, page 3-19
Flows for Configuring Services and Policies
Table 3 -8 describes the recommended basic flow for configuring services and policies; this flow does
not include user-defined conditions and attribute configurations. With this flow, you can use NDGs, identity groups, and compound conditions in rules.
Prerequisites
Before you configure services and policies, it is assumed you have done the following:
OL-26225-01
Added network resources to ACS and create network device groups. See Creating, Duplicating, and
Editing Network Device Groups, page 7-2 and Network Devices and AAA Clients, page 7-5.
User Guide for Cisco Secure Access Control System 5.4
3-19
Chapter 3 ACS 5.x Policy Model
Flows for Configuring Services and Policies
Added users to the internal ACS identity store or add external identity stores. See Creating Internal
Users, page 8-11, Managing Identity Attributes, page 8-7, or Creating External LDAP Identity Stores, page 8-26.
Table 3-8 Steps to Configure Services and Policies
Step Action Drawer in Web Interface
Step 1
Define policy results:
Authorizations and permissions for device administration—Shell
Policy Elements
profiles or command sets.
Authorizations and permissions for network access—Authorization
profile.
See:
Creating, Duplicating, and Editing a Shell Profile for Device
Administration, page 9-24
Creating, Duplicating, and Editing Command Sets for Device
Administration, page 9-29
Creating, Duplicating, and Editing Authorization Profiles for Network
Access, page 9-18
Step 2
(Optional) Define custom conditions to policy rules. You can complete this
— step before defining policy rules in Step 6, or you can define custom conditions while in the process of creating a rule. SeeCreating, Duplicating,
and Editing a Custom Session Condition, page 9-5.
Step 3
Create Access Services—Define only the structure and allowed protocols;
Access Policies you do not need to define the policies yet. See Creating, Duplicating, and
Editing Access Services, page 10-12.
Step 4
Add rules to Service Selection Policy to determine which access service to
Access Policies use for requests. See:
Step 5
Step 6
3-20
Customizing a Policy, page 10-4
Creating, Duplicating, and Editing Service Selection Rules, page 10-8
Define identity policy. Select the identity store or sequence you want to use to authenticate requests and obtain identity attributes. See Managing Users
and Identity Stores.
Create authorization rules:
Device administration—Shell/command authorization policy.
Network access—Session authorization policy.
See:
Customizing a Policy, page 10-4
Configuring Access Service Policies, page 10-22
User Guide for Cisco Secure Access Control System 5.4
Users and Identity Stores
Access Policies
OL-26225-01
Chapter 3 ACS 5.x Policy Model
Related Topics
Policy Terminology, page 3-3
Policy Conditions, page 3-16
Policy Results, page 3-16
Policies and Identity Attributes, page 3-17
Flows for Configuring Services and Policies
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
3-21
Flows for Configuring Services and Policies
Chapter 3 ACS 5.x Policy Model
3-22
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
CHA PTER
4

Common Scenarios Using ACS

Network control refers to the process of controlling access to a network. Traditionally a username and password was used to authenticate a user to a network. Now a days with the rapid technological advancements, the traditional method of managing network access with a username and a password is no longer sufficient.
The ways in which the users can access the network and what they can access have changed considerably. Hence, you must define complex and dynamic policies to control access to your network.
For example, earlier, a user was granted access to a network and authorized to perform certain actions based on the group that the user belonged to. Now, in addition to the group that the user belongs to, you must also consider other factors, such as whether:
The user is trying to gain access within or outside of work hours.
The user is attempting to gain access remotely.
The user has full or restricted access to the services and resources.
Apart from users, you also have devices that attempt to connect to your network.
When users and devices try to connect to your network through network access servers, such as wireless access points, 802.1x switches, and VPN servers, ACS authenticates and authorizes the request before a connection is established.
Authentication is the process of verifying the identity of the user or device that attempts to connect to a network. ACS receives identity proof from the user or device in the form of credentials. There are two different authentication methods:
Password-based authentication—A simpler and easier way of authenticating users. The user enters
a username and password. The server checks for the username and password in its internal or external databases and if found, grants access to the user. The level of access (authorization) is defined by the rules and conditions that you have created.
Certificate-based authentication—ACS supports certificate-based authentication with the use of the
Extensible Authentication Protocol-Transport Level Security (EAP-TLS) and Protected Extensible Authentication Protocol-Transport Level Security (PEAP-TLS), which uses certificates for server authentication by the client and for client authentication by the server.
Certificate-based authentication methods provide stronger security and are recommended when compared to password-based authentication methods.
Authorization determines the level of access that is granted to the user or device. The rule-based policy model in ACS 5.x allows you to define complex conditions in rules. ACS uses a set of rules (policy) to evaluate an access request and to return a decision.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
4-1

Overview of Device Administration

ACS organizes a sequence of independent policies into an access service, which is used to process an access request. You can create multiple access services to process different kinds of access requests; for example, for device administration or network access.
Cisco Secure Access Control System (ACS) allows you to centrally manage access to your network services and resources (including devices, such as IP phones, printers, and so on). ACS 5.4 is a policy-based access control system that allows you to create complex policy conditions and helps you to comply with the various Governmental regulations.
When you deploy ACS in your network, you must choose an appropriate authentication method that determines access to your network.
This chapter provides guidelines for some of the common scenarios. This chapter contains:
Overview of Device Administration, page 4-2
Password-Based Network Access, page 4-5
Certificate-Based Network Access, page 4-9
Agentless Network Access, page 4-12
VPN Remote Network Access, page 4-20
ACS and Cisco Security Group Access, page 4-23
RADIUS and TACACS+ Proxy Requests, page 4-29
Chapter 4 Common Scenarios Using ACS
Overview of Device Administration
Device administration allows ACS to control and audit the administration operations performed on network devices, by using these methods:
Session administration—A session authorization request to a network device elicits an ACS
response. The response includes a token that is interpreted by the network device which limits the commands that may be executed for the duration of a session. See Session Administration, page 4-3.
Command authorization—When an administrator issues operational commands on a network
device, ACS is queried to determine whether the administrator is authorized to issue the command. See Command Authorization, page 4-4.
Device administration results can be shell profiles or command sets.
Shell profiles allow a selection of attributes to be returned in the response to the authorization request for a session, with privilege level as the most commonly used attribute. Shell profiles contain common attributes that are used for shell access sessions and user-defined attributes that are used for other types of sessions.
ACS 5.4 allows you to create custom TACACS+ authorization services and attributes. You can define:
Any A-V pairs for these attributes.
The attributes as either optional or mandatory.
Multiple A-V pairs with the same name (multipart attributes).
ACS also supports task-specific predefined shell attributes. Using the TACACS+ shell profile, you can specify custom attributes to be returned in the shell authorization response. See TACACS+ Custom
Services and Attributes, page 4-5.
4-2
Command sets define the set of commands, and command arguments, that are permitted or denied. The received command, for which authorization is requested, is compared against commands in the available command sets that are contained in the authorization results.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
If a command is matched to a command set, the corresponding permit or deny setting for the command is retrieved. If multiple results are found in the rules that are matched, they are consolidated and a single permit or deny result for the command is returned, as described in these conditions:
If an explicit deny-always setting exists in any command set, the command is denied.
If no explicit deny-always setting exists in a command set, and any command set returns a permit
result, the command is permitted.
If either of the previous two conditions are not met, the command is denied.
You configure the permit and deny settings in the device administration rule table. You configure policy elements within a device administration rule table as conditions that are or not met. The rule table maps specific request conditions to device administration results through a matching process. The result of rule table processing is a shell profile or a command set, dependent on the type of request.
Session administration requests have a shell profile result, which contains values of attributes that are used in session provisioning. Command authorization requests have a command authorization result, which contains a list of command sets that are used to validate commands and arguments.
This model allows you to configure the administrator levels to have specific device administration capabilities. For example, you can assign a user the Network Device Administrator role which provides full access to device administration functions, while a Read Only Admin cannot perform administrative functions.
Overview of Device Administration
Session Administration
The following steps describe the flow for an administrator to establish a session (the ability to communicate) with a network device:
1. An administrator accesses a network device.
2. The network device sends a RADIUS or TACACS+ access request to ACS.
3. ACS uses an identity store (external LDAP, Active Directory, RSA, RADIUS Identity Server, or
internal ACS identity store) to validate the administrator’s credentials.
4. The RADIUS or TACACS+ response (accept or reject) is sent to the network device. The accept
response also contains the administrator’s maximum privilege level, which determines the level of administrator access for the duration of the session.
To configure a session administration policy (device administration rule table) to permit communication:
Step 1 Configure the TACACS+ protocol global settings and user authentication option. See Configuring
TACACS+ Settings, page 18-1.
Step 2 Configure network resources. See Network Devices and AAA Clients, page 7-5.
Step 3 Configure the users and identity stores. See Managing Internal Identity Stores, page 8-4 or Managing
External Identity Stores, page 8-22.
Step 4 Configure shell profiles according to your needs. See Creating, Duplicating, and Editing a Shell Profile
for Device Administration, page 9-24.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
4-3
Overview of Device Administration
Step 5 Configure an access service policy. See Access Service Policy Creation, page 10-4.
Step 6 Configure a service selection policy. See Service Selection Policy Creation, page 10-4.
Step 7 Configure an authorization policy (rule table). See Configuring a Session Authorization Policy for
Network Access, page 10-30.
Command Authorization
This topic describes the flow for an administrator to issue a command to a network device.
Note The device administration command flow is available for the TACACS+ protocol only.
1. An administrator issues a command to a network device.
2. The network device sends an access request to ACS.
3. ACS optionally uses an identity store (external Lightweight Directory Access Protocol [LDAP],
Active Directory, RADIUS Identity Server, or internal ACS identity store) to retrieve user attributes which are included in policy processing.
Chapter 4 Common Scenarios Using ACS
4. The response indicates whether the administrator is authorized to issue the command.
To configure a command authorization policy (device administration rule table) to allow an administrator to issue commands to a network device:
Step 1 Configure the TACACS+ protocol global settings and user authentication option. See Configuring
TACACS+ Settings, page 18-1.
Step 2 Configure network resources. See Network Devices and AAA Clients, page 7-5.
Step 3 Configure the users and identity stores. See Managing Internal Identity Stores, page 8-4 or Managing
External Identity Stores, page 8-22.
Step 4 Configure command sets according to your needs. See Creating, Duplicating, and Editing Command
Sets for Device Administration, page 9-29.
Step 5 Configure an access service policy. See Access Service Policy Creation, page 10-4.
Step 6 Configure a service selection policy. See Service Selection Policy Creation, page 10-4.
Step 7 Configure an authorization policy (rule table). See Configuring Shell/Command Authorization Policies
for Device Administration, page 10-35.
Related Topics
Network Devices and AAA Clients, page 7-5
Configuring System Administrators and Accounts, page 16-3
4-4
Managing Users and Identity Stores, page 8-1
Managing External Identity Stores, page 8-22
Managing Policy Conditions, page 9-1
Managing Access Policies, page 10-1
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
TACACS+ Custom Services and Attributes
This topic describes the configuration flow to define TACACS+ custom attributes and services.
Step 1 Create a custom TACACS+ condition to move to TACACS+ service on request. To do this:
a. Go to Policy Elements > Session Conditions > Custom and click Create.
b. Create a custom TACACS+ condition. See Creating, Duplicating, and Editing a Custom Session
Condition, page 9-5.
Step 2 Create an access service for Device Administration with the TACACS+ shell profile as the result. See
Configuring Shell/Command Authorization Policies for Device Administration, page 10-35.
Step 3 Create custom TACACS+ attributes. See Creating, Duplicating, and Editing a Shell Profile for Device
Administration, page 9-24.

Password-Based Network Access

Password-Based Network Access
This section contains the following topics:
Overview of Password-Based Network Access, page 4-5
Password-Based Network Access Configuration Flow, page 4-7
For more information about password-based protocols, see Appendix B, “Authentication in ACS 5.4.”
Overview of Password-Based Network Access
The use of a simple, unencrypted username and password is not considered a strong authentication mechanism but can be sufficient for low authorization or privilege levels such as Internet access.
Encryption reduces the risk of password capture on the network. Client and server access-control protocols, such as RADIUS encrypt passwords to prevent them from being captured within a network. However, RADIUS operates only between the AAA client and ACS. Before this point in the authentication process, unauthorized persons can obtain clear-text passwords, in these scenarios:
The communication between an end-user client dialing up over a phone line
An ISDN line terminating at a network-access server
Over a Telnet session between an end-user client and the hosting device
ACS supports various authentication methods for authentication against the various identity stores that ACS supports. For more information about authentication protocol identity store compatibility, see
Authentication Protocol and Identity Store Compatibility, page B-36.
Passwords can be processed by using these password-authentication protocols based on the version and type of security-control protocol used (for example, RADIUS), and the configuration of the AAA client and end-user client.
OL-26225-01
You can use different levels of security with ACS concurrently, for different requirements. Password Authentication Protocol (PAP) provides a basic security level. PAP provides a very basic level of security, but is simple and convenient for the client. MSCHAPv2 allows a higher level of security for encrypting passwords when communicating from an end-user client to the AAA client.
User Guide for Cisco Secure Access Control System 5.4
4-5
Password-Based Network Access
Note During password-based access (or certificate-based access), the user is not only authenticated but also
authorized according to the ACS configuration. And if NAS sends accounting requests, the user is also accounted.
ACS supports the following password-based authentication methods:
Plain RADIUS password authentication methods
RADIUS EAP-based password authentication methods
Chapter 4 Common Scenarios Using ACS
RADIUS-PAP
RADIUS-CHAP
RADIUS-MSCHAPv1
RADIUS-MSCHAPv2
PEAP-MSCHAPv2
PEAP-GTC
EAP-FAST-MSCHAPv2
EAP-FAST-GTC
EAP-MD5
LEAP
You must choose the authentication method based on the following factors:
The network access server—Wireless access points, 802.1X authenticating switches, VPN servers,
and so on.
The client computer and software—EAP supplicant, VPN client, and so on.
The identity store that is used to authenticate the user—Internal or External (AD, LDAP, RSA token
server, or RADIUS identity server).
Related Topics
Authentication in ACS 5.4, page B-1
Password-Based Network Access Configuration Flow, page 4-7
Network Devices and AAA Clients, page 7-5
Managing Access Policies, page 10-1
4-6
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
Password-Based Network Access Configuration Flow
This topic describes the end-to-end flow for password-based network access and lists the tasks that you must perform. The information about how to configure the tasks is located in the relevant task chapters.
To configure password-based network access:
Step 1 Configure network devices and AAA clients.
a. In the Network Devices and AAA Clients, page 7-5, configure the Authentication Setting as
RADIUS.
b. Enter the Shared Secret.
See Network Devices and AAA Clients, page 7-5, for more information.
Step 2 Configure the users and identity stores. For more information, see Chapter 8, “Managing Users and
Identity Stores.”
Step 3 Define policy conditions and authorization profiles. For more information, see Chapter 9, “Managing
Policy Elements.”
Step 4 Define an access service. For more information, see Creating, Duplicating, and Editing Access Services,
page 10-12.
Password-Based Network Access
a. Set the Access Service Type to Network Access.
b. Select one of the ACS-supported protocols in the Allowed Protocols Page and follow the steps in
the Action column in Tabl e 4-1.
Step 5 Add the access service to your service selection policy. For more information, see Creating, Duplicating,
and Editing Service Selection Rules, page 10-8.
Step 6 Return to the service that you created and in the Authorization Policy Page, define authorization rules.
For more information, see Configuring Access Service Policies, page 10-22.
Table 4-1 Network Access Authentication Protocols
Protocol Action
Process Host Lookup
In the Allowed Protocols Page, choose Process Host Lookup.
(MAB)
RADIUS PAP In the Allowed Protocols Page, choose Allow PAP/ASCII.
RADIUS CHAP In the Allowed Protocols Page, choose Allow CHAP.
RADIUS MSCHAPv1 In the Allowed Protocols Page, choose Allow MS-CHAPv1.
RADIUS MSCHAPv2 In the Allowed Protocols Page, choose Allow MS-CHAPv2.
EAP-MD5 In the Allowed Protocols Page, choose Allow EAP-MD5.
LEAP In the Allowed Protocols Page, choose Allow LEAP.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
4-7
Chapter 4 Common Scenarios Using ACS
Password-Based Network Access
Table 4-1 Network Access Authentication Protocols
Protocol Action
PEAP In the Allowed Protocols Page, choose PEAP. For the PEAP inner method, choose
EAP-MSCHAPv2 or EAP-GTC or both.
EAP-FAST
1. In the Allowed Protocols Page, choose Allow EAP-FAST to enable the EAP-FAST settings.
2. For the EAP-FAST inner method, choose EAP-MSCHAPv2 or EAP-GTC or both.
3. Select Allow Anonymous In-Band PAC Provisioning or Allow Authenticated In-Band PAC
Provisioning or both.
For Windows machine authentication against Microsoft AD and for the change password feature:
1. Click the Use PACS radio button. For details about PACs, see About PACs, page B-22.
2. Check Allow Authenticated In-Band PAC Provisioning.
3. Check Allow Machine Authentication.
4. Enter the Machine PAC Time to Live.
5. Check Enable Stateless Session Resume.
6. Enter the Authorization PAC Time to Live.
7. Check Preferred EAP Protocol to set the preferred protocol from the list.
For RADIUS, non-EAP authentication methods (RADIUS/PAP, RADIUS/CHAP, RADIUS/MS-CHAPv1, RADIUS/MSCHAPv2), and simple EAP methods (EAP-MD5 and LEAP), you need to configure only the protocol in the Allowed Protocols page as defined in Ta ble 4 - 1.
Some of the complex EAP protocols require additional configuration:
For EAP-TLS, you must also configure:
The EAP-TLS settings under System Administration > Configuration > EAP-TLS Settings.
A local server certificate under System Administration > Configuration > Local Server Certificates > Local Certificates.
A CA certificate under Users and Identity Stores > Certificate Authorities.
For PEAP, you must also configure:
The inner method in the Allowed Protocols page and specify whether password change is allowed.
The PEAP settings under System Administration > Configuration > PEAP Settings.
Local server certificates under System Administration > Configuration > Local Server Certificates > Local Certificates.
For EAP-FAST, you must also configure:
The inner method in the Allowed Protocols page and specify whether password change is allowed.
4-8
Whether or not to use PACs and if you choose to use PACs, you must also specify how to allow in-band PAC provisioning.
The EAP-FAST settings under System Administration > Configuration > EAP-FAST > Settings.
A local server certificate under System Administration > Configuration > Local Server Certificates > Local Certificates (Only if you enable authenticated PAC provisioning).
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
Related Topics
Authentication in ACS 5.4, page B-1
Network Devices and AAA Clients, page 7-5
Managing Access Policies, page 10-1
Creating, Duplicating, and Editing Access Services, page 10-12
About PACs, page B-22

Certificate-Based Network Access

This section contains the following topics:
Overview of Certificate-Based Network Access, page 4-9
Using Certificates in ACS, page 4-10
Certificate-Based Network Access, page 4-10
For more information about certificate-based protocols, see Appendix B, “Authentication in ACS 5.4.”
Certificate-Based Network Access
Overview of Certificate-Based Network Access
Before using EAP-TLS, you must install a computer certificate on ACS. The installed computer certificate must be issued from a CA that can follow a certificate chain to a root CA that the access client trusts.
Additionally, in order for ACS to validate the user or computer certificate of the access client, you must install the certificate of the root CA that issued the user or computer certificate to the access clients.
ACS supports certificate-based network access through the EAP-TLS protocol, which uses certificates for server authentication by the client and for client authentication by the server.
Other protocols, such as PEAP or the authenticated-provisioning mode of EAP-FAST also make use of certificates for server authentication by the client, but they cannot be considered certificate-based network access because the server does not use the certificates for client authentication.
ACS Public Key Infrastructure (PKI) certificate-based authentication is based on X509 certificate identification. The entity which identifies itself with a certificate holds a private-key that correlates to the public key stored in the certificate.
A certificate can be self-signed or signed by another CA. A hierarchy of certificates can be made to form trust relations of each entity to its CA. The trusted root CA is the entity that signs the certificate of all other CAs and eventually signs each certificate in its hierarchy.
ACS identifies itself with its own certificate. ACS supports a certificate trust list (CTL) for authorizing connection certificates. ACS also supports complex hierarchies that authorize an identity certificate when all of the chain certificates are presented to it.
ACS supports several RSA key sizes used in the certificate that are 512, 1024, 2048, or 4096 bits. Other key sizes may be used. ACS 5.4 supports RSA. ACS does not support the Digital Signature Algorithm (DSA). However, in some use cases, ACS will not prevent DSA cipher suites from being used for certificate-based authentication.
OL-26225-01
All certificates that are used for network access authentication must meet the requirements for X.509 certificates and work for connections that use SSL/TLS. After this minimum requirement is met, the client and server certificates have additional requirements.
User Guide for Cisco Secure Access Control System 5.4
4-9
Certificate-Based Network Access
You can configure two types of certificates in ACS:
Trust certificate—Also known as CA certificate. Used to form CTL trust hierarchy for verification
of remote certificates.
Local certificate—Also known as local server certificate. The client uses the local certificate with
various protocols to authenticate the ACS server. This certificate is maintained in association with its private key, which is used to prove possession of the certificate.
Note During certificate-based access (or password-based access), the user is not only authenticated but also
authorized according to the ACS configuration. And if NAS sends accounting requests, the user is also accounted.
Related Topics
Configuring CA Certificates, page 8-71
Configuring Local Server Certificates, page 18-14
Using Certificates in ACS, page 4-10
Chapter 4 Common Scenarios Using ACS
Using Certificates in ACS
The three use cases for certificates in ACS 5.4 are:
Certificate-Based Network Access, page 4-10
Authorizing the ACS Web Interface from Your Browser Using a Certificate, page 4-11
Validating an LDAP Secure Authentication Connection, page 4-12
Certificate-Based Network Access
For TLS- related EAP and PEAP protocols, you must set up a server certificate from the local certificate store and a trust list certificate to authenticate the client. You can choose the trust certificate from any of the certificates in the local certificate store.
To use EAP-TLS or PEAP (EAP-TLS), you must obtain and install trust certificates. The information about how to perform the tasks is located in the relevant task chapters.
Before you Begin:
Set up the server by configuring:
EAP-TLS or PEAP (EAP-TLS)
The local certificate. See Configuring Local Server Certificates, page 18-14.
To configure certificate-based network access for EAP-TLS or PEAP (EAP-TLS):
4-10
Step 1 Configure the trust certificate list. See Configuring CA Certificates, page 8-71, for more information.
Step 2 Configure the LDAP external identity store. You might want to do this to verify the certificate against a
certificate stored in LDAP. See Creating External LDAP Identity Stores, page 8-26, for details.
Step 3 Set up the Certificate Authentication Profile. See Configuring Certificate Authentication Profiles,
page 8-75, for details.
Step 4 Configure policy elements. See Managing Policy Conditions, page 9-1, for more information.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
You can create custom conditions to use the certificate’s attributes as a policy condition. See Creating,
Duplicating, and Editing a Custom Session Condition, page 9-5, for details.
Step 5 Create an access service. See Configuring Access Services, page 10-11, for more information.
Step 6 In the Allowed Protocols Page, choose EAP-TLS or PEAP (EAP-TLS) as inner method.
Step 7 Configure identity and authorization policies for the access service. See Configuring Access Service
Policies, page 10-22, for details.
Note When you create rules for the identity policy, the result may be the Certificate Authentication
Profile or an Identity Sequence. See Viewing Identity Policies, page 10-22, for more information.
Step 8 Configure the Authorization Policies. See Configuring a Session Authorization Policy for Network
Access, page 10-30.
Step 9 Configure the Service Selection Policy. See Configuring the Service Selection Policy, page 10-5.
Certificate-Based Network Access
Table 4-2 Network Access Authentication Protocols
Protocol Action
EAP-TLS In the Allowed Protocols Page, choose Allow EAP-TLS to enable the EAP-TLS settings.
Enable Stateless Session resume—Check this check box to enable the Stateless Session
Resume feature per Access service. This feature enables you to configure the following options:
Proactive Session Ticket update—Enter the value as a percentage to indicate how much of the Time to Live must elapse before the session ticket is updated. For example, the session ticket update occurs after 10 percent of the Time to Live has expired, if you enter the value 10.
Session ticket Time to Live—Enter the equivalent maximum value in days, weeks, months, and years, using a positive integer.
PEAP In the Allowed Protocols Page, choose PEAP. For the PEAP inner method, choose EAP-TLS or
PEAP Cryptobinding TLV.
Related Topics
Configuring Local Server Certificates, page 18-14
Configuring CA Certificates, page 8-71
Authentication in ACS 5.4, page B-1
Overview of EAP-TLS, page B-6
Authorizing the ACS Web Interface from Your Browser Using a Certificate
You use the HTTPS certificate-based authentication to connect to ACS with your browser. The Local Server Certificate in ACS is used to authorize the ACS web interface from your browser. ACS does not support browser authentication (mutual authentication is not supported).
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
4-11

Agentless Network Access

A default Local Server Certificate is installed on ACS so that you can connect to ACS with your browser. The default certificate is a self-signed certificate and cannot be modified during installation.
Related Topics
Using Certificates in ACS, page 4-10
Configuring Local Server Certificates, page 18-14
Validating an LDAP Secure Authentication Connection
You can define a secure authentication connection for the LDAP external identity store, by using a CA certificate to validate the connection.
To validate an LDAP secure authentication connection using a certificate:
Step 1 Configure an LDAP external identity store. See Creating External LDAP Identity Stores, page 8-26.
Step 2 In the LDAP Server Connection page, check Use Secure Authentication.
Step 3 Select Root CA from the drop-down menu and continue with the LDAP configuration for ACS.
Chapter 4 Common Scenarios Using ACS
Related Topics
Using Certificates in ACS, page 4-10
Configuring Local Server Certificates, page 18-14
Managing External Identity Stores, page 8-22
Agentless Network Access
This section contains the following topics:
Overview of Agentless Network Access, page 4-12
Host Lookup, page 4-13
Agentless Network Access Flow, page 4-16
For more information about protocols used for network access, see Authentication in ACS 5.4, page B-1.
Overview of Agentless Network Access
Agentless network access refers to the mechanisms used to perform port-based authentication and authorization in cases where the host device does not have the appropriate agent software.
For example, a host device, where there is no 802.1x supplicant or a host device, where the supplicant is disabled.
802.1x must be enabled on the host device and on the switch to which the device connects. If a host/device without an 802.1x supplicant attempts to connect to a port that is enabled for 802.1x, it will be subjected to the default security policy.
4-12
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
The default security policy says that 802.1x authentication must succeed before access to the network is granted. Therefore, by default, non-802.1x-capable devices cannot get access to an 802.1x-protected network.
Although many devices increasingly support 802.1x, there will always be devices that require network connectivity, but do not, or cannot, support 802.1x. Examples of such devices include network printers, badge readers, and legacy servers. You must make some provision for these devices.
Cisco provides two features to accommodate non-802.1x devices. For example, MAC Authentication Bypass (Host Lookup) and the Guest VLAN access by using web authentication.
ACS 5.4 supports the Host Lookup fallback mechanism when there is no 802.1x supplicant. After 802.1x times out on a port, the port can move to an open state if Host Lookup is configured and succeeds.
Related Topics
Host Lookup, page 4-13
Agentless Network Access Flow, page 4-16
Host Lookup
Agentless Network Access
ACS uses Host Lookup as the validation method when an identity cannot be authenticated according to credentials (for example, password or certificate), and ACS needs to validate the identity by doing a lookup in the identity stores.
An example for using host lookup is when a network device is configured to request MAC Authentication Bypass (MAB). This can happen after 802.1x times out on a port or if the port is explicitly configured to perform authentication bypass. When MAB is implemented, the host connects to the network access device.
The device detects the absence of the appropriate software agent on the host and determines that it must identify the host according to its MAC address. The device sends a RADIUS request with service-type=10 and the MAC address of the host to ACS in the calling-station-id attribute.
Some devices might be configured to implement the MAB request by sending PAP or EAP-MD5 authentication with the MAC address of the host in the user name, user password, and CallingStationID attributes, but without the service-type=10 attribute.
While most use cases for host lookup are to obtain a MAC address, there are other scenarios where a device requests to validate a different parameter, and the calling-station-id attribute contains this value instead of the MAC address. For example, IP address in layer 3 use cases).
Table 4 -3 describes the RADIUS parameters required for host lookup use cases.
Table 4-3 RADIUS Attributes for Host Lookup Use Cases
Use Cases
Attribute
RADIUS::ServiceType Call check (with PAP or
PAP 802.1x EAP-MD5
EAP-MD5)
RADIUS::UserName MAC address Any value (usually the
MAC address
MAC address)
RADIUS::UserPassword MAC address Any value (usually the
MAC address
MAC address)
RADIUS::CallingStationID MAC address MAC address MAC address
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
4-13
Agentless Network Access
ACS supports host lookup for the following identity stores:
Internal hosts
External LDAP
Internal users
Active Directory
You can access the Active Directory via the LDAP API.
You can use the Internal Users identity store for Host Lookup in cases where the relevant host is already listed in the Internal Users identity store, and you prefer not to move the data to the Internal Hosts identity store.
ACS uses the MAC format (XX-XX-XX-XX-XX-XX) and no other conversions are possible. To search the Internal Users identity store using the User-Name attribute (for example, xx:xx:xx:xx:xx:xx) you should leave the Process Host Lookup option unchecked. ACS will handle the request as a PAP request.
When MAC address authentication over PAP or EAP-MD5 is not detected according to the Host Lookup configuration, authentication and authorization occur like regular user authentication over PAP or EAP-MD5. You can use any identity store that supports these authentication protocols. ACS uses the MAC address format as presented in the RADIUS User-Name attribute.
Chapter 4 Common Scenarios Using ACS
Related Topics
Creating an Access Service for Host Lookup, page 4-18
Viewing and Performing Bulk Operations for Internal Identity Store Hosts, page 8-18
Managing Users and Identity Stores, page 8-1
Authentication with Call Check, page 4-14
Authentication with Call Check
When ACS identifies a network access request with the call check attribute as Host Lookup (RADIUS::ServiceType = 10), ACS authenticates (validates) and authorizes the host by looking up the value in the Calling-Station-ID attribute (for example, the MAC address) in the configured identity store according to the authentication policy.
When ACS receives a RADIUS message, it performs basic parsing and validation, and then checks if the Call Check attribute, RADIUS ServiceType(6), is equal to the value 10. If the RADIUS ServiceType is equal to 10, ACS sets the system dictionary attribute UseCase to a value of Host Lookup.
In the ACS packet processing flow, the detection of Host Lookup according to Call Check service-type is done before the service selection policy. It is possible to use the condition UseCase equals Host Lookup in the service selection policy.
Initially, when RADIUS requests are processed, the RADIUS User-Name attribute is copied to the System UserName attribute. When the RADIUS Service-Type equals 10, the RADIUS Calling-Station-ID attribute is copied to the System User-Name attribute, and it overrides the RADIUS User-Name attribute value.
4-14
ACS supports four MAC address formats:
Six groups of two hexadecimal digits, separated by hyphens—01-23-45-67-89-AB
Six groups of two hexadecimal digits, separated by colons—01:23:45:67:89:AB
Three groups of four hexadecimal digits, separated by dots—0123.4567.89AB
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
Twelve consecutive hexadecimal digits without any separators—0123456789AB
If the Calling-Station-ID attribute is one of the four supported MAC address formats above, ACS copies it to the User-Name attribute with the format of XX-XX-XX-XX-XX-XX. If the MAC address is in a format other than one of the four above, ACS copies the string as is.
Process Service-Type Call Check
You may not want to copy the CallingStationID attribute value to the System UserName attribute value. When the Process Host Lookup option is checked, ACS uses the System UserName attribute that was copied from the RADIUS User-Name attribute.
When the Process Host Lookup option is not checked, ACS ignores the HostLookup field and uses the original value of the System UserName attribute for authentication and authorization. The request processing continues according to the message protocol. For example, according to the RADIUS User-Name and User-Password attributes for PAP.
For setting the Process Host Lookup option, see Creating an Access Service for Host Lookup, page 4-18.
PAP/EAP-MD5 Authentication
Agentless Network Access
When a device is configured to use PAP or EAP-MD5 for MAC address authentication, you can configure ACS to detect the request as a Host Lookup request, within the network access service. The device sends the request with the host's MAC address in the User-Name, User-Password, and Calling-Station-ID attributes.
If you do not configure ACS to detect Host Lookup, the access request is handled as a regular PAP, or EAP-MD5 authentication request.
If you check the Process HostLookup field and select PAP or EAP-MD5, ACS places the HostLookup value in the ACS::UseCase attribute. The User-Password attribute is ignored for the detection algorithm.
ACS follows the authentication process as if the request is using the call check attribute, and processes it as a Host Lookup (Service-Type=10) request. The RADIUS dictionary attribute ACS::UseCase is set to the value of HostLookup.
The Detect Host Lookup option for PAP and EAP-MD5 MAC authentication is done after the service selection policy. If a service selection rule is configured to match ACS::UseCase = Host Lookup, the request falls into the Host Lookup category.
If ACS is not configured to detect PAP or EAP-MD5 authentications as MAC authentication flows, ACS will not consider the Detect Host Lookup option. These requests are handled like a regular user request for authentication, and looks for the username and password in the selected identity store.
Related Topics
Creating an Access Service for Host Lookup, page 4-18
Managing Access Policies, page 10-1
OL-26225-01
Viewing and Performing Bulk Operations for Internal Identity Store Hosts, page 8-18
Managing Users and Identity Stores, page 8-1
User Guide for Cisco Secure Access Control System 5.4
4-15
Agentless Network Access
Agentless Network Access Flow
This topic describes the end-to-end flow for agentless network access and lists the tasks that you must perform. The information about how to configure the tasks is located in the relevant task chapters.
Perform these tasks in the order listed to configure agentless network access in ACS:
Step 1 Configure network devices and AAA clients.
This is the general task to configure network devices and AAA clients in ACS and is not specific to agentless network access. Select Network Resources > Network Devices and AAA Clients and click Create. See Network Devices and AAA Clients, page 7-5.
Step 2 Configure an identity store for internal hosts.
Configure an internal identity store. See Adding a Host to an Internal Identity Store, page 4-17
or
Configure an external identity store. See Configuring an LDAP External Identity Store for Host
Lookup, page 4-17.
For more information, see Chapter 8, “Managing Users and Identity Stores.”
Chapter 4 Common Scenarios Using ACS
Step 3 Configure the identity group. See Configuring an Identity Group for Host Lookup Network Access
Requests, page 4-18.
For more information, see Chapter 8, “Managing Users and Identity Stores.”
Step 4 Define policy elements and authorization profiles for Host Lookup requests.
For more information, see Chapter 9, “Managing Policy Elements.”
Step 5 Create an empty service by defining an access service for Host Lookup. For more information, see
Creating an Access Service for Host Lookup, page 4-18.
Step 6 Return to the service that you created:
a. Define an identity policy. For more information, see Configuring an Identity Policy for Host Lookup
Requests, page 4-19.
ACS has the option to look for host MAC addresses in multiple identity stores.
For example, MAC addresses can be in the Internal Hosts identity store, in one of the configured LDAP identity stores, or in the Internal Users identity store.
The MAC address lookup may be in one of the configured identity stores, and the MAC attributes may be fetched from a different identity store that you configured in the identity sequence.
You can configure ACS to continue processing a Host Lookup request even if the MAC address was not found in the identity store. An administrator can define an authorization policy based on the event, regardless of whether or not the MAC address was found.
The ACS::UseCase attribute is available for selection in the Authentication Policy, but is not mandatory for Host Lookup support.
4-16
b. Return to the service that you created.
c. Define an authorization policy. For more information, see Configuring an Authorization Policy for
Host Lookup Requests, page 4-20.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
Step 7 Define the service selection.
Step 8 Add the access service to your service selection policy. For more information, see Creating, Duplicating,
and Editing Service Selection Rules, page 10-8.
Related Topics
Managing Users and Identity Stores, page 8-1
Managing Access Policies, page 10-1
Adding a Host to an Internal Identity Store
To configure an internal identity store for Host Lookup:
Step 1 Choose Users and Identity Store > Internal Identity Stores > Hosts and click Create.
See Viewing and Performing Bulk Operations for Internal Identity Store Hosts, page 8-18, or more information.
Agentless Network Access
Step 2 Fill in the fields as described in the Users and Identity Stores > Internal Identity Store > Hosts >
Create Page.
Step 3 Click Submit.
Previous Step:
Network Devices and AAA Clients, page 7-5
Next Step:
Configuring an Identity Group for Host Lookup Network Access Requests, page 4-18
Configuring an LDAP External Identity Store for Host Lookup
To configure an LDAP external identity store for Host Lookup:
Step 1 Choose Users and Identity Stores > External Identity Stores > LDAP and click Create. See Creating
External LDAP Identity Stores, page 8-26, for more information.
Step 2 Follow the steps for creating an LDAP database.
In the LDAP: Directory Organization page, choose the MAC address format.
The format you choose represents the way MAC addresses are stored in the LDAP external identity store.
Step 3 Click Finish.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
4-17
Chapter 4 Common Scenarios Using ACS
Agentless Network Access
Previous Step:
Network Devices and AAA Clients, page 7-5
Next Step:
Configuring an Identity Group for Host Lookup Network Access Requests, page 4-18
Related Topics
Creating External LDAP Identity Stores, page 8-26
Deleting External LDAP Identity Stores, page 8-33
Configuring an Identity Group for Host Lookup Network Access Requests
To configure an identity group for Host Lookup network access requests:
Step 1 Choose Users and Identity Store > Identity Groups> and click Create.
See Managing Identity Attributes, page 8-7, for more information.
Step 2 Fill in the fields as required.
The identity group may be any agentless device, such as a printer or phone.
Step 3 Click Submit.
Previous Steps:
Adding a Host to an Internal Identity Store, page 4-17
Configuring an LDAP External Identity Store for Host Lookup, page 4-17
Next Step:
Creating an Access Service for Host Lookup, page 4-18
Related Topic
Managing Identity Attributes, page 8-7
Creating an Access Service for Host Lookup
You create an access service and then enable agentless host processing.
To create an access service for Host Lookup:
4-18
Step 1 Choose Access Policies > Access Service, and click Create. See Configuring Access Services,
page 10-11, for more information.
Step 2 Fill in the fields as described in the Access Service Properties—General page:
a. In the Service Structure section, choose User Selected Policy Structure.
b. Set the Access Service Type to Network Access and define the policy structure.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
c. Select Network Access, and check Identity and Authorization.
The group mapping and External Policy options are optional.
d. Make sure you select Process Host Lookup.
If you want ACS to detect PAP or EAP-MD5 authentications for MAC addresses (see
PAP/EAP-MD5 Authentication, page 4-15), and process it like it is a Host Lookup request (for
example, MAB requests), complete the following steps:
e. Select one of the ACS supported protocols for MAB in the Allowed Protocols Page (EAP-MD5 or
PAP ).
f. Check Detect PAP/EAP-MD5 as Host Lookup.
Related Topics
Managing Access Policies, page 10-1
Authentication in ACS 5.4, page B-1
Authentication with Call Check, page 4-14
Agentless Network Access
Process Service-Type Call Check, page 4-15
Configuring an Identity Policy for Host Lookup Requests
To configure an identity policy for Host Lookup requests:
Step 1 Choose Access Policies > Access Services > <access_servicename> Identity.
See Viewing Identity Policies, page 10-22, for details.
Step 2 Select Customize to customize the authorization policy conditions.
A list of conditions appears. This list includes identity attributes, system conditions, and custom conditions. See Customizing a Policy, page 10-4, for more information.
Step 3 Select Use Case from the Ava il ab le customized conditions and move it to the Selected conditions.
Step 4 In the Identity Policy Page, click Create.
a. Enter a Name for the rule.
b. In the Conditions area, check Use Case, then check whether the value should or should not match.
c. Select Host Lookup and click OK.
This attribute selection ensures that while processing the access request, ACS will look for the host and not for an IP address.
d. Select any of the identity stores that support host lookup as your Identity Source.
e. Click OK.
OL-26225-01
Step 5 Click Save Changes.
Related Topic
Managing Access Policies, page 10-1
User Guide for Cisco Secure Access Control System 5.4
4-19

VPN Remote Network Access

Configuring an Authorization Policy for Host Lookup Requests
To configure an authorization policy for Host Lookup requests:
Step 1 Choose Access Policies > Access Services > <access_servicename> Authorization.
See Configuring a Session Authorization Policy for Network Access, page 10-30, for details.
Step 2 Select Customize to customize the authorization policy conditions.
A list of conditions appears. This list includes identity attributes, system conditions, and custom conditions.
See Customizing a Policy, page 10-4, for more information.
Step 3 Select Use Case from the Ava il ab le customized conditions and move it to the Selected conditions.
Step 4 Select Authorization Profiles from the customized results and move it to the Selected conditions and
click OK.
Step 5 In the Authorization Policy Page, click Create.
a. Enter a Name for the rule.
Chapter 4 Common Scenarios Using ACS
b. In the Conditions area, check Use Case, then check whether the value should or should not match.
c. Select Host Lookup and click OK.
This attribute selection ensures that while processing the access request, ACS will look for the host and not for an IP address.
d. Select an Authorization Profile from the authorization profiles and move it to the Selected results
column
e. Click OK.
Step 6 Click Save Changes.
Related Topic
Managing Access Policies, page 10-1
VPN Remote Network Access
A remote access Virtual Private Network (VPN) allows you to connect securely to a private company network from a public Internet. You could be accessing your company’s network from home or elsewhere. The VPN is connected to your company’s perimeter network (DMZ). A VPN gateway can manage simultaneous VPN connections.
4-20
Related Topics
Supported Authentication Protocols, page 4-21
Supported Identity Stores, page 4-21
Supported VPN Network Access Servers, page 4-22
Supported VPN Clients, page 4-22
Configuring VPN Remote Access Service, page 4-22
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
Supported Authentication Protocols
ACS 5.4 supports the following protocols for inner authentication inside the VPN tunnel:
RADIUS/PAP
RADIUS/CHAP
RADIUS/MS-CHAPv1
RADIUS/MS-CHAPv2
With the use of MS-CHAPv1 or MS-CHAPv2 protocols, ACS can generate MPPE keys that is used for encryption of the tunnel that is created.
Related Topics
VPN Remote Network Access, page 4-20
Supported Identity Stores, page 4-21
Supported VPN Network Access Servers, page 4-22
Supported VPN Clients, page 4-22
Configuring VPN Remote Access Service, page 4-22
VPN Remote Network Access
Supported Identity Stores
ACS can perform VPN authentication against the following identity stores:
ACS internal identity store—RADIUS/PAP, RADIUS/CHAP, RADIUS/MS-CHAP-v1, and
RADIUS/MS-CHAP-v2
Active Directory—RADIUS/PAP, RADIUS/MS-CHAP-v1, and RADIUS/MS-CHAP-v2
LDAP—RADIUS/PAP
RSA SecurID Server—RADIUS/PAP
RADIUS Token Server—RADIUS/PAP (dynamic OTP)
Related Topics
VPN Remote Network Access, page 4-20
Supported Authentication Protocols, page 4-21
Supported VPN Network Access Servers, page 4-22
Supported VPN Clients, page 4-22
Configuring VPN Remote Access Service, page 4-22
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
4-21
VPN Remote Network Access
Supported VPN Network Access Servers
ACS 5.4 supports the following VPN network access servers:
Cisco ASA 5500 Series
Cisco VPN 3000 Series
Related Topics
VPN Remote Network Access, page 4-20
Supported Authentication Protocols, page 4-21
Supported Identity Stores, page 4-21
Supported VPN Clients, page 4-22
Configuring VPN Remote Access Service, page 4-22
Supported VPN Clients
Chapter 4 Common Scenarios Using ACS
ACS 5.4 supports the following VPN clients:
Cisco VPN Client 5.0 Series
Cisco Clientless SSL VPN (WEBVPN)
Cisco AnyConnect VPN client 2.3 Series
MS VPN client
Related Topics
VPN Remote Network Access, page 4-20
Supported Authentication Protocols, page 4-21
Supported Identity Stores, page 4-21
Supported VPN Network Access Servers, page 4-22
Configuring VPN Remote Access Service, page 4-22
Configuring VPN Remote Access Service
To configure a VPN remote access service:
Step 1 Configure the VPN protocols in the Allowed Protocols page of the default network access service. For
more information, see Configuring Access Service Allowed Protocols, page 10-16.
4-22
Step 2 Create an authorization profile for VPN by selecting the dictionary type, and the Tunneling-Protocols
attribute type and value. For more information, see Specifying RADIUS Attributes in Authorization
Profiles, page 9-22.
Step 3 Click Submit to create the VPN authorization profile.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
Related Topics
VPN Remote Network Access, page 4-20
Supported Authentication Protocols, page 4-21
Supported Identity Stores, page 4-21
Supported VPN Network Access Servers, page 4-22
Supported VPN Clients, page 4-22
Configuring VPN Remote Access Service, page 4-22

ACS and Cisco Security Group Access

Note ACS requires an additional feature license to enable Security Group Access capabilities.
Cisco Security Group Access, hereafter referred to as Security Group Access, is a new security architecture for Cisco products. You can use Security Group Access to create a trustworthy network fabric that provides confidentiality, message authentication, integrity, and antireplay protection on network traffic.
ACS and Cisco Security Group Access
Security Group Access requires that all network devices have an established identity, and must be authenticated and authorized before they start operating in the network. This precaution prevents the attachment of rogue network devices in a secure network.
Until now, ACS authenticated only users and hosts to grant them access to the network. With Security Group Access, ACS also authenticates devices such as routers and switches by using a name and password. Any device with a Network Interface Card (NIC) must authenticate itself or stay out of the trusted network.
Security is improved and device management is simplified since devices can be identified by their name rather than IP address.
Note The Cisco Catalyst 6500 running Cisco IOS 12.2(33) SXI and DataCenter 3.0 (Nexus 7000) NX-OS
4.0.3 devices support Security Group Access. The Cisco Catalyst 6500 supports Security Group Tags (SGTs); however, it does not support Security Group Access Control Lists (SGACLs) in this release.
To configure ACS for Security Group Access:
1. Add users.
This is the general task to add users in ACS and is not specific to Security Group Access. Choose Users and Identity Stores > Internal Identity Store > Users and click Create. See Creating
Internal Users, page 8-11, for more information.
2. Adding Devices for Security Group Access.
3. Creating Security Groups.
OL-26225-01
4. Creating SGACLs.
5. Configuring an NDAC Policy.
User Guide for Cisco Secure Access Control System 5.4
4-23
ACS and Cisco Security Group Access
6. Configuring EAP-FAST Settings for Security Group Access.
7. Creating an Access Service for Security Group Access.
8. Creating an Endpoint Admission Control Policy.
9. Creating an Egress Policy.
10. Creating a Default Policy.
Adding Devices for Security Group Access
The RADIUS protocol requires a shared secret between the AAA client and the server. In ACS, RADIUS requests are processed only if they arrive from a known AAA client. You must configure the AAA client in ACS with a shared secret.
The Security Group Access device should be configured with the same shared secret. In Security Group Access, every device must be able to act as a AAA client for new devices that join the secured network.
All the Security Group Access devices possess a Protected Access Credential (PAC) as part of the EAP Flexible Authentication via Secured Tunnel (EAP-FAST) protocol. A PAC is used to identify the AAA client. The RADIUS shared secret can be derived from the PAC.
To add a network device:
Chapter 4 Common Scenarios Using ACS
Step 1 Choose Network Resources > Network Devices and AAA Client and click Create. See Network
Devices and AAA Clients, page 7-5, for more information.
Step 2 Fill in the fields in the Network Devices and AAA clients pages:
To add a device as a seed Security Group Access device, check RADIUS and Security Group
Access, or to add a device as a Security Group Access client, check Security Group Access only.
If you add the device as a RADIUS client, enter the IP Address and the RADIUS/Shared Secret.
If you add the device as a Security Group Access device, fill in the fields in the Security Group Access section.
You can check Advanced Settings to display advanced settings for the Security Group Access
device configuration and modify the default settings.
The location or device type can be used as a condition to configure an NDAC policy rule.
Step 3 Click Submit.
Creating Security Groups
Security Group Access uses security groups for tagging packets at ingress to allow filtering later on at Egress. The product of the security group is the security group tag, a 4-byte string ID that is sent to the network device.
The web interface displays the decimal and hexadecimal representation. The SGT is unique. When you edit a security group you can modify the name, however, you cannot modify the SGT ID.
4-24
The security group names Unknown and Any are reserved. The reserved names are used in the Egress policy matrix. The generation ID changes when the Egress policy is modified.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
Devices consider only the SGT value; the name and description of a security group are a management convenience and are not conveyed to the devices. Therefore, changing the name or description of the security group does not affect the generation ID of an SGT.
To create a security group:
Step 1 Choose Policy Elements > Authorizations and Permissions > Network Access > Security Groups
and click Create.
Step 2 Fill in the fields as described in the Configuring Security Group Access Control Lists, page 9-34.
Tip When you edit a security group, the security group tag and the generation ID are visible.
Step 3 Click Submit.
Creating SGACLs
ACS and Cisco Security Group Access
Security Group Access Control Lists (SGACLs) are similar to standard IP-based ACLs, in that you can specify whether to allow or deny communications down to the transport protocol; for example, TCP, User Datagram Protocol (UDP), and the ports; FTP; or Secure Shell Protocol (SSH).
You can create SGACLs that can be applied to communications between security groups. You apply Security Group Access policy administration in ACS by configuring these SGACLs to the intersection of source and destination security groups through a customizable Egress matrix view, or individual source and destination security group pairs.
To create an SGACL:
Step 1 Choose Policy Elements > Authorizations and Permissions > Named Permissions Objects >
Security Group ACLs. then click Create.
Step 2 Fill in the fields as described in the Configuring Security Group Access Control Lists, page 9-34.
Step 3 Click Submit.
Configuring an NDAC Policy
The Network Device Admission Control (NDAC) policy defines which security group is sent to the device. When you configure the NDAC policy, you create rules with previously defined conditions, for example, NDGs.
OL-26225-01
The NDAC policy is a single service, and it contains a single policy with one or more rules. Since the same policy is used for setting responses for authentication, peer authorization, and environment requests, the same SGT is returned for all request types when they apply to the same device.
Note You cannot add the NDAC policy as a service in the service selection policy; however, the NDAC policy
is automatically applied to Security Group Access devices.
User Guide for Cisco Secure Access Control System 5.4
4-25
Chapter 4 Common Scenarios Using ACS
ACS and Cisco Security Group Access
To configure an NDAC policy for a device:
Step 1 Choose Access Policies > Security Group Access Control > Security Group Access > Network
Device Access > Authorization Policy.
Step 2 Click Customize to select which conditions to use in the NDAC policy rules.
The Default Rule provides a default rule when no rules match or there are no rules defined. The default security group tag for the Default Rule result is Unknown.
Step 3 Click Create to create a new rule.
Step 4 Fill in the fields in the NDAC Policy Properties page.
Step 5 Click Save Changes.
Configuring EAP-FAST Settings for Security Group Access
Since RADIUS information is retrieved from the PAC, you must define the amount of time for the EAP-FAST tunnel PAC to live. You can also refresh the time to live for an active PAC.
To configure the EAP-FAST settings for the tunnel PAC:
Step 1 Choose Access Policies > Security Group Access Control > > Network Device Access.
Step 2 Fill in the fields in the Network Device Access EAP-FAST Settings page.
Step 3 Click Submit.
Creating an Access Service for Security Group Access
You create an access service for endpoint admission control policies for endpoint devices, and then you add the service to the service selection policy.
Note The NDAC policy is a service that is automatically applied to Security Group Access devices. You do
not need to create an access service for Security Group Access devices.
To create an access service:
Step 1 Choose Access Policies > Access Service, and click Create. See Configuring Access Services,
page 10-11, for more information.
Step 2 Fill in the fields in the Access Service Properties—General page as required.
Step 3 In the Service Structure section, choose User selected policy structure.
4-26
Step 4 Select Network Access, and check Identity and Authorization.
Step 5 Click Next.
The Access Services Properties page appears.
Step 6 In the Authentication Protocols area, check the relevant protocols for your access service.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
Step 7 Click Finish.
Creating an Endpoint Admission Control Policy
After you create a service, you configure the endpoint admission control policy. The endpoint admission control policy returns an SGT to the endpoint and an authorization profile. You can create multiple policies and configure the Default Rule policy. The defaults are Deny Access and the Unknown group.
To add a session authorization policy for an access service:
Step 1 Choose Access Policies > Access Services > service > Authorization.
Step 2 Configure an Authorization Policy. See Configuring a Session Authorization Policy for Network Access,
page 10-30.
Step 3 Fill in the fields in the Network Access Authorization Rule Properties page.
The Default Rule provides a default rule when no rules match or there are no rules defined. The default for the Default Rule result is Deny Access, which denies access to the network. The security group tag is Unknown.
ACS and Cisco Security Group Access
security
You can modify the security group when creating the session authorization policy for Security Group Access.
Step 4 Click OK.
Step 5 Choose Access Policies > Service Selection Policy to choose which services to include in the endpoint
policy. See Configuring the Service Selection Policy, page 10-5, for more information.
Step 6 Fill in the fields in the Service Select Policy pages.
Step 7 Click Save Changes.
Creating an Egress Policy
The Egress policy (sometimes called SGACL policy) determines which SGACL to apply at the Egress points of the network based on the source and destination SGT. The Egress policy is represented in a matrix, where the X and Y axis represent the destination and source SGT, respectively, and each cell contains the set of SGACLs to apply at the intersection of these two SGTs.
Any security group can take the role of a source SGT, if an endpoint (or Security Group Access device) that carries this SGT sends the packet. Any security group can take the role of a destination SGT, if the packet is targeting an endpoint (or Security Group Access device) that carries this SGT. Therefore, the Egress matrix lists all of the existing security groups on both axes, making it a Cartesian product of the SGT set with itself (SGT x SGT).
The first row (topmost) of the matrix contains the column headers, which display the destination SGT. The first column (far left) contains the row titles, with the source SG displayed. At the intersection of these axes lies the origin cell (top left) that contains the titles of the axes, namely, Destination and Source.
OL-26225-01
All other cells are internal matrix cells that contain the defined SGACL. The rows and columns are ordered alphabetically according to the SGT names. Each SGACL can contain 200 ACEs.
User Guide for Cisco Secure Access Control System 5.4
4-27
ACS and Cisco Security Group Access
Initially, the matrix contains the cell for the unknown source and unknown destination SG. Unknown refers to the preconfigured SG, which is not modifiable. When you add an SG, ACS adds a new row and new column to the matrix with empty content for the newly added cell.
To add an Egress policy and populate the Egress matrix:
Step 1 Choose Access Policies > Security Group Access Control > Egress Policy.
The Egress matrix is visible. The security groups appear in the order in which you defined them.
Step 2 Click on a cell and then click Edit.
Step 3 Fill in the fields as required.
Step 4 Select the set of SGACLs to apply to the cell and move the selected set to the Selected column.
The ACLS are used at the Egress point of the SGT of the source and destination that match the coordinates of the cell. The SGACLs are applied in the order in which they appear.
Step 5 Use the Up and Down arrows to change the order. The device applies the policies in the order in which
they are configured. The SGACL are applied to packets for the selected security groups.
Step 6 Click Submit.
Chapter 4 Common Scenarios Using ACS
Creating a Default Policy
After you configure the Egress policies for the source and destination SG in the Egress matrix, Cisco recommends that you configure the Default Egress Policy. The default policy refers to devices that have not been assigned an SGT. The default policy is added by the network devices to the specific policies defined in the cells. The initial setting for the default policy is Perm it A l l .
The term default policy refers to the ANY security group to ANY security group policy. Security Group Access network devices concatenate the default policy to the end of the specific cell policy.
If the cell is blank, only the default policy is applied. If the cell contains a policy, the resultant policy is the combination of the cell-specific policy which precedes the default policy.
The way the specific cell policy and the default policy are combined depends on the algorithm running on the device. The result is the same as concatenating the two policies.
The packet is analyzed first to see if it matches the ACEs defined by the SGACLs of the cell. If there is no match, the packet falls through to be matched by the ACEs of the default policy.
Combining the cell-specific policy and the default policy is done not by ACS, but by the Security Group Access network device. From the ACS perspective, the cell-specific and the default policy are two separate sets of SGACLs, which are sent to devices in response to two separate policy queries.
To create a default policy:
Step 1 Choose Access Policies > Security Group Access Control > Egress Policy then choose Default Policy.
Step 2 Fill in the fields as in the Default Policy for Egress Policy page.
4-28
Step 3 Click Submit.
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS

RADIUS and TACACS+ Proxy Requests

You can use ACS to act as a proxy server that receives authentication RADIUS requests and authentication and authorization TACACS+ requests from a network access server (NAS) and forwards them to a remote server. ACS then receives the replies for each forwarded request from the remote RADIUS or TACACS+ server and sends them back to the client.
ACS uses the service selection policy to differentiate between incoming authentication and accounting requests that must be handled locally and those that must be forwarded to a remote RADIUS or TACACS+ server.
When ACS receives a proxy request from the NAS, it forwards the request to the first remote RADIUS or TACACS+ server in its list. ACS processes the first valid or invalid response from the remote RADIUS server and does the following:
If the response is valid for RADIUS, such as Access-Challenge, Access-Accept, or Access-Reject,
ACS returns the response back to the NAS.
If ACS does not receive a response within the specified time period, then after the specified number
of retries, or after a specified network timeout, it forwards the request to the next remote RADIUS server in the list.
If the response is invalid, ACS proxy performs failover to the next remote RADIUS server. When
the last failover remote RADIUS server in the list is reached without getting reply, ACS drops the request and does not send any response to the NAS.
RADIUS and TACACS+ Proxy Requests
ACS processes the first valid or invalid response from the remote TACACS+ server and does the following:
If the response is valid for TACACS+, such as TAC_PLUS_AUTHEN (REPLY) or
TAC_PLUS_AUTHOR(RESPONSE), ACS returns the response back to the NAS.
If ACS does not receive a response within the specified time period, after the specified number of
retries, or after specified network timeout it forwards the request to the next remote TACACS+ server in the list.
If the response is invalid, ACS proxy performs failover to the next remote TACACS+ server. When
the last failover remote TACACS+ server in the list is reached without getting reply, ACS drops the request and does not send any response to the NAS.
You can configure ACS to strip the prefix, suffix, and both from a username (RADIUS) or user (TACACS+). For example, from a username acme\smith@acme.com, you can configure ACS to extract only the name of the user, smith by specifying \ and @ as the prefix and suffix separators respectively.
ACS can perform local accounting, remote accounting, or both. If you choose both, ACS performs local accounting and then moves on to remote accounting. If there are any errors in local accounting, ACS ignores them and moves on to remote accounting.
During proxying, ACS:
1. Receives the following packets from the NAS and forwards them to the remote RADIUS server:
Access-Request
2. Receives the following packets from the remote RADIUS server and returns them to the NAS:
OL-26225-01
Access-Accept
Access-Reject
Access-Challenge
3. Receives the following packets from the NAS and forwards them to the remote TACACS+ server:
User Guide for Cisco Secure Access Control System 5.4
4-29
RADIUS and TACACS+ Proxy Requests
TAC_PLUS_AUTHOR
TAC_PLUS_AUTHEN
4. Receives the following packets from the remote TACACS+ server and returns them back to the NAS:
This behavior is configurable.
TAC_PLUS_ACCT
An unresponsive external RADIUS server waits for about timeout * number of retries seconds before failover to move to the next server.
There could be several unresponsive servers in the list before the first responsive server is reached. In such cases, each request that is forwarded to a responsive external RADIUS server is delayed for number of previous unresponsive servers * timeout * number of retries.
This delay can sometimes be longer than the external RADIUS server timeout between two messages in EAP or RADIUS conversation. In such a situation, the external RADIUS server would drop the request.
You can configure the number of seconds for an unresponsive external TACACS+ server waits before failover to move to the next server.
ACS 5.4 supports multiple network interface connectors for RADIUS (IPv4) and TACACS+ (IPv4 and IPv6) proxies. ACS 5.4 with Virtual machine, UCS, IBM, or CAM platform contains up to four network interfaces: Ethernet 0, Ethernet 1, Ethernet 2, and Ethernet 3. For more information, see Multiple
Network Interface Connector in the Connecting the Network Interface section of Installation and
Upgrade Guide for Cisco Secure Access Control System 5.4.
Chapter 4 Common Scenarios Using ACS
Related Topics
Supported Protocols, page 4-30
Supported RADIUS Attributes, page 4-31
Configuring Proxy Service, page 4-32
Supported Protocols
The RADIUS proxy feature in ACS supports the following protocols:
Supports forwarding for all RADIUS protocols
All EAP protocols
Protocols not supported by ACS (Since ACS proxy do not interfere into the protocol conversation
and just forwards requests)
Note ACS proxy can not support protocols that use encrypted RADIUS attributes.
The TACACS+ proxy feature in ACS supports the following protocols:
PAP
ASCII
CHAP
MSCHAP authentications types
4-30
Related Topics
RADIUS and TACACS+ Proxy Requests, page 4-29
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 4 Common Scenarios Using ACS
Supported RADIUS Attributes, page 4-31
Configuring Proxy Service, page 4-32
Supported RADIUS Attributes
The following supported RADIUS attributes are encrypted:
User-Password
CHAP-Password
Message-Authenticator
MPPE-Send-Key and MPPE-Recv-Key
Tunnel-Password
LEAP Session Key Cisco AV-Pair
TACACS+ Body Encryption
RADIUS and TACACS+ Proxy Requests
When ACS receives a packet from NAS with encrypted body (flag TAC_PLUS_UNECRYPTED_FLAG is 0x0), ACS decrypts the body with common data such as shared secret and sessionID between NAS and ACS and then encrypts the body with common data between ACS and TACACS+ proxy server. If the packet body is in cleartext, ACS will resend it to TACACS+ server in cleartext.
Connection to TACACS+ Server
ACS supports single connection to another TACACS+ server (flag TAC_PLUS_SINGLE_CONNECT_FLAG is 1). If the remote TACACS+ server does not support multiplexing TACACS+ sessions over a single TCP connection ACS will open or close connection for each session.
Related Topics
RADIUS and TACACS+ Proxy Requests, page 4-29
Supported Protocols, page 4-30
Configuring Proxy Service, page 4-32
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
4-31
RADIUS and TACACS+ Proxy Requests
Configuring Proxy Service
To configure proxy services:
Step 1 Configure a set of remote RADIUS and TACACS+ servers. For information on how to configure remote
servers, see Creating, Duplicating, and Editing External Proxy Servers, page 7-19.
Step 2 Configure an External proxy service. For information on how to configure a External proxy service, see
Configuring General Access Service Properties, page 10-13.
You must select the User Selected Service Type option and choose External proxy as the Access Service Policy Structure in the Access Service Properties - General page.
Step 3 After you configure the allowed protocols, click Finish to complete your External proxy service
configuration.
Related Topics
RADIUS and TACACS+ Proxy Requests, page 4-29
Chapter 4 Common Scenarios Using ACS
Supported Protocols, page 4-30
Supported RADIUS Attributes, page 4-31
4-32
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
CHA PTER
5

Understanding My Workspace

The Cisco Secure ACS web interface is designed to be viewed using Microsoft Internet Explorer versions 6.x to 9.x and Mozilla Firefox versions 3.x to 10.x. The web interface not only makes viewing and administering ACS possible, but it also allows you to monitor and report on any event in the network.
These reports track connection activity, show which users are currently logged in, list the failed authentication and authorization attempts, and so on.
The My Workspace drawer contains:
Welcome Page, page 5-1
Task Guides, page 5-2
My Account Page, page 5-2
Login Banner, page 5-3
Using the Web Interface, page 5-3
Importing and Exporting ACS Objects through the Web Interface, page 5-18
Common Errors, page 5-25
Accessibility, page 5-27

Welcome Page

The Welcome page appears when you start ACS, and it provides shortcuts to common ACS tasks and links to information.
You can return to the Welcome page at any time during your ACS session. To return to this page, choose My Workspace > Welcome.
Ta bl e 5 -1 We l c om e P ag e
Field Description
Before You Begin Contains a link to a section that describes the ACS policy model and associated terminology.
Getting Started Links in this section launch the ACS Task Guides, which provide step-by-step instructions on how
to accomplish ACS tasks.
Quick Start Opens the Task Guide for the Quick Start scenario. These steps guide you through a minimal
system setup to get ACS going quickly in a lab, evaluation, or demonstration environment.
OL-26225-01
User Guide for Cisco Secure Access Control System 5.4
5-1
Chapter 5 Understanding My Workspace

Task Guides

Table 5-1 Welcome Page (continued)
Field Description
Initial System Setup Opens the Task Guide for initial system setup. This scenario guides you through the steps that are
required to set up ACS for operation as needed; many steps are optional.
Policy Setup Steps Opens the Task Guide for policy setup. This scenario guides you through the steps that are
required to set up ACS policies.
New in ACS 5 Options in this section link to topics in the ACS online help. Click an option to open the online
help window, which displays information for the selected topic.
Use the links in the online help topics and in the Contents pane of the online help to view more information about ACS features and tasks.
Tutorials & Other Resources
Provides links to:
Introduction Overview video.
Configuration guide that provides step-by-step instructions for common ACS scenarios.
In ACS 5.4, you can also see a banner in the welcome page. You can customize this After Login banner text from the Login Banner page.
Task Guides
From the My Workspace drawer, you can access Tasks Guides. When you click any of the tasks, a frame opens on the right side of the web interface. This frame contains step-by-step instructions, as well as links to additional information. ACS provides the following task guides:
Quick Start—Lists the minimal steps that are required to get ACS up and running quickly.
Initial System Setup—Lists the required steps to set up ACS for basic operations, including
information about optional steps.
Policy Setup Steps—Lists the required steps to define ACS access control policies.

My Account Page

Note Every ACS administrator account is assigned one or more administrative roles. Depending upon the roles
assigned to your account, you may or may not be able to perform the operations or see the options described in certain procedures. See Configuring System Administrators and Accounts, page 16-3 to configure the appropriate administrator privileges.
Use the My Account page to update and change the administrator password for the administrator that is currently logged in to ACS.
To display this page, choose My Workspace > My Account.
5-2
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 5 Understanding My Workspace

Login Banner

Table 5-2 My Account Page
Field Description
General Read-only fields that display information about the currently logged-in administrator:
Administrator name
Description
E-mail address, if it is available
Change Password Displays rules for password definition according to the password policy.
To change your password:
1. In the Password field, enter your current password.
2. In the New Password field, enter a new password.
3. In the Confirm Password field, enter your new password again.
Assigned Roles Displays the roles that are assigned to the currently logged-in administrator.
Related Topics
Configuring Authentication Settings for Administrators, page 16-10
Changing the Administrator Password, page 16-22
Login Banner
ACS 5.4 supports customizing of the login banner texts. You can set two sets of banner text; for instance, before logging you can display one banner text, and after logging in you can display another banner text. You can do this customization from the Login Banner page. The copyright statement is the default for both the banners.
Note ACS does not support ' and " symbols in login banner text.
To customize the login banner, choose My Workspace > Login Banner.
Table 5-3 Login Banner Page
Field Description
Before Login Enter the text that you want to display in the banner before login.
After Login Enter the text that you want to display in the banner after login.

Using the Web Interface

You can configure and administer ACS through the ACS web interface, in which you can access pages, perform configuration tasks, and view interface configuration errors. This section describes:
OL-26225-01
Accessing the Web Interface, page 5-4
Understanding the Web Interface, page 5-5
User Guide for Cisco Secure Access Control System 5.4
5-3
Using the Web Interface
Common Errors, page 5-25
Accessibility, page 5-27
Accessing the Web Interface
The ACS web interface is supported on HTTPS-enabled Microsoft Internet Explorer versions 6.x to 9.x and Mozilla Firefox versions 3.x to 10.x.
This section contains:
Logging In, page 5-4
Logging Out, page 5-5
Logging In
To log in to the ACS web interface for the first time after installation:
Step 1 Enter the ACS URL in your browser, for example, https://acs_host/acsadmin, https://[IPv6
address]/acsadmin, or https://ipv4 address/acsadmin, where /acs_host is the IP address or Domain
Name System (DNS) hostname. The DNS hostname works for IPv6 when the given IP address is resolvable to both IPv4 and IPv6 formats.
Chapter 5 Understanding My Workspace
Note Launching the ACS web interface using IPv6 addresses is not supported in Mozilla Firefox
versions 4.x or later.
The login page appears.
Step 2 Enter ACSAdmin in the Username field; the value is not case-sensitive.
Step 3 Enter default in the Password field; the value is case-sensitive.
This password (default) is valid only when you log in for the first time after installation. Click Reset to clear the Username and Password fields and start over, if needed.
Step 4 Click Login or press Enter.
The login page reappears, prompting you to change your password.
ACS prompts you to change your password the first time you log in to the web interface after installation and in other situations based on the authentication settings that is configured in ACS.
Step 5 Enter default in the Old Password field, then enter a new password in the New Password and the Confirm
Password fields.
If you forget your username or password, use the acs reset-password command to reset your username to ACSAdmin and your password to default. You are prompted to change your password after a reset. See Command Line Reference for ACS 5.4 for more information.
Step 6 Click Login or press Enter.
You are prompted to install a valid license:
5-4
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Loading...