Well, we have good news and bad. The bad news is Cisco ACS is end-of-sale, end-of maintenance, and end-of-support. In other words, if you still have ACS running in production, you came to the right place. The good news is, the TACACS+ functionality or aka Device Administration in ISE speak, is fully supported in ISE. The even better news is the functionality is infinitely easier to configure and understand in ISE.
Of course, the first question is typically what does ISE support? The answer is, simply, just about everything ACS did and then some.
Cisco ISE and Cisco Secure ACS Parity
Cisco ISE introduces the following features to achieve parity with Cisco Secure ACS.
Disable user account if the configured date exceeds a specific period for individual users
Disable user account if the configured date exceeds a specific period for all the users globally
Disable user accounts after n days of configuration globally
Disable user accounts after n days of inactivity
Support for IP address range in all the octets for the network device
Configuration of network device with IPv4 or IPv6 address
Configuration of external proxy servers with IPv4 or IPv6 address
Support for maximum length of Network Device Group (NDG) name
Support for time and date conditions
Support for service selection rules, authentication rules, and authorization (standard and exception) rules with compound conditions having AND and OR operators
MAR configuration in Active Directory
Dial-in attribute support
Enable password change for LDAP
Configuration of primary and backup LDAP server for each PSN
Configuration of RADIUS ports
Authorization profile configured with dynamic attribute
Two new values for the service-type RADIUS attribute
Increased internal user support for 300,000 users
Internal users’ authorization cache
Authenticate internal users against external identity store password
Dictionary check for passwords of admin user and internal user
Crytobinding TLV attribute support for allowed protocols
Use of length included flag while performing EAP-TLS authentication against a Terminal Wireless Local Area Network Unit (TWLU) client
Common Name and Distinguished Name support for Group Name attribute for LDAP Identity Store
The big ones are both RADIUS and TACACS+ authentication, support for nearly every platform that supports either protocol, full command level authorization, or support for many GUI based devices. The bottom line is really, if you have a device running, we can get it working with ISE.
ISE Device Administration Licensing
In addition to the Base License requirements, to use TACACS+ you also require a Device Admin License for each node that will service Device Admin requests. The decision on which nodes will also run the Device Administration persona typically comes down to design. If you have a medium sized business in a single geographical region, two nodes will typically suffice. If you are a large business with many offices and data centers around the world, you would typically prefer to have one or more TACACS+ nodes in each region.
Device Administration Configuration
It takes a bit of getting used to, but if you are currently working with ACS, this will be a walk in the park.
The first step is to enable the service on the individual PSNs. Here is a basic example on a single-node lab environment:
This screen provides you with an overview of the steps required to get TACACS+ working properly.
Step 1: Prepare
When in the prepare step, you have to think about how you want to organize your policies, whether or not you are migrating from ACS, and enabling the PSNs.
Profiles: A profile dictates a few general settings that will be applied to a group of users. In a Cisco deployment, for example, you would typically set the privilege level of the devices. For example:
Command Sets: A command set lists the commands a user or group of users can run on the device. You can design your policy to either deny everything you don’t want and permit the rest, or Permit everything you want and deny the rest. Rules are run top-down until a match is made, so be careful if you have both Permit and Deny statements in the same Command Set. Best practice is to permit what you want and deny the rest.
Step 2: Define
During the Define phase, you configure the devices that will be managed, configure the users that will manage the devices, tie it all together in a policy, and wrap-up with some general settings.
If you are already using ISE for NAC, there won’t be any surprises here. The same process you used for RADIUS; you use for TACACS+. We simply have to give each device a name, IP Address, and a TACACS+ shared secret.
There are three ways to go.
Active Directory: You can utilize AD Groups to group your engineers by function. For example, you can say anyone in the AD Group “Cisco-Engineers” gets the “Cisco_Admins” ISE profile and associated command set.
Local: If you would rather not use AD, you can configure local accounts for TACACS+.
Hybrid: You can also take a hybrid approach and create local users in ISE but point to Active Directory for the password. This way you can maintain strict control of ISE “in-house”, but gain the advantages and policies of your corporate AD.
A policy is essentially an IF/Then/Else statement. In the following example, we are saying:
IF the device is a switch AND the user is in an AD Group named “Net-Admin”, THEN assign the command set Cisco_Permit_All AND the shell profile “Cisco_Admins” ELSE go to the next line.
The final “Define” dialog is for general settings. There are several customizable settings to match internal policy:
Go Live & Monitor
Now everything is setup, and the deployment is completely ready to go. Next steps include viewing the real-time TACACS+S Log which will show every successful/failed authentication as well as every successful/failed command authorization request.
In addition, you can run ad-hoc or scheduled reports to get a birds-eye view of every configuration change that has taken place on your network, and who did it! There are several default reports:
Migration from ACS
Cisco offers an automated tool that allows you to export your ACS configuration and import it into ISE. We at CDA are not huge fans of this process as it only actually saves time in extremely large deployments.
Instead, we typically take a hybrid approach using some automation and some manual processes. This approach allows complete control over what is being moved over to ISE and avoids moving the old junk to the new house. We encourage our customers to not think about what they have today, rather focus on exactly what they want tomorrow. From there, we inventory all devices (whether or not they existed in ACS), build profiles for each, document and deploy the user structure, and finally tie everything together in an easy-to-understand policy.
If you would like assistance with your Cisco ISE migration, contact us today!