How to Migrate ACS 5.x to ISE 2.x

[kthiruve]

This is meant to understand all the aspects migration and also to guide you through different steps in the migration project for you and your customers. For complete information on ACS to ISE migration, top of the mind questions, quick answers to comparisons, video tutorials, demos, please view

ACS to ISE Migration

Author: Krishnan Thiruvengadam

Table of Contents

• Introduction
• Background
• Planning Your Migration
• ACS vs ISE Feature Comparison
• ACS vs ISE Underlying Differences
• Migration Paths
• Migration from 5.x to ACS 5.5/ 5.6/ 5.7/ 5. 8
• Migration from ACS 4.x to ACS 5.x
• Deployment Considerations
• ACS vs ISE Deployment Comparison
• TACACS+ Topology Design
• Device Administration Model
• Deployment Options
• PSN Scale
• Licensing
• ISE VM Sizing for Log Retention
• Log retention and sizing MnT hard disks
• What happens if my logging requirements exceeds the example?
• Prepare Your Migration
• Configuration Maps and Exceptions
• Network Resources
• Users and Identity Stores
• Policy Elements
• Access Policies
• Monitoring and Reporting
• System Administration
• Staging Environment for Migration
• Migration Tool Requirements
• Installation and configuration of the Migration Tool
• Supported/Unsupported Objects for Migration
• Preparation for Migration from Cisco Secure ACS, Release 5.5+
• Migration Process with Migration Tool
• Exporting ACS Configuration
• Policy Gap Analysis
• Network Devices and Network Device Groups
• Importing ACS Configuration
• Verifying Migration of Access Policies
• For RADIUS
• For TACACS
• Supporting Chatty Devices (TACACS+ single connect)
• Final Steps
• Appendix A: ACS vs ISE Deployment Limits
• Appendix B: TACACS+ Performance per ISE Deployment
• Dedicated TACACS+ Only Deployment
• Shared deployment (RADIUS + TACACS+):
• Appendix C: ISE VM Sizing and Log retention
• TACACS+ guidance for size of syslogs:
• TACACS+ transactions, logs and storage
• TACACS+ log retention (# of days):
• Scripted device admin model
• Human admin – device admin using sample number of sessions and commands shown below.
• RADIUS Log retention (# of days)
• Appendix D: Unsupported Rule Elements

Introduction

This document provides partners, Cisco field engineers and TME’s with a guide to plan ACS to ISE migration. This document will also have procedure for migrating from Cisco Secure Access Control System (ACS) to Identity Services Engine (ISE) software. ISE 2.1 and above supports migration from ACS 5.5/ 5.6/ 5.7/ 5.8. ISE 2.0 supports migration from ACS 5.5 or ACS 5.6 only. ACS from prior versions need to be upgraded to these versions before migrating over to ISE 2.x.

This document will have 3 broad sections for performing ACS to ISE migration.

• Planning your migration

• Prepare your migration

• Migration process

Planning your migration section covers the feature comparison and underlying differences between ACS vs ISE features. It provides options for topology design, device administration models to help scale PSN’s. It provides step by step guide to plan out your hardware capacity keeping the IT Audit needs for logs retention while migrating to new ISE environment.

Prepare your Migration section includes best practices and steps for operational tasks to prepare for your migration. This includes configuration maps that points to location of functional configuration in ACS and ISE calling in exceptions during migration of ACS to ISE with ways to fix issues. It also discusses on creating a staging environment for migration and preparing the tool/setup for migration.

Migration process is the core section that will cover the migration process and provides step by step procedure to export configuration, fix policy gaps and import configuration to ISE iteratively till the migration is successful.

Background

Cisco Secure Access Control System (ACS) is a centralized identity and access policy solution that ties together an enterprise's network access policy and identity strategy. Cisco Secure ACS operates as a RADIUS and TACACS+ server, combining user authentication, user and administrator device access control, and policy control in a centralized identity networking solution.

Cisco ISE is a consolidated policy-based access control system that incorporates a superset of features available in existing Cisco policy platforms. Cisco ISE performs the following functions:

• Consolidates the network access functionality of ACS and ties together profiling and posture compliance.
• On-boarding mobile device using secure BYOD (Bring your own device) flows.
• Provides for comprehensive guest access management for Cisco ISE administrators.
• Enforces endpoint compliance with comprehensive client provisioning.
• Discovery, profiling, policy-based placement, and monitoring of endpoint devices on the network
• Employs advanced enforcement capabilities with TrustSec using Secure Group Tags(SGT’s)
• Facilitates TACACS-enabled device administration through its Work Center. The Work Center menu contains a work flow for TACACS+ configuration, which acts as a single start point for ISE administrators.

Planning Your Migration

This section will give you information on the basic, top of the mind questions related to migration that includes ISE vs ACS feature comparison and underlying differences, migration paths to migrate from different versions of ACS, Deployment differences between ACS to ISE. It will also help you design with the best topology for your environment keeping in mind your current ACS deployment, device administration model and log retention needs of your IT environment.

ACS vs ISE Feature Comparison

The full feature comparison of ACS 5.x and ISE 2.x can be found in ACS vs ISE Comparison. ISE 2.0 has a full TACACS+ protocol implementation and feature sets have only few differences from ACS. ISE 2.1+ supports ACS parity items including scalability. 

For TACACS+, ISE 2.x has a Device Administration Work Center that provides a nice work flow for the administrator to configure the device administration functionality. Migration Tool can be downloaded directly from work center to your Windows machine to perform migration between ACS and ISE. ISE provides robust reporting capability of TACACS + authentication, authorization, accounting and command accounting. ISE 2.3 included additional set of reports to complete the functionality on par with ACS.

ISE 2.3 included IPv6 support for TACACS+ and support for IP ranges in all IPv4 octets.

Policy Sets in ISE vs Access Service + Service Selection Policy in ACS:

ISE 2.x has a rule based policy model like ACS 5.x versions. ISE 2.x supports policy sets. Each policy set that has an entrance criteria for filtering incoming requests to apply to the corresponding Authentication and Authorization policies.

In ACS, access services lets you create a service policy structure based on service type (RADIUS/ TACACS+/external proxy) to create an Identity/Authorization policy. A Service Selection Policy provides a criteria to select the right access services. An access service is selected based on conditions where single or multiple Service Selection Rules can use the same service.

In ISE, you must enable Policy Sets on ISE UI from Administration ➡ System Settings ➡ Policy Settings to make them available on the Policy menu for RADIUS.

ACS vs ISE Underlying Differences

Both ACS 5.5+ and ISE 2.x have functionally similar policy engines, however to ensure proper and error free migration, there are several things to make note of in the underlying differences between ACS and ISE. The following features do not relate specifically to the TACACS+ protocol but are used in deployment solutions.

1. Naming constraints: ISE 2.1 does not allow many special character’s in its object entities. For example, semicolon “:”, dot “.” depending on the type of entity.
   Note: ISE 2.1 and ISE 2.0 patch 2 supports “.”). ISE typically allows alpha numeric characters, “_” and “– “character in its objects. Some objects such as username and authorization profile might support more characters. When ACS objects has special characters, these objects will be renamed by the migration tool and imported to ISE . This is discussed in depth in the next chapter.

2. Custom Conditions or Aliases: it is implemented in ISE 2.0 as regular inline custom conditions.

3. Policy Format/Alias: Tabular form of policy tables and hit counts are supported in ISE 2.3

4. Unsupported rule elements: ISE does not support certain elements that are part of rule or condition. This includes Unsupported attributes used by the policy, Unsupported AND/OR condition structure (mainly, once complex conditions are configured) and Unsupported operators. For example, ACS supports a combination of AND and OR in its compound condition used in an authorization policy. ISE 2.0 through ISE 2.2 supports either AND or in its authorization conditions in an authorization policy. This may cause policies not to get migrated. ACS authorization policy needs to be analyzed, split and additional policies should be added in view of this. For complete list of unsupported rule elements please see Appendix D.

Note: Combination of AND and OR operators is supported in ISE 2.3.

Note: It is not necessary to have special entity to make ISE 2.0 traverse different identity stores and fetch information.

Migration Paths

ISE 2.0 supports migration from ACS 5.6 or ACS 5.5 versions only.

ISE 2.1+ supports migration from ACS 5.5 / 5.6 / 5.7 and ACS 5.8.

Migration from 5.x to ACS 5.5/ 5.6/ 5.7/ 5. 8

If customers are in prior version of ACS 5.x, you have to upgrade to ACS 5.5 and ACS 5.6 first before migrating to ISE 2.0. For migrating to ISE 2.1 your customer be in one of the last 4 releases of ACS (ACS 5.5/ 5.6/ 5.7 or 5.8).

If your customers interim goal is to upgrade to the latest ACS version due to the EOL considerations shown below then upgrade to ACS 5.8.

Version	End of Sale	End of Life	End of Support(Vulnerability fix)
5.8	Aug 30, 2017	Aug 30, 2018	Aug 31, 2020
5.7	May 2, 2016	May 2, 2017	May 31, 2019
5.6	Feb 16, 2016	Feb 15, 2017	February 28, 2019
5.5	April 15, 2015	April 14, 2016	April 30, 2018
4.2	October 27, 2011	October 26, 2012	October 31, 2014
3.3	August 29, 2006	August 29, 2007	August 28, 2009

Please follow the link for detailed procedure for migrating to ACS 5.8. Here are the upgrade paths for the ACS 5.x versions. The versions that support migration to ISE is in black letters as shown below, rest in blue.

• ACS 5.0ACS 5.2 ACS 5.4 ACS 5.6ACS 5.7 or ACS 5.8

• ACS 5.1 ACS 5.3 ACS 5.5 ACS 5.6 or ACS 5.7 or ACS 5.8

• ACS 5.2 ACS 5.4 ACS 5.6 ACS 5.7 or ACS 5.8

• ACS 5.3 ACS 5.5 ACS 5.6 or ACS 5.7 or ACS 5.8

• ACS 5.4 ACS 5.6 ACS 5.7 or ACS 5.8

Migration from ACS 4.x to ACS 5.x

ACS 4.x is an older version and cannot migrate to ISE directly. You must first upgrade from ACS 4.x to either ACS 5.5 or ACS 5.6 before migrating to ISE 2.0.

ACS 5.x has a significantly different architecture than ACS 4.x. The migration might not carry over a lot of configuration automatically. You might have to manually carry over configuration or use import/export tools. Here are the links that speaks about what objects are supported/not supported during migration.

ACS 4.x to ACS 5.5

ACS 4.x to ACS 5.6

If you need to migrate from ACS 4.x, best approach is to start clean, install ISE and do manual configuration. You can also use import/export tools that is supported in ISE for user identities/group identities, network devices, network devices groups etc. You can also use REST API for populating configuration in ISE.

For customers to migrate to ACS 5.5 or ACS 5.6, they need to be in one of the ACS 4.x versions

• ACS 4.1.1.24

• ACS 4.1.4

• ACS 4.2.0.124 

• ACS 4.2.1

Please look at the ACS 4.x to 5.x migration doc for more details on architecture and the choices for migration based on your configuration sets.

Deployment Considerations

ISE supports standalone deployment for smaller networks. For larger networks, ISE supports distributed deployment to support services including network access, profiling, BYOD, Guest, Posture Compliance and TrustSec. ISE 2.x supports TACACS+ service for providing device admin and audit control supporting 30k network device objects in ISE 2.0 and 100k network devices in ISE 2.1+ in a single deployment.

ACS vs ISE Deployment Comparison

ISE deployment is slightly different from ACS that has either primary or secondary instances in three functional roles Primary, Secondary or dedicated logging (Primary or Secondary). In ACS deployment, the primary and secondary are both active and take part in providing AAA services in a network. AAA client traffic is primarily distributed by the network devices across the ACS instances for balancing the load.

A Cisco ISE node is a dedicated appliance or Virtual Machine that supports different functional roles or personas such as Administration, Policy Service, Monitoring, and PxGrid. Details about the functional roles are described here. These functional roles can be combined or separated in dedicated nodes to optimize the distribution of endpoint connections based on geography, based on the type of services used etc. Each of the personas can be part of a standalone or in a distributed deployment.

Simple 2 Node Deployment – ACS vs ISE

In a simple 2 node ISE deployment with redundancy, ISE node can have an active/standby pair for Administration and active/active Monitoring personas. Policy services persona is also part of the same node for standalone deployment. Policy Service persona is the work horse of ISE providing network access, posture, BYOD, guest access, client provisioning, and profiling services. A two nodes deployment of ACS is shown below for comparison. 

   

Figure 1. Basic 2 Node Setup ISE(Left), ACS (Right)

In ISE deployment, each persona can be a dedicated node with separate Administration, Monitoring and Policy Services nodes or a combination as shown in Figure 2 below. Policy Services Node provides AAA services including RADIUS services, TACACS services. Policy Services persona evaluates the policies and makes all the decisions in an ISE deployment. You can have more than one node assuming this persona.

Figure 2. Single ISE node with one more Personas

ACS vs ISE Distributed Deployment

ACS has a flatter deployment model for dispersing the ACS instances across the network. ACS deployment scalability works by including additional backup servers based on the performance and logging requirement. ACS deployment supports robust replication, full synchronization and incremental replication. As the number of ACS scales up for large deployment, a dedicated syslog server is recommended with a total deployment supporting 22 ACS instances.

Figure 3. ACS Distributed Deployment

Basic Distributed Deployment

In ISE, expanding the 2 node setup above to a basic distributed deployment, for a network that spans across geographies, business units you can add up to 5 dedicated PSN’s to the 2 node setup in Figure 4 as shown below. In this topology, you have two PAN/ MnT nodes as primary and secondary in a redundant setup in the same datacenter. This setup supports to a maximum of 20,000 endpoints across PSN’s across different geographies. This is similar to a small to medium sized deployment of with few instances of ACS as shown above in Figure 3 above.

Figure 4. Basic Distributed Deployment (ISE)

Note: In a distributed deployment, inter-ISE node delay (latency) should be lesser than or equal to 200ms for versions ISE 2.0 and lower (300ms for ISE 2.1+) for successful node communication and replication. For TACACS+ the latency requirement may be relaxed.

Fully Distributed Deployment

In a fully distributed deployment, the administration and monitoring personas are separated in different nodes with 2 Admin nodes and 2 MnT nodes. In a large network, the primary, secondary admin and monitoring nodes are dedicated nodes that can be in different datacenters as shown in Figure 5. below.

Figure 5. Fully Distributed Deployment

The full distributed topology requires datacenters to be connected with a high speed and low latency links. With ISE 2.1, a maximum of 50 PSN’s with 2 PAN and 2 MnT’s are supported with a maximum of 500,000 endpoints across PSN’s (250k endpoints for ISE 2.0). Policy services nodes in the same location can be part of a node group called cluster that will help with high availability in case of PSN failures. This can be useful for services such as profiling etc.

Appendix A provides comparison on the deployment limits of ACS vs ISE and can be used as a reference to determine to scale your deployment.

TACACS+ Topology Design

ISE topology design needs to account for the scalability needs of the customer. There are a few differences between ACS and ISE deployment scalability limits as in Appendix A .

When migrating ACS deployment to ISE, you need to comprehend the deployment considerations mentioned in the section above for one or both Network Access (RADIUS) and Device Administration (TACACS+) services. Whether you dedicate a separate node for TACACS+ is more of a security and operational policy decision.  If separated in ACS deployment today, then continue doing so if that model serves you well. 

Tip: If you wish to combine both TACACS+ Device Administration and RADIUS into same deployment, then dedicating nodes to TACACS+ service may be the best option for a large organization to prevent user services from impacting device admin services and vice versa.

Device Administration Model

The main question here is whether RADIUS and Device Admin (TACACS+) should co-exist in the same node or as independent nodes. Here is some general guidance that will help you answer the question:

• For programmatic device admin model, recommend dedicated PSN nodes for Device Admin service.

• For human device admin model where individual admin users manually login and manage network devices, consider the following example:

• 20 Device admins concurrent sessions @ 1 command/s = 40 TPS (command authorization + accounting record)

• In this scenario, it would be acceptable to run Device Admin service on PSNs running other core endpoint services.

• If you expect a much higher level of activity – much higher number of concurrent admins or transactions – then consider dedicating PSN.

Note: Organizational requirements and security policies such as “separation of device admin and user access control” may dictate the need for dedicated PSN nodes for Device Admin function, or even an isolated ISE deployment to separate RADIUS and TACACS+ control.

Deployment Options

There are 3 ways you can deploy TACACS+/ RADIUS services with ISE simple or distributed deployment. These are dedicated deployment, dedicated PSN’s and Integrated deployment as described below. Each has its own pros and cons and use cases.

The illustration below will give further details on each of the above options:

Dedicated Deployment	Dedicated PSNs	Integrated
Separate deployments for RADIUS and TACACS+. This includes a separate Administration Node (PAN) for managing policies, users/groups, network devices etc., a separate Monitoring Node (MnT) for managing TACACS+ logs and dedicated Policy Services Node for supporting TACACS+ or RADIUS service.	The ISE Administration Node (PAN) and Monitoring Node (MNT) are shared for managing policies, policy elements, logging and other configuration for both TACACS+ and RADIUS. However you will still have a dedicated PSNs for addressing incoming TACACS+ or RADIUS requests and they are not shared.	Shared Policy services node(PSN), admin (PAN) and Monitoring node (MnT) for TACACS+ and RADIUS. For medium/small sized companies where device administration and network access managed by same group. For Device admin model using only human admin users. Where seperation of Network access and Device admin users are not critical.
Pros: Complete separation of policy & operations for Device Administration vs. Network Access. Cons: Separate ISE deployments to maintain. Cost of additional PAN and MNT nodes for the second deployment.	Pros: Centralized policy, monitoring for all AAA Scale Device Administration independently from Network Access as needed Cons: Per-PSN utilization may be low for a dedicated function. May need additional PSNs for distributed coverage.	Pros: Centralized policy & monitoring for all AAA needs. Same configuration for all PSNs. Scale all AAA needs incrementally by adding a PSN when or where needed. Cons: Potential need for cross-department administrative access depending on the organization. Load from Network Access may impact Device Administration services and vice versa.

To plan and run your ACS to ISE migration, you need to perform several steps. The document will guide you through these steps necessary based on the type of customer, deployment needs etc.

1. Choose the deployment model that fits your need based on the information in the section above.

2. Choose the type of deployment, 2 Node Dedicated vs Simple or fully distributed deployment based on the Deployment considerations

PSN Scale

Once a suitable deployment method is chosen,

1. For TACACS+ only, to determine the number of PSN’s for scripted device administration model as discussed above, you can replace each ACS authentication server with an ISE PSN node. This is a simple, fool proof approach.
2. For Endpoint services(Secure access and other services using RADIUS, when determining number of PSN’s for a RADIUS deployment, please use ‘Maximum Concurrent Endpoints’ as the main guideline as discussed in Appendix B: Shared deployment (RADIUS + TACACS+):.
3. If your ACS is oversubscribed use the Performance Metrics in the Appendix at the end of the doc.

From Appendix C: TACACS+ transactions, logs and storage , select the right Device Administration model to determine the transactions per second (TPS) for TACACS+ controls (Authentication, session authorization, accounting (or) Command accounting only (or) for everything) in your environment. Please pay attention to the peak TPS based on the model.

Then refer Appendix B and look at the table at the bottom to know the peak TPS supported across different appliance to choose the hardware needed for the PSN’s. Please remember to scale PSN’s considering redundancy, location/geography and other factors as outlined in in ACS vs ISE Distributed deployment section above.

Tip: Please pay attention to TACACS+ performance in Appendix B for dedicated and shared deployments which will be the key to determine the number of PSN’s. Remember that all other transactions happens once during the TACACS + session except for command authorization and accounting.

Licensing

When migrating from ACS deployment using a 35xx appliance/ legacy appliance or VM, use the ISE ordering guide for information about licensing. Go to ‘Migration appliance ordering information’ section for your specific needs.

TACACS+ functionality requires a perpetual license for the entire ISE deployment and does not have a migration license. You also need for a minimum number of Base license e.g.: Base license for 100 endpoints to access the UI functionality of TACACS+ and to turn on TACACS+ service.

To expand ISE deployment for more than TACACS+, please use the ordering guide mentioned above as reference. Please take a look at the ‘Cisco ISE migration Licenses’ and the ‘License consumption’ section in the ordering guide for more information.

ISE VM Sizing for Log Retention

Log size becomes an important factor to consider while designing the hardware and VM Hard disk sizing for the ISE MnT servers. This is especially for large enterprises where logging requirements might vary in your environment based on IT and audit policies of your network.

In ISE, monitoring persona (MnT) is responsible for collecting logs, generating reports and for troubleshooting ISE deployments. Based on the logging needs of an enterprise you can choose remote syslog servers for log storage.

For TACACS+ logging requirements, there are two use cases to consider based on device administration performed either by a human administrator or by an automated script/ robot. Logs are collected in the MnT and purged based on the log retention needs and hard disk size. Here is a sample log size calculation per day for these use cases:

• Use case 1: Human administrator managing devices: For e.g.: 50 Administrators opening 50 sessions per day with 10 commands/session; Log size per day = 50 * 50 * (5k +10*3k) = 87500KB = 85.4MB per day.
• Use case 2: Managing devices using scripted device administration: An automated script to run against 30K network devices. For e.g.: @ 4 times per day with 5 commands per session; Log size per day = (5K +5 * 3K) * 30000 * 4 = 2400000KB ~ 2.3GB per day.

Log retention and sizing MnT hard disks

Log retention should be calculated for both TACACS+ and RADIUS separately.

6. For TACACS+, start by calculating the logs generated by your network devices for TACACS+ based on the device administration model in your environment. Please use the examples in the use cases mentioned above as reference. Use Appendix C to determine the log size per day for TACACS+. For RADIUS, logs are based on number of authentication.

7. Now gather information on the log retention needs of your environment (based on your audit needs etc.). Go back and refer to log retention tables in Appendix C and determine the hard disk size of MnT. This is especially important when you are using an ISE virtual machine.

What happens if my logging requirements exceeds the example?

If amount of logs per day as in Use case 2 above exceeds 2.3GB also shown in Appendix C – steps should be taken to reduce the logs sent to MnT based on the following.

1. Revise and minimize duplicate incoming log traffic: To avoid duplication of entries in AAA logs are generated by automated scripts (For the same user name and/or originated form the same IP address) use MnT collection filters in ISE (From ISE UI browse to SystemLoggingCollection Filters for this.) to filter incoming logs from scripts, “pings” or “keep-alive” to be masked out..

2. Consider separation of incoming traffic between ISE MnT and external 3^rd party Syslog collector: ISE administrator can create as many remote Logging Targets (SystemLoggingRemote Logging Targets) as necessary, to a generic Unix Syslog or to a third party SIEM software such as SPLUNK. After that each individual logging category may be routed to the specific Logging Target. (From ISE UI, browser to SystemLoggingLogging categories for this).

3. From ISE UI, go to Administration System Settings Protocols RADIUS and enable log suppression by enabling the last three options as shown here.

   

Prepare Your Migration

Outdated, redundant or stale policy or rule cleanup: As part of migration effort, revise and clean existing policy and rule set in ACS. Some of the policies might be inactive, obsolete and no longer relevant. Same goes true for users and Network devices. Observing Hit Count on ACS can help verifying this. Reset the Hit Count several months before migration. If Hit Count is equal to zero for a long time, this policy is a good candidate to be marked as disabled, moved to the end of list or removed at all. Consolidating and optimizing several policies into one is a good way to make configuration more manageable, more scalable and less prone to mistakes.

Configuration Maps and Exceptions

The tables below shows configuration map for ACS and ISE that includes location of configuration objects, exceptions that are observed during migration and ways to fix/get around those exceptions. For e.g.: As part of pre-migration, please clean up object names in ACS to make sure it does not have special characters not supported by ISE. Please see the details in the table below. The following tables are organized like the flow in the ACS UI for easy readability.

Network Resources

ACS 5 configuration	ISE Configuration	Exceptions and Fixes
Network Resources ➡ Network Device Groups Network Resources ➡ Network Devices	Work Centers ➡ Device Administration ➡ Network Device Groups. (A valid NDG name can contain alphanumeric, Hyphen(-), Underscore(_), period(.) and space characters) Work Centers ➡ Device Administration ➡ Network Resources ➡ Network Devices. (A valid Network Device name can contain alphanumeric, Hyphen(-), Underscore(_)) Migration tool will automatically convert the unsupported characters to supported ones in ISE 2.2+.	Naming constraints. Need to fix names during policy gap analysis. IP range not supported in ISE 2.0/2.1(convert the range into subnets if possible). ISE 2.2 supports IP ranges in the last octet. IP exclusions supported by “overlapping IPs”. ISE 2.3 supports IP ranges in all octets. If you change the default name of in ACS, it will not get migrated. ISE 2.1 supports Network devices name with “.” character.
Network Resources ➡ Default Network Device	Administration ➡ Network Resources ➡ Default Network Device	ISE must have RADIUS enabled (ISE 2.0 only). Fixed in ISE 2.1.
Network Resources ➡ External Proxy Servers	Work Centers ➡ Device Admin ➡ Network resources ➡ TACACS Proxy Servers Administration ➡ Network resources ➡ External Radius server	When ‘Cisco Secure ACS’ is external proxy, a prefix ‘TACACS_’ or ‘RADIUS_’ is added to the name before moving it to the correct location in ISE
Network Resources ➡ OCSP Services	-	Not Supported

Users and Identity Stores

ACS 5 Element	ISE Element	Exceptions and Fixes
Users and Identity Stores Internal Identity Stores Users Users and Identity Stores Identity groups	Administration ➡ Identity Management ➡ Identity ➡ Users Administration ➡ Identity Management ➡ User Identity Groups ➡ User identity Groups. (A valid User and User Identity group name can contain alphanumeric and ~@# $&*_+.- characters.)	Account disable policy, Password type not supported in ISE 2.0 (Supported in ISE 2.1). Disable password hashing for users if using ACS 5.7/5.8 Naming constraints. If using ISE 2.0/2.1, need to fix names during policy gap analysis.
Enable password option: Users and Identity Stores ➡ Internal Identity Stores ➡ Users (create user)	Enable Password option: (Workcenter ➡ Device Admin ➡ Identity ➡ Users (Add Users)	Check the password policy for defaults, password history, password Lifetime.
Users and Identity Stores ➡ Internal Identity Stores ➡ Hosts	Administration ➡ Identity Management ➡ Identity ➡ Endpoints. (A valid MAC address consists of six octets, separated by ':','.' or '-'. Valid octets contain 0-9,a-f,or A-F only.)	Wild cards are not supported in ISE.
User Identity Stores ➡ External Identity Store	Administration ➡ Identity Management ➡ External Identity Store	Description, RSA instance file, Display RSA missing secret will not be migrated. RSA sdopts.rec file and secondary information are not migrated.
User Identity Stores ➡ Certificate Authorities	Administration ➡ Certificates ➡ Certificate Management ➡ Trusted Certificates	Migration not supported.
User Identity Stores ➡ Certificate Authentication profile	Administration ➡ Identity Management ➡ External Identity Store ➡ Certificate Authentication Profile (A valid name can contain alphanumeric and underscore(_) characters.)	Name Constraints. If using ISE 2.0/2.1, fix name mismatch in ACS.
User and Identity Store ➡ Identity Store Sequence	Administration ➡ Identity Management ➡ Identity Store Sequence	Additional Attribute retrieval not supported in ISE. See 1 for more details.

Policy Elements

ACS 5 Element	ISE Element	Exceptions and Fixes
Policy Elements ➡ Authorization and Permissions ➡ Network Access ➡ Authorization Profiles	Policy ➡ Policy Elements ➡ Results ➡ Authorization profile	Unique name required. Name Conflicts (shared namespace in ISE)
Policy Elements ➡ Authorization and Permissions ➡ Named Permission Objects ➡ Downloadable ACL	Policy ➡ Policy Elements ➡ Results ➡ Downloadable ACL	Unique name required.
Policy Elements ➡ Device Administration ➡ Shell Profiles	Work Centers ➡ Device Administration ➡ Policy Results ➡ TACACS Profiles	No Callback verify, No hangup, Callback line, CallBack Rotary is not supported in ISE. Unique name required. Recommend using a prefix for Device admin Authorization Results.
Policy Elements ➡ Device Administration ➡ Command Sets	Work Centers ➡ Device Administration ➡ Policy Results ➡ TACACS Command Sets	Unique name required.

Access Policies

ACS 5 Element	ISE Element	Exceptions and Fixes
Access policies ➡ Access Services with external proxy + Service selection rule with Proxy Service	TACACS+: Work Center ➡ Device Admin Policy Sets + Proxy Sequence + Proxy server sequence. RADIUS: Policy ➡ Policy Sets ➡ Authentication policy
Access policies ➡ Access Services ➡ Allowed protocols	Policy ➡ Policy Elements ➡ Results ➡ Authentication ➡ Allowed Protocols
Access policies ➡ Access Service Service Selection rule Identity rule Authorization rule Group mapping	Device Admin Policy Sets Policy set criteria Authentication policy Authorization Policy	Policy model difference. Group mapping not supported in ISE. See 1 for more details. ISE 2.0 through ISE 2.2 does not support rule condition that has different operators. See Appendix D for information on supported rule elements. Cleanup the Authorization rule conditions in ACS to eliminate combination (AND and OR).
Policy Elements ➡ Max User Sessions	-	Not Supported in ISE 2.0 and ISE 2.1.

Note: Group mapping and additional attribute can be configured in ISE post migration by creating new condition (advanced option) in the authorization policy inside Device Admin policy Set. To do that, please make sure to add Microsoft Active Directory from Administration Identity Management External Identity sources. You can add up to 50 domains in ISE. Go to groups tab and attributes tab to download groups and attributes from AD (or external ID store) to be used in the conditions inside authorization policy.

Monitoring and Reporting

ACS 5 Element	ISE Element	Exceptions and Fixes
Monitoring and Reports ➡ Launch Monitoring and Report viewer	Operations ➡ RADIUS, Operations ➡ TACACS+, Operations ➡ Reports	Migration not supported

System Administration

ACS 5 Element	ISE Element	Exceptions and Fixes
System Administration ➡ Configuration ➡ Global System Options ➡ TACACS+ Settings	Work Center ➡ Device Admin ➡ Settings	None.
System Administration ➡ Operations ➡ Software repositories, System Administration ➡ Operations ➡ Distributed system information	Administration ➡ System ➡ Maintenance ➡ Repository Administration ➡ System ➡ Deployment ➡ Deployment	Migration not supported
System Administration ➡ Operations Scheduled Backups	Administration ➡ Sytem ➡ Backup and Restore	Migration not supported
System Administration ➡ Administrators ➡ Accounts, Roles and Administrators settings	Administration ➡ System ➡ Admin Access ➡ Administrators, Authentication, Settings	Migration not supported
System Administration ➡ Configuration ➡ Local Certificates	Administration ➡ System ➡ Certificates ➡ Certificate Management ➡ System Certificates	Migration not supported
System Administration ➡ Configuration ➡ Log Configuration	Administration ➡ System ➡ Logging	Migration not supported
System Administration ➡ Configuration ➡ Dictionaries ➡ Identity users, Hosts	Policy ➡ Policy Elements ➡ Dictionaries ➡ Users Policy ➡ Policy Elements ➡ Dictionaries ➡ Systems ➡ Endpoints	Identity and host attributes that are of type date are not supported in ISE. This is supported in ISE 2.3. Identity Dictionary attribute Maximum length, default value, Mandatory fields, Add policy condition and Policy condition display name not supported in ISE.
System Administration ➡ Configuration ➡ Dictionaries ➡ Protocols ➡ RADIUS RADIUS IETF System Administration ➡ Configuration ➡ Dictionaries ➡ Protocols ➡ RADIUS VSA	Policy ➡ Policy Elements ➡ Dictionaries ➡ System ➡ RADIUS ➡ RADIUS IETF Policy ➡ Policy Elements ➡ Dictionaries ➡ System ➡ RADIUS ➡ RADIUS VSA	Not migrated. Only RADIUS VSA not in ISE will be migrated.

If your configuration object is not in the list above, here is the complete list of data mapping of objects that are supported for migration between ACS and ISE 2.0. Please get familiarized with this so as to understand the gaps and results during and after the migration process.

Staging Environment for Migration

Create separate instance of ACS server for staging the migration to perform tests in the lab and necessary changes in the configuration. In this case, all changes will be done in that staging environment and will not affect production environment.

Note: Remember that when doing backup/restore of ACS, the restore process carries over system certificates to the staging server.

Install ISE server in standalone mode using the instruction here . The migration process will be successful with a clean installation on a standalone ISE node with bootstrap configuration. It is recommended to take a clean ISE configuration backup of the default configuration state in case the migration process is disrupted during the import process.

It is highly recommended to use staging environment to test resulted configuration. If lab environment allows ISE 2.x should be connected to external ID store such as LDAP or AD then test authentication/authorization request to see that ISE 2.x performs basic functionality as expected. Please also download the AD/LDAP groups and attributes used in your existing ACS configuration.

Migration Tool Requirements

Migration tool is a separate tool available for download on each ISE web interface from the Device admin work center. You can download the migTool.zip file in the following ways.

• By entering the following URL on the browser address bar: of ISE >/admin/migTool.zip
• Alternately, you can navigate to the Work Centers ➡ Device Administration ➡ Overview page, and click the migration tool in the Prepare section to download the migration tool.
• Migration tool requires specific version of the migration tool for specific ISE versions. If you are using ISE 2.2 and above, please go to the software download center for the specific version of ISE and download the migration tool.

This is aimed to assist with configuration migration from ACS 5.5+ to ISE 2.x. Migration tool is supported in both Windows and Linux machines. For large deployment please make sure you have 2GB RAM and 1 GB hard disk to run the migration. Migration Tool uses Java run-time executable (JRE7 and not below) and libraries and can be run on supported Windows and Linux platform.

Installation and configuration of the Migration Tool

The Migration Tool establishes secure communication to ACS, for exporting configuration and to ISE for importing configuration. For that purpose, migration tool uses system/local certificates (for self-signed certificates) or root CA certificates (for CA signed certificates) that have to be exported from ACS 5 and from ISE 2.0.

1. After downloading the tool save it to a local folder on your Windows machine, migration tool need to be unzipped into empty working folder where it will have its folder structure for binaries, logs and configuration files.
2. Edit the config.bat file to set the initial amount of memory allocated for the java Heap Sizes. (Set the initial amount of memory allocated for the java Heap Sizes for the migration process in the config.bat file. The attribute to set the heap size in config.bat is: _Xms = 64 and _Xmx = 1024 (The memory is 64 and 1024 megabytes, respectively).
3. In ACS, the local certificate can be found in the UI when you go to System Administration ➡ Configuration ➡ Local Server Certificates ➡ Local Certificates. From the list of entries, the entry which has Protocol “Management Interface”, need to be exported.
   
   Note: Only certificate (not private key) need to be exported.
4. Browse ISE 2.x UI and go to system certificate by going to Administration ➡ System ➡ Certificates ➡ System Certificates. Observe the entry that has usage “admin”. This certificate need to be exported.
5. Copy the ISE and ACS trusted certificate on the Windows client machine running the tool. Click migration.bat from the migTool folder to launch the migration process. Click Yes to display a list of unsupported and partially supported objects. Click Close.
   
   Note: To run the migration tool please make sure that you use super admin credentials
6. Go to Settings ➡ Trusted Certificates, click Add, choose the root certificate to add, the certificate will appear in the list.
   Tip: The root CA certificate of the ACS server certificate that got restored in the staging ACS server needs to be added to the migration tool.
7. Enable the migration interface in ACS and ISE with the following commands from the CLI:
   From ACS CLI, Enter

   acs config-web-interface migration enable

   From ISE CLI, Enter:

   application configure ise

   Enter 11 for Enable/Disable ACS Migration.
   Enter Y
   
   
8. Migration tool uses DN host name (FQDN in ISE) to establish communication between itself and ACS or ISE, hence hostnames of ACS and ISE machines need to be DNS resolvable.
   Tip: Make sure to have a DNS entry for the hostnames for proper resolution. Remember to use the hostname and not the IP address in the tool dialog box while importing/exporting. This hostname should match the name in the server certificate.
9. If DNS resolution does not work, create an entry in the host file on your Windows machine. Please make sure the DN in the certificate matches the IP address and hostname entries in hosts file in your Windows machine (location: C:\Windows\system32\drivers\etc).
   
   Note: You might get an error message if any of the above are not complete. Please also make sure you have ACS service running with a compatible license.
   
   
   Warning: It is recommended to build dedicated temporary ACS machine for staging the migration. Please do not use the production environment.

Supported/Unsupported Objects for Migration

The migration tool will automatically migrate ACS 5 supported entities to the ISE 2.x. Here is a complete list of objects supported, not supported and partially supported. Please take time to get familiar with this.

There are unsupported/ partially supported list on key areas that appears as a dialog box when you start the tool. You can also find this when you click the Help menu from the tool. This does not cover logs, backup and other management areas. For a more complete listing please use the link above.

Preparation for Migration from Cisco Secure ACS, Release 5.5+

You must consider the following before you start migrating Cisco Secure ACS data to Cisco ISE:

• Migrate Cisco Secure ACS, Release 5.5+ configuration data only when the Policy Set mode in Cisco ISE, Release 2.0 is configured. Enable Policy set in ISE UI by browsing to Administration ➡ System ➡ Settings ➡ Policy sets

• Migrate on a fresh installation of Cisco ISE, Release 2.x.

• Generate one policy set per an enabled rule in the Service Selection Policy (SSP) and order them according to the order of the SSP rules.

We recommend that you do not change to Simple mode after a successful migration from Cisco Secure ACS. Because, you might lose all the migrated policies in Cisco ISE. You cannot retrieve those migrated polices, but you can switch to Policy Set mode from Simple mode.

Note: The service that is the result of the Service Selection Policy default rule in ACS becomes the default policy set in Cisco ISE, Release 2.0. For all the policy sets created in the migration process, the first matching policy set is the matching type.

It is important understand the differences between the Service selection policies in ACS and policy sets in ISE. The policy set migration guidelines provides a list of considerations as part of pre-migration to help migrate Access services and service selection rules from ACS to ISE.

Migration Process with Migration Tool

Migration tool is the heart of automatic migration. Migration can also be done manually or using import/export utilities. For simplicity, we discuss the automatic migration process in this document using migration tool. Here are some tips how to use on the migration tool UI. A screen shot of the migration tool is shown below.

• The Migrated objects will have main container such as Policy Elements etc. Please click on the container to open it to view the objects migrated.

• You can see that all the containers have a progress bar . The objects under the containers have a status bar in green showing the status of the import or export.

• The Count shows the number of object imported/exported.

• The Warnings and Errors count will appear if there is a warning or error during the import and export phase of the migration.

• By clicking on the error/warning count you can open the corresponding report.

• The Policy gap analysis report shows the gap analysis in the policies between ACS and ISE as part of import/ export process.

• The Import Reports and Export Reports button will open up the corresponding reports to understand and analyze errors/warnings during the import and export phase.

• The Settings tab is used for importing CA certificates and for default settings for migration. Please do not change the default settings unless absolutely necessary.

• Log console displays the activity log that includes tracks the tool process and issue warning/errors. This is stored in migration.txt file under the migTool folder.

Migration is an iterative process, consisting 3 phases, exporting configuration, gap analysis and finally the import process. The export process needs to be repeated since there may be exceptions and errors that will appear during exporting. Corrective actions need to be taken based on the exceptions that appear on the reports.

Exporting ACS Configuration

Warning: You cannot use NAT between the migration machine and the ACS 5.x server.

1. Please use the tables after step 9 to understand the types of the objects before exporting objects from ACS. Click ‘Export from ACS’ button to start the export.
2. Type in the ACS host name, admin user name and password, click Connect.
3. Observe the progress of exporting via progress bars per container and per individual objects. Time spent for export process greatly depends on configuration size and amount of entities to be exported.
   
   Note: Migration tool will export or import all the supported object once and lists the gaps, errors if an objects are not supported in ISE (or) if ISE already has the objects available (or) if the character set does not support it etc. You cannot stop the migration tool in-between. However you can exit out of it and it should start from where it stopped.
4. To get more information about a warning or an error that occurred during the export process, click any on the link under ‘Warnings’ or ‘Errors’ column on the Migrations tab. The ‘Object Errors and Warnings Details’ window displays the result of a warning or an error during export. It provides the object group, the type, and the date and time of a warning or an error.
5. Data export process may take long time depending the configuration. If you have a large number of network devices it (for e.g.: 15k it will take up to 4-5hours). When the data export process has completed, the Cisco Secure ACS to Cisco ISE Migration Tool window displays the status of export that Exporting finished.
   
   
   Note: It was observed that sometimes the progress bar across the objects shows complete but the export process status does not change to Export finished. In such case, please open the export report to see the status of the export at the bottom of the report to proceed.
6. Open the export report by clicking on the Export report(s) button as shown in the screenshot above. Export report will have information that will help do gap analysis.

Policy Gap Analysis

Upon export completion, administrator should analyze results by reviewing ‘Export Report”, “policy gap report”, fix listed errors in the ACS configuration and should re-run process ones again. When errors are fixed, warnings and other issues are addressed and understood, administrator should perform export once again and use the data for importing.

Important: Please make a copy of these reports every time you run the tool for comparison. The policy gap report gets overwritten when you run the import on the next step.

Note: Log files are stored in the “reports” sub-folder where migration tool running. This can be reviewed, archived and shared for auditing purposes. These are the files available to review export_report.txt, import_report.txt, policy_gap_report.txt. Please rename the policy_gap_report.txt file since this will be overwritten during the import process.

Here are some sample output from the export report showing name constraints on objects.

Note: This is specific to ISE 2.0/2.1. The migration tool for ISE 2.2+ automatically converts unsupported characters to supported characters in ISE

==========================================
Object Type: Users
==========================================
> 2016.01.27 18:24:56'561 : 'america\sample.adm' will not be exported because the name contains special characters or space that are not supported by ISE.
The valid name can contain alphanumeric and ~@# $&*_+.- characters
==========================================
Object Type: Certificate Authentication Profile
==========================================
> 2016.01.27 18:24:57'996 : 'CN Username' will not be exported because the name contains space or special characters that are not supported by ISE.
The valid name can contain alphanumeric and underscore(_)
Object Type: Network Devices
==========================================
> 2016.01.27 18:30:03'024 : 'sample.device.us' will not be exported because the name contains special characters that are not supported by ISE.
The valid name can contain alphanumeric, hyphen(-) and underscore(_)
=========================================
Object Type: Authorization Profiles
==========================================
> 2016.01.27 18:30:49'605 : 'DenyAccess': will not be exported because it is predefined in ISE.
> 2016.01.27 18:30:49'621 : 'Deny Access' will not be exported because the name contains special characters that are not supported by ISE.
The valid name can contain alphanumeric, space and !@#$%&()-_+{};'<>.?/~ characters

Note: During the policy export, the migration tool will provide this information in the policy gap analysis report. Object Names that are not compatible with ISE 2.0/ISE 2.1 will not be processed. Hence import policies and rules may not be possible, partial configurations are not allowed.

For parity gaps observed per configuration set between ACS and ISE. Reconciliation is possible for some of these, for others alternate method needs to be chosen. Please see the tables from Step 9 for details to fix the parity gaps. Future versions of ISE is expected to close the gap. Here is the sample behavior for Network Devices/ Network Device Groups below during reconciliation.

Network Devices and Network Device Groups

Reconciliation flow for Migration Tool

• If Device does not exist in ISE (Defined by no overlap of IP configuration)
• Then it will be added during migration.
• If Device does exist (IP/subnet exactly matches) and (name exactly matches)
• Then migration will updates detail to add TACACS+ elements
• If only approximate match. (name matches exactly, or IP/subnet matches exactly, but not both)
• Then migration tool reports error.

Warning: The migration tool migrates all the policies when they are compatible. However, it will not migrate any of the policies if one or more are incompatible. Please make sure to fix all the access policies for error by analyzing the policy gap report.

Once the errors/warnings are reviewed and corrected start the export process once again. Go back to the Exporting configuration: section above. Start the export process again. Go through the Policy gap analysis and make sure that it is clean after looking at all exceptions and go the next step.

Importing ACS Configuration

1. Administrator should connect to target ISE 2.x using FQDN and should start import configuration into ISE. Click on “Import to ISE” button from the screenshot above to start the import. During importing, the migration tool will create a report that can be opened from the menu. Generally, if ACS configuration is clean, import process does not produce any errors.
2. In the LDAP Identity Store drop-down list, select the identity store to which you want to add attributes, and click Add Attribute. These attributes will be imported from the ID store during migration. Alternatively, you can Cancel it to skip adding LDAP attribute. Skip the next step and go the following step to proceed further.
3. Enter a name in the Attribute Name field, choose an attribute type from the Attribute Type drop-down list, enter a value in the Default Value field, and click Save & Exit.
4. When you have finished adding attributes, click Import to ISE, enter the Cisco ISE Fully Qualified Domain Name (FQDN), username, and password in the ISE Credentials window and click Connect. The migration tool checks that the Hostname/FQDN matches the CN in the SSL certificate. You will see an error if does not match. Please make sure your DNS hostname of ISE is the same as CN of the certificate being used.
5. Data import process will take time to complete depending on the configuration. When the data import process has completed, the Cisco Secure ACS to Cisco ISE Migration Tool window displays the status of import that Importing finished.
6. To view a complete report on the imported data, click Import Report(s).
7. To get more information about a warning or an error that occurred during the import process, click any underlined numbers in the Warnings or Errors column on the Migrations tab.
8. To analyze the policy gap between Cisco Secure ACS and Cisco ISE, click Policy Gap Analysis Report.
9. At any time, click View Log Console to display a real-time view of the export or import operations.

Warning: If you have multiple deployments of ACS and are merging to ISE then migration tool will only add configuration not merge with the exception of Network devices. Even for Network devices if there are two separate deployments one for RADIUS and another for TACACS+, migration tool will add configuration to the same entry. This may change in the future. It is highly recommended to start import on clean ISE configuration.

Upon completion, it is necessary to review results in ISE 2.x UI for consistency and integrity. All policies have to be based on existing rules, which, in turn should create existing and logically sound results, for e.g. shell profiles, commands sets and authorization profiles.

Note: It is highly recommended to check policy’s order and security logic at this point and change it in ISE. More specific policies for e.g., analyzing specific user names usually allow access, default policies usually deny assess.

Once the migration is complete and successful, and take an ISE backup of all the configuration imported from ACS and name it suitably.

Verifying Migration of Access Policies

Migrating policies is a most important and crucial phase of the whole process. While translating policies from ACS to ISE user need to take into considerations following:

ACS has so called “Service Selection Rule(s)” and “Service Selection Policies” which are not present in ISE. ISE 2.x has “Policy sets” and rules under that are automatically created while migration from ACS to ISE. Picture below shows mapping between ACS “Service Selection Policies” and ISE “Policy Set”.

On the screenshot below, Rule1 represents Service Selection Rule which is matching RADIUS protocol used in “Radius Authentication” service.

Rule 1 from the Service selection policy will be migrated to Policy ➡ Policy Sets as new Policy Set for RADIUS(observe the screenshot below). Rule 2 will be migrated to Work Center ➡ Device Administration ➡ Device Admin policy sets in TACACS+ work center as shown below.

In ACS, Service Selection policy will result in an access service. For e.g., Rule 4 for TACACSAMERICAS from screenshot above resulted in “PA-AMERICAS Network Device” as access service. Every access services consists of two parts, Identity and Authorization. As an example we see how Rule 4 from screenshots above was migrated from ACS to ISE.

Identity Rule in ACS

Authorization Rule in ACS.

Next screenshot from ISE 2.0 will show how ACS rules translated into ISE Policy Sets after migration.

This example was sample of real world configuration, though same idea will be applied to set of rules of any complexity.

RADIUS Access policies: RADIUS access policies can be verified the same way however for RADIUS flows the policy will have a different Network access protocol. Authorization policy shown in the screenshot above will be mapped to Authorization profile instead of command sets and Shell profiles. From ISE UI, please go to Policy ➡ Policy Sets for this.

External Proxies: When adding an external proxy server or verifying the configuration. Here are the steps

For RADIUS

1. Create/verify external RADIUS server configuration by visiting Administration ➡ Network Resources ➡ External Radius Server from ISE UI.
2. Verify that the Access Services selection for service type external proxy in ACS are migrated to Administration ➡ Network Resources ➡ RADIUS Server Sequences in ISE. In ACS, you have go to Access services and click on the external proxy policy for the configuration.
3. Verify that the Service Selection Rules from ACS for external proxy is migrated to Policy ➡ Policy Sets in ISE. Adding proxy sequence is part of the authentication policy in ISE UI. You can create one by editing authentication policy, clicking on “Allowed protocols” drop down for the authentication policy, click RADIUS Server sequence and select the correct name.
   
   

For TACACS

1. Verify the external TACACS server and TACACS+ Server sequences has entries by browsing ISE UI , go to Work Centers ➡ Device Administration ➡ Network Resources. Check that the Access Services Selection for service type external proxy in ACS is migrated to TACACS+ Server sequences.
2. For TACACS+ proxy sequence, go to Work Centers ➡ Device Administration ➡ Policy Sets under the policy set criteria. Make sure the Proxy sequence is selected and the correct TACACS+ Server sequence entry is selected from the dropdown.
   

Supporting Chatty Devices (TACACS+ single connect)

“Single connect” feature in ISE has two modes RFC standard and (compatibility) mode. When ‘single connect’ feature is turned on per device, it will negotiate, sustain TCP connection and will pass multiple TACACS+ transactions to ISE. Such connection will stay considerably longer than regular TCP connections. This will help “chatty” devices pass-through TACACS+ transactions once a connection is established and the TCP link is sustained in a most effective way. Other devices where this option is not turned on will establish TCP link by demand. This will help “chatty devices” in getting higher preference during high load condition.

During upgrade preparation, network administrator should create a list of most active Network devices (NAS’s), ACS can provide such reports and statistics – this list may contain up to several thousand devices. It is recommended to make those NASs to talk to ISE PSN with TACACS+ single connect enabled. Rest of the NASs will not use single connect.

1. You have to login to ISE UI, browse to Work Centers ➡ Device Administration ➡ Network Resources ➡ Network Devices and go to TACACS+ authentication settings to enable this per device.
   
   
   
   Note: It is very important to estimate number of simultaneous connections that might be established to single ISE PSN in order to avoid TCP socket starvation.

2. This is post-migration activity to improve TACACS + efficiency for chatty devices. Create a list of chatty network devices and enable single connect mode for them with the TACACS+ draft option enabled as shown in the screenshot above.

3. ISE allows you to export and import “Network devices” list. Export the existing network device list as a csv file. Open the csv file in Microsoft Excel or other spreadsheet supporting software.

4. Change the values of the column ‘TACACS:Connect Mode Options:String (OFF|ON_LEGACY|ON_DRAFT_COMPLIANT)’ for the list of chatty devices to “ON_DRAFT_COMPLIANT”. Save the file as csv.

5. Import this csv to ISE. The export and import process takes time depending the number of network devices. Please be patient while importing or exporting large sets of devices.

6. Take an ISE backup of all the configuration imported from ACS and name it suitably. ISE configuration can be restored into production with backup/restore process in ISE software. While doing this please make sure the ISE versions and patch level are the same in your staging and production system.
   
   

   Note: For CA signed certificates, please make sure you create the server certificates in advance based on the number of servers including PAN, MnT and PSN’s.

Final Steps

1. Once the ISE server (PAN) is in production, install additional nodes (MnT and PSN’s) and allow it to replicate.

2. Change the TACACS+ and/or the RADIUS configuration on few Network devices to point to ISE server (Policy Services Node) in normal business hours for a few days. Observe for any inconsistencies before changing the configuration settings on the next set of network devices. Please move the network devices from ACS to ISE in batches to avoid disruptions.

3. Once you successfully moved all the network devices to the ISE server, monitor your daily log size for TACACS+ until you move all the network devices for first two months to tune it based on the traffic needs. Visit the ‘What happens if my logging requirements exceeds the example?’ section of this document for recommendation on log size considerations.

You have now completed Migration from ACS to ISE!

Appendix A: ACS vs ISE Deployment Limits

The table below provides the scalability limits of ACS 5.x vs ISE 2.x for planning the ISE deployment.

<th">ISE 2.2 Limits<td">54(2 PANs, 2 MnTs, 50 PSNs)<td">500,000 concurrent sessions(not specific to Endpoint or Users)1.5M Total endpoints<td">300,000 Internal Users<td">-<td">-<td">500(User), 500(End-point ID)<td">50<td">1000<td">100,000<td">100(10k in ISE 2.3)<td">- (6 in ISE 2.3)<td">-<td">100(Simple mode)200( Policy set mode - 2 rules + default)<td">600 (Simple mode)700 ( Policy set mode)<td">8<td">600<td">100(Policy sets)<td">N/A<td">8000ACL’s<td">4,000<td">2,500<td">500,000/deployment ( 2 SXPSNs)

Attributes	ACS 5.x Limits	ISE 2.0 Limits	ISE 2.1 Limits
Nodes	22	44 (2 PANs, 2 MnTs, 40 PSNs)	54(2 PANs, 2 MnTs, 50 PSNs)
Endpoints	150,000	250,000 concurrent endpoints 1 M total endpoints	500,000 concurrent sessions(not specific to Endpoint or Users) 1.5M Total endpoints
Users	300,000	25,000 Internal Users 1 million Internal Guests	300,000 Internal Users
Admins	50	-	-
Admin Roles	9	-	-
Identity Groups	1,000	500(User), 500(End-point ID)	500(User), 500(End-point ID)
Active Directory Join Points	1 join point per node	50	50
Active Directory Group Retrieval	1,500	1000	1000
Network Devices	100,000 150,000(35xx)	30,000 (network objects not IP’s)	100,000
Network Device Groups	10000	100	100
Network Device Hierarchies	6	-	-
Services	25	-	-
Authentication Rules	-	100	100
Authorization Rules	320	600 (<100 recommended)	600
Conditions	8	8	8
Authorization Profile	600	600 ( < 100 recommended)	600
Service Selection Policy (SSP)	50	N/A	40(Policy sets)
Network Conditions (NARs)	3,000, 10000 (ACS 5.8.1)	N/A	N/A
dACLs	600 dACL with 100 ACEs each	8000ACL’s	8000ACL’s
TrustSec Security Group Tags (SGT)	-	4,000	4,000
TrustSec Security Group ACLs (SGACLs)	-	2,500	2,500
Maximum number of SXP bindings	N/A	100,000	500,000

Appendix B: TACACS+ Performance per ISE Deployment

Dedicated TACACS+ Only Deployment

Max Concurrent TACACS+ Sessions/TPS by Deployment Model and Platform

Deployment Model	Platform	Max # Dedicated PSNs ( # recommended)	Max RADIUS Endpoints per Deployment	Max T+ Sessions/TPS (TPS for recommended PSN’s)
Standalone (all personas on same node) (2 nodes redundant)	3415	0	N/A	500
	3495	0	N/A	1,000
	3515	0	N/A	1,000
	3595	0	N/A	1,500
Basic Distributed: Admin + MnT on same node; Dedicated PSN (Minimum 4 nodes redundant)	3415 as Admin+MNT	**5 (2 rec.)	N/A	2,500 (1,000)
	3495 as Admin+MNT	**5 (2 rec.)	N/A	5,000 (2,000)
	3515 as Admin+MNT	**5 (2 rec.)	N/A	* 5,000 (2,000)
	3595 as Admin+MNT	**5 (2 rec.)	N/A	* 7,500 (3,000)
Fully Distributed: Dedicated Admin and MnT nodes (Minimum 6 nodes redundant)	3495 as Admin and MNT	**40 (2 rec.)	N/A	20,000 (2,000)
	3595 as Admin and MNT	**50 (2 rec.)	N/A	*25,000 (3,000)

*Under ISE 2.0.x, scaling for small and large 35x5 appliance same as small and large 34x5 appliance.

** Device Admin service can be enabled on each PSN; minimally 2 for redundancy, but 2 often sufficient.

Red indicates TPS that will cause performance hits on MnT and is not recommended.

Scaling per PSN	Platform	Max RADIUS Endpoints per PSN	Max T+ Sessions/TPS
Dedicated Policy nodes (Max Endpoints Gated by Total Deployment Size)	SNS-3415	N/A	500
	SNS-3495	N/A	1,000
	SNS-3515	N/A	* 1,000
	SNS-3595	N/A	* 1,500

Shared deployment (RADIUS + TACACS+):

Integrated PSNs: PSNs that share RADIUS and TACACS+ service and sharing same Admin + MnT node.

Dedicated PSNs: PSNs that are dedicated for RADIUS only or TACACS+ only service sharing same Admin + MnT.

Max Concurrent RADIUS Sessions / TACACS+ TPS by Deployment Model and Platform

Deployment Model	Platform	Max #PSNs: Integrated / Dedicated PSNs( Radius + TACACS+)	Max RADIUS Endpoints per Deployment	Max TACACS+ TPS (Integrated / dedicated T+ PSNs)
Standalone (all personas on same node) (2 nodes redundant)	3415	0	5,000	50
	3495	0	10,000	50
	3515	0	7,500	50
	3595	0	20,000	50
Basic Distributed: Admin + MnT on same node; Integrated / Dedicated PSNs (Minimum 4 nodes redundant)	3415 as Admin+MNT	**5 / 3+2	5,000	100 / 500
	3495 as Admin+MNT	**5 / 3+2	10,000	100 / 1,000
	3515 as Admin+MNT	**5 / 3+2	7,500	* 100 / 1,000
	3595 as Admin+MNT	**5 / 3+2	20,000	* 100 / 1,500
Fully Distributed: Dedicated Admin and MnT nodes; Integrated / Dedicated PSNs (Minimum 6 nodes redundant)	3495 as Admin and MNT	**40 / 38+2	250,000	1,000 / 2,000
	3595 as Admin and MNT	*50* / 48+2	500,000	* 1,000 / 3,000

** Device Admin service enabled on same PSNs also used for RADIUS OR dedicated RADIUS and T+ PSNs.

* Under ISE 2.0.x, scaling for Small and Large 35x5 appliance same as Small and Large 34x5 appliance.

Scaling per PSN	Platform	Max RADIUS Endpoints per PSN	Max TACACS+ TPS
Dedicated Policy nodes (Max Endpoints Gated by Total Deployment Size)	SNS-3415	5,000	500
	SNS-3495	20,000	1,000
	SNS-3515	7,500	1,000
	SNS-3595	40,000(ISE 2.1+)	1,500

Appendix C: ISE VM Sizing and Log retention

Note: ISE 2.0 allows 50% allocation for logging for both RADIUS and TACACS+. ISE MnT requires purging at 80% capacity. For e.g.: If you have a 600G hard disk, 480G of hard disk will be the effective hard disk space with purging. Out of the 50% total allocation, 20% allocation is for TACACS+ and 30% is for RADIUS logs.

TACACS+ guidance for size of syslogs:

Message size per TACACS+ Session	Message Size per Command Authorization (per session)
Authentication: 2kB	Command Authorization: 2kB
Session Authorization: 2kB	Command Accounting: 1kB
Session Accounting: 1kB

TACACS+ transactions, logs and storage

Human Administrators and Scripted device administrator (Robot) model

	Session Authentication and Accounting Only	Command Accounting Only (10 Commands / Session)	Auth. + Session + Command Authorization + Accounting (10 Commands / Session)
	Avg TPS	Peak TPS	Logs/ Day	Storage/ day	Avg TPS	Peak TPS	Logs/ Day	Storage/ day	Avg TPS	Peak TPS	Logs/ Day	Storage/ day
# Admins	Based on 50 Admin Sessions per Day – Human Admin model
1	< 1	< 1	150	< 1MB	< 1	< 1	650	1MB	< 1	<1	1.2k	2MB
5	< 1	< 1	750	1MB	< 1	< 1	3.3k	4MB	< 1	<1	5.8k	9MB
10	< 1	< 1	1.5k	3MB	< 1	< 1	6.5k	8MB	< 1	1	11.5k	17MB
25	< 1	< 1	3.8k	7MB	< 1	1	16.3k	19MB	< 1	2	28.8k	43MB
50	< 1	1	7.5k	13MB	< 1	2	32.5k	37MB	1	4	57.5k	86MB
100	< 1	1	15k	25MB	1	4	65k	73MB	2	8	115k	171MB
# NADs	Based on 4 Scripted Sessions per Day – Scripted Device Admin model
500	< 1	5	6k	10MB	< 1	22	26k	30MB	1	38	46k	70MB
1,000	< 1	10	12k	20MB	1	43	52k	60MB	1	77	92k	140MB
5,000	< 1	50	60k	100MB	3	217	260k	300MB	5	383	460k	700MB
10,000	1	100	120k	200MB	6	433	520k	600MB	11	767	920k	1.4GB
20,000	3	200	240k	400MB	12	867	1.04M	1.2GB	21	1.5k	1.84M	2.7GB
30,000	5	300	360k	600MB	18	1.3k	1.56M	1.7GB	32	2.3k	2.76M	4.0GB
50,000	7	500	600k	1GB	30	2.2k	2.6M	2.9GB	53	3.8k	*4.6M	6.7GB

*Red indicates logs/ day that will cause performance hits and slowness in log processing.

TACACS+ log retention (# of days):

Please see the static tables below for easy use. If you are an advanced user and would like to customize number of commands/sessions etc., please use the ISE MnT Log sizing calculator for TACACS+ and RADIUS .

Scripted device admin model

Number of sessions per day: 4

Number of commands: 10

Message Size /session (KB) = 5kB + Number of commands/session *3kB

Automated access(single script) log size calculation = n Number of devices * 4 Sessions * Message size

E.g. : Log Size for 30k Network devices = 4GB/day

ISE 2.1(20% allocation):

# of Network Devices in the deployment	MnT Disk Size(GB)
	200	400	600	1024	2048
500	480	959	1439	2455	4909
1000	240	480	720	1228	2455
5000	48	96	144	246	491
10000	24	48	72	123	246
20000	12	24	36	62	123
30000	8	16	24	41	82
50000	5	10	15	25	50

ISE 2.2 (60% disk allocation):

# Network Devices	200 GB (days)	400 GB (days)	600 GB (days)	1024 GB (days)	2048 GB (days)
100	12,583	25,166	37,749	64,425	128,850
500	2,517	5,034	7,550	12,885	25,770
1,000	1,259	2,517	3,775	6,443	12,885
5,000	252	504	755	1,289	2,577
10,000	126	252	378	645	1,289
25,000	51	101	151	258	516
50,000	26	51	76	129	258
75,000	17	34	51	86	172
100,000	13	26	38	65	129

Human admin – device admin using sample number of sessions and commands shown below.

Number of sessions: 50

Number of Commands/session: 10

Message Size /session (KB) = 5kB + Number of commands/session *3kB

Manual access log size calculation = 50 Sessions * N Admins * Message size

E.g. : Log Size for 50 admins = 85.4MB/ day

Number of Admins\ Disk Size(GB)	MnT Disk Size (GB)
	200	400	600	1024	2048
5	3835	7670	11505	19635	39269
10	1918	3835	5753	9818	19635
20	959	1918	2877	4909	9818
30	640	1279	1918	3273	6545
40	480	959	1439	2455	4909
50	384	767	1151	1964	3927

RADIUS Log retention (# of days)

Number of Authentications per day per endpoint: 100

Custom Disk Size (GB): 500

Max. Allocated MnT Tablespace (GB): 120

Message size per Auth. (KB): 4

Log Size/day: Number of Endpoints * 10 auth./day * Message Size

ISE 2.1 – (30% disk allocation)

Number of Endpoints	MnT Disk Size (GB)
	200	400	600	1024	2048	Custom
10,000	126	252	378	645	1,289	315
20,000	63	126	189	323	645	158
30,000	42	84	126	215	430	105
40,000	32	63	95	162	323	79
50,000	26	51	76	129	258	63
100,000	13	26	38	65	129	32
150,000	9	17	26	43	86	21
200,000	7	13	19	33	65	16
250,000	6	11	16	26	52	13

Note: Above values are based on controlled criteria including event suppression, duplicate detection, message size, re-authentication interval, etc. and result may vary depending on the environment.

ISE 2.2 – (60% disk allocation)

Total Endpoints	200 GB (days)	400 GB (days)	600 GB (days)	1024 GB (days)	2048 GB (days)
5,000	504	1007	1510	2577	5154
10,000	252	504	755	1289	2577
25,000	101	202	302	516	1031
50,000	51	101	151	258	516
100,000	26	51	76	129	258
150,000	17	34	51	86	172
200,000	13	26	38	65	129
250,000	11	21	31	52	104
500,000	6	11	16	26	52

Appendix D: Unsupported Rule Elements

Cisco Secure ACS and Cisco ISE are based on different policy models, and there is a gap between pieces of Cisco Secure ACS data when it is migrated to Cisco ISE. When Cisco Secure ACS and Cisco ISE release versions change, not all Cisco Secure ACS policies and rules can be migrated due to:

Unsupported attributes used by the policy

Unsupported AND/OR condition structure (mainly, once complex conditions are configured)

Unsupported operators

Rule Elements	Status of Support	Description
Date and Time	Supported in ISE 2.3	Date and time conditions in an authorization policy that have a weekly recurrence setting, are not migrated to Cisco ISE. As a result, the rules are also not migrated.
Date and Time	Supported in ISE 2.3	Date and time conditions in an authentication policy are not migrated to Cisco ISE. As a result, the rules are also not migrated.
In	Supported	The "In" operator is converted to STARTS_WITH.
Not In	Supported	The "Not In" operator is converted to NOT_STARTS_WITH.
Contains Any	Supported	The "Contains Any" operator is converted to a compound condition with EQUALS & OR operators. Example: In ACS, AD ExternalGrp Contains Any (A, B) is converted to (AD ExternalGrp Equals A) OR (AD ExternalGrp Equals B) in Cisco ISE.
Contains All	Supported	The "Contains All" operator is converted to a compound condition with EQUALS & AND operators. Example: In ACS AD:ExternalGrp contains all A;B is converted to (AD ExternalGrp Equals A) AND (AD ExternalGrp Equals B) in Cisco ISE.
Combination of logical expressions	Supported in ISE 2.3	Rules that use these operators in their conditions are not migrated: Authentication policies that include compound conditions that have different logical expressions other than a || b || c || … and/or a && b && c && … such as (a || b) && c. Authorization policies that include compound conditions that have different local expressions other than a && b && c && are not migrated as part of the rule condition. Workaround: You can manually use library compound conditions in ISE for some advanced logical expressions. You can also split the compound condition such as (a || b) && c to two simpler rules with a || b and c.
Network conditions	Supported in ISE 2.2	Rules that include only network conditions are not migrated. In case the condition includes network conditions and other supported conditions, the network conditions are ignored and are not migrated as part of the rule condition. Workaround: Can use authorization condition for the attributes.
User attributes	Partially Supported	Rules with conditions that include user attributes with a data type other than the “String” data type are not migrated.
Host attributes	Not Supported	Authentication fails in case the condition refers to host attributes. Authorization policies that include a condition that has host (endpoint) attributes are not migrated to Cisco ISE authorization policies. Please see supported attributes and data types for additional information on User, Host and Radius attributes.

[dparmako]

I am trying to migrate a config from AC 5.8.1. to ISE 2.2. The migration tool starts exporting the ACS config OK, but then it hangs forever at "Predefined Reference Data", after counting to some 560 objects.

What I am doing wrong here ?

[kthiruve]

HI Dragan,

Hoping that this was resolved. Just for the sake of clarity I am answering the question.

"Predefined reference data" takes a long time if you have large number of users and devices. I have covered this in the Part 3 of ACS to ISE Migration videos in the following community page ACS to ISE Migration.

Please ask your questions in ISE or ACS communities in future so that we can track this.

http://cs.co/ise-community

Thanks

Krishnan

[Johnny Leon]

Customer would like to migrate from ACS5.6 to ISE2.x.  Customer ACS deployment is with an SNS-3415 appliance.  Request is to upgrade to ISE2.x but maintaining the SNS-3415.  Is this supported?  If yes, what licensing migration SKU's can I use?  If no, what are my options?

Please advice.  Thank you.