Cisco ISE Device Administration Prescriptive Deployment Guide

[kthiruve]

Deploying Cisco ISE for Device Administration

This deployment guide is intended to provide the relevant design, deployment, operational guidance and best practices to run Cisco Identity Services Engine (ISE) for device administration on Cisco devices and a sample non-Cisco devices.

Author: Krishnan Thiruvengadam

For an offline or printed copy of this document, simply choose ⋮ Options > Printer Friendly Page. You may then Print, Print to PDF or copy and paste to any other document format you like.

Table of Contents

• Introduction
• About Cisco Identity Services Engine (ISE)
• About This Guide
• Define
• What is Device administration?
• What are the key elements of Device administration?
• How to plan your workflow for device administration?
• Identify context and privileges across identities
• Define Policy structure for device administration
• Solution deployment considerations
• What is Authentication, Authorization and Accounting (AAA)?
• User Application Consideration
• Automation tool consideration
• Network Device Considerations
• External Services Consideration
• ISE Deployment Models
• Simple Two Node Deployment
• Basic Distributed Deployment
• Fully Distributed Deployment
• How to avoid TACACS+ service failure at a location, site or region?
• Design
• Device Administration Model
• Design Options
• TACACS Deployment Scale
• Calculate the Number of Transactions per Second (TPS)
• Calculate Number of PSNs
• How to Size ISE Nodes for Maximum Log Retention
• Hardware and Software Requirements:
• Deploy
• ISE Configuration for Device Administration
• Bootstrapping
• Licensing Device Administration on ISE
• Enabling Device Administration on ISE
• Creating Internal or External Identities
• Using External Identity Sources for User identities
• Adding Active Directory join point
• Creating Network Devices and Network Device Groups
• Create Network Device Groups to classify Network Devices
• Create Network Devices for TACACS+ and add them to Network Device Groups
• Change your shared secret without network disruption
• Configure ISE as proxy to other TACACS+ Server
• Policy Elements
• Command Set syntax
• Device Admin Policy Sets
• What is a Policy set? How does it work?
• Authentication Policy
• Authorization Policy
• Cisco IOS – Switches/Routers
• Access Privileges via TACACS Profile
• TACACS Command Sets
• Policy sets; Conditions, Authentication and Authorization policy
• IOS Configuration for TACACS+
• Testing TACACS+ User Access to CSRv
• Troubleshooting TACACS+ User Access to CSRv
• Wireless Controllers – WLC
• Configuring TACACS Profiles
• Device Admin Policy Sets
• WLC Configuration for TACACS+
• Testing TACACS+ User Access
• Troubleshooting TACACS+ User Access
• Cisco Nexus Platform
• TACACS Profiles
• TACACS Command Sets
• Device Admin Policy Sets
• NX-OS Configuration for TACACS+
• Test and Troubleshoot User access for NX-OS
• Adaptive Security Appliance (ASA – VPN/Firewall)
• TACACS Profiles
• TACACS Command Sets
• Device Admin Policy Sets
• ASA Configuration for TACACS+
• ASDM Defined User Roles
• Test and Troubleshoot ASA CLI user access
• Role Based Access Control using Prime Infrastructure (PI)
• Prime Infrastructure (PI) Configuration
• ISE Configuration
• ISE Network Devices and AAA Clients
• ISE TACACS Profiles
• ISE TACACS Policy Set
• Test and Troubleshooting User Access to PI
• Device Administration for Third-Party Devices
• Operate
• Global Settings
• Logging
• Log Details
• Purging Logs
• Reporting
• How Do I Get Support?

Introduction

About Cisco Identity Services Engine (ISE)

Figure1: Cisco Identity Services Engine

Cisco ISE is a leading, identity-based network access control and policy-enforcement system. It is a common policy engine for controlling end-point access and network device administration for enterprises. ISE allows an administrator to centrally control access policies for wired, wireless, and VPN endpoints in the network. ISE eases the complexity of network device administration of Cisco and non-Cisco devices with intuitive workflows for Network administrators to manage the different components of Device administration.

ISE builds context about endpoints, including users and groups (Who), device type (What), access time (When), access location (Where), access type (Wired/Wireless/VPN) (How). This context is used to build granular policies enterprise wide for access and device administration.

About This Guide

This document provides guidance for partners, field engineers and customers to design, deploy device administration to an enterprise network.

The purpose of this guide is to help you with design and deploy common scenarios, and to outline tasks and
configurations for device administration for Cisco devices, a sample third party device and ISE. Note that the guide does not cover more complex configurations, such as two factor authentication or load-balancing.

Figure2: ISE for Device Administration flow

There are four major sections in this document. The Define section shows how to define problem areas, plan for deployment, and other considerations; the Design section shows how to design device administration flow for your network; the Deploy section provides guidance about the various configurations and best practices; and lastly, the Operate section shows how to manage and monitor a network controlled by Cisco ISE.

Define

What is Device administration?

Network and Security administrators typically own the task of administering and monitoring network and security devices in an enterprise. For a handful of devices keeping track of the admin users, privileges and changes to configuration is not very difficult. However when the network grows to tens, hundreds and thousands of devices, it would be a nightmare to manage the devices without automation and smooth workflow. ISE provides the capability to automate device administration tasks with clean workflows and monitoring capabilities within a controlled space in the UI.

What are the key elements of Device administration?

As a Network administrator/analyst, the first step is to think about how you want to manage your network. Your network comprises of three basic elements (assets) from a Device administration standpoint.

1. Organization, across single or multiple locations.
2. Admin, helpdesk users, lobby ambassadors etc.
3. Network and Security devices.

You also need to know your company’s security needs for authenticating users, if you are using external authentication server or some form of strong authentication etc. Finally, the audit/compliance needs for logging and monitoring changes in the network.

Next step is to plan your workflow for which you need to understand the assets of your company, come up with working model that suits your companies needs and it’s the personnel involved.

How to plan your workflow for device administration?

Identify context and privileges across identities

An enterprise network can span multiple geographies, different sites and locations etc. Your IT organization can have different groups that work together. You may have to work with other organizations such as Support, Operations or Front desk/Lobby ambassadors in your company to help them do their task successfully. The admin users can spread across different locations. These personnel may need different level of access privileges to same or different set of devices based on their role. Soon things can get complicated to manage. On top of this, you are responsible for monitoring the network for changes and anomalies to making sure nobody messes around with the configuration that may allow unauthorized access. Finally, you may be responsible for automating the access to these network devices using scripts and other automation tools.

So, the first step to make your life easier is to simplify administrative tasks that you do every day. You need to come up with a high level policy based on your business intent. Let us say your business intent is “Admin personnel need different level of access, to variety of network and security devices, based on the role, location, type of network/security devices etc.”

This requires you to understand a little bit about the organizational structure, your network topology, roles of the administrators, type and location (or any other classification) of network devices/security devices you have to manage etc.

Figure 3: IT infrastructure access based on Role

Here is an example: You have Cisco IOSXE switches, Wireless Controllers, ASR routers, Cisco ASA firewalls, NGIPS, VPN devices in your network.

Steve who lives in germany, is first level admin (helpdesk) for that region requiring access to network devices and firewall. You have Fei from China who is the network administrator for Asia Pacific region needing full privileges on all network devices in the region but not security devices. Finally, you have Trevor from South Africa, who is a security administrator for his region requiring full acccess to the security devices. All of them use Active directory for authentication.

Define Policy structure for device administration

Based on the scenario, your challenge is to create a policy that allows every administrator to do just their task and not anymore than that successfully. To start with, I highly recommend creating a table as given below. You have to create the role based on their organizational role and other rights provided such as if the user is a member of Active directory group etc. The last two columns distinctly calls out privileges and permissions you give the admins to do their tasks based on the role and criteria.

Role	Criteria			Privileges	Permissions
Network Admin	Confirm user is part of network admin group with an ability to manage network devices in their region			Full Privileges of Network devices	Full Permissions
Security Admin	Confirm user is part of security admin group with an ability to manage security devices in their region.			Full Privileges of Security device	Full Permissions to security devices
Helpdesk	Confirm user is part of helpdesk admin group with an ability to manage network devices and firewall in their region.			Helpdesk (View not change)	Only certain show commands
Default	if no matches, then			Deny access

The workflow picture below will help you visualize the table above. You can see the Users on the left and access and privileges to the right. Idea is to provide users the right level of access using the role and other criteria. Now if you are thinking whether ISE would allow you to check multiple criteria. The answer is “Yes”. We will look at it in detail in the next section. In short, ISE has the ability to create single or a combination of criteria’s such as the one in workflow.

Figure4: Role-based Policies

Once you generate this policy structure, the next step is to understand the build blocks of Device Administration and identify the components needed for creating a deployment.

Solution deployment considerations

Figure5: Components of ISE deployment

Device administration starts with admin users accessing network device using SSH or Telnet client such as Putty, or directly accessing the network device/NMS application over a browser. These admin users send their credentials to network devices/application that are then passed on to ISE. ISE verifies these credentials internally or using an external Identity store such as Active directory, RSA etc. Verifying the user credentials is the first step towards allowing access. Providing right level of access after verifying user credentials is the essence of AAA that stands for Authentication, Authorization and Accounting.

What is Authentication, Authorization and Accounting (AAA)?

The first step is Authentication, a process of verifying the user credentials to see if they are who they claim to be. In real life, this is very similar to walking into a Health care center. If you are a patient, you will provide information to the front desk who may verify necessary information and allow you access. If you are a Front desk personnel, you will not have access to Patient records but will be able to gather patient information. If you are a Doctor you are allowed everywhere and will have access to Patient records.

Figure6: Health Care Center (Role based access)

Similarly, users who are part of an organization are given a Job Title and a role in the company. They are typically assigned to Active directory groups corresponding to their role which determines their access to different IT resources in the company. This is the basis of role based policy assignment.

Now if these users are Network admins, based on their roles they may need to access only certain network devices based on device type, location etc. ISE verifies the user credentials and, if successful, validates a set of criteria and assigns the right set of privileges/ permissions to network devices. This is called Authorization. Finally, admin user’s session needs to be monitored and tracked with Accounting.

ISE is a server that hosts AAA services. There are two types of AAA services, RADIUS and TACACS+. Remote Access Dial-In User Service (RADIUS) is an IETF standard, was typically used by ISP’s for dial-in and is expanded to network access using 802.1X standard, VPN access etc. Terminal Access Controller Access-Control System (TACACS) is a protocol created by US Department of Defense and enhanced by Cisco. This is used mainly for Network administration due to its flexibility and logging capabilities. There are key differences between RADIUS and TACACS+. Here is a nice primer from network world to read if you are interested to know the differences. This document will mainly focus on TACACS+ as a service for Device administration.

Now let us examine the admin user experience and the AAA flow. Let us consider an admin user trying to access the application using a browser or using tools such as Putty that connects to a remote device using protocols such as Telnet, Secure Shell (SSH) etc. Figure 7 below shows the functionality, flow and the user interaction using TACACS+.

Figure7: TACACS+ flow with AAA

First, when the admin user tries to connect to the network device, the device sends out a ‘request for connection’ to the ISE server. ISE server sends a challenge back asking the user credentials that can be a username/password or a certificate (if using third party software). Admin user sends the user credentials back to ISE for verification. The user credentials are verified against an internal/external user database to complete the authentication successfully. At this point the admin user is still waiting for access but the user validation is complete.

Next, the network device/application asks ISE to authorize the user into the device to access the device/application. ISE authorizes the user allowing access to the network device prompt or to the UI using different set of privileges (Full/Read only etc.). Once the admin user gets access to the shell prompt/application, he or she can start executing commands or browse different menus in the UI. This is called Shell authorization.

At this point, if you want granular control and audit for every command executed, you can configure your network/security device to authorize every command that is executed. Environments that require tighter change control and audit tracking use this feature. This is called Command Authorization that is unique to TACACS only. This is not available using RADIUS protocol. Similarly you can turn on ‘Command Accounting’ to monitor every command authorization transaction and this is unique to TACACS as well. This makes TACACS a protocol of choice for Device administration.

From the TACACS+ flow, you can see three distinct phases Authentication, Authorization and Accounting. These phases are independent in TACACS+, meaning they use separate transactions (TACACS is a TCP protocol - port 49) that opens a TCP session for every transaction. This is different from RADIUS, where an authorization happens as a sequential process to every authenticated session and they are tied together. What this also means, is that when you are scaling the service to thousands of network devices these separate transactions come to play a key role in performance. You have to be cognizant of the options you turn on in the network devices that increases the number of transactions per second (TPS) across a large number of network devices. This is especially important if you are using Command authorization where every command is authorized and accounted for.

User Application Consideration

Admin user can use any application of choice to access the network device. For example switches, routers and security devices such as firewalls may allow ‘Telnet’ or ‘Secure Shell’ or other ways to remotely access the device. Administrators can use applications such as Putty, Secure CRT etc. for this. Other devices such as Cisco Wireless controller, Cisco Prime etc. may use browser to access the device.

Based on your environment you may choose a simple username/password called single factor authentication. You can use more than one factor for authentication that means a combination of password/PIN and hardware device that plugs in to the computer.

Figure 8: Types for User authentication

In general, two factor authentication is a form of strong authentication used in government, industry etc. The two factors can be any of the factors mentioned above but typically it uses user credentials/ Passcode and Token/ Smartcard as two factors.

You could use a key/token such as RSA, Duo that can recognize a token/password and sends it to RSA Server /Duo cloud for credential validation. In such cases, ISE needs to be configured to talk to these servers to forward the credentials for verification and to gather status information. The choice and use of these applications are beyond the scope of this document. It is suffice to say that, ISE works with a variety of these applications. Please check out the Two factor authentication community page for further information.

Automation tool consideration

In an Enterprise or Service Provider network managing thousands of devices may not be easier. You may need automation tools to glean status information from several thousand devices in your network at specific intervals of time and to monitor the devices continuously. Typically automation scripts written in Python/Tcl and other languages are used to develop logic, using standard set of CLI commands supported by different network devices, and to interact with the network and security devices periodically.

Optimize the scripts with timeouts at different points so as to not repeat the unexecuted task on and on endlessly. Every time a command is sent via script, ISE authorizes the command, independent of the values received by the script. This increases number of transactions and amount of logs created and consumed by ISE. Make sure to remove or minimize the frequency of poll using test user credentials to gather general status information from network devices. This minimizes spurious transactions and optimize log consumption If command accounting is turned on for every network device another log entry is created on top of command authorization. Be cognizant of the fact that for every command execution two logs are created.

Network Device Considerations

Network and Security devices generally include support for external authentication servers using RADIUS protocol. Due to flexibility of TACACS protocol and its ease of use for device administration a lot of third party devises do support TACACS+ though it is a Cisco proprietary protocol. Most of them support Authentication and Authorization and some of them may not support Command authorization. So it is important to understand the capability of these devices. Here is a quick list of enterprise and carrier class network device manufacturers supporting TACACS+:

Adtran, Alcatel/Lucent, Arbor, Aruba, Avocent/Cyclades, Blade Networks, BlueCat Networks, Blue Coat, Brocade/Foundry, Cisco, Citrix, Dell, Edgewater, EMC, Enterasys, Ericsson/Redback, Extreme, Fortinet, Fujitsu, HP/3Com, Huawei, IBM, Juniper, Linksys, Netscreen, Netgear, Nortel, Palo Alto Networks, Radware, Riverstone, Samsung and others (source).

We always start with your requirement as the first step. In simple words, what you need to monitor across these devices for e.g.: system uptime, memory, CPU, disk space, interface status, connection/link status, faults, exceptions, failures, configuration changes, updates etc. Critical devices may need frequent monitoring than non-critical devices. Typically some of these can be gathered using SNMP and a Network Management Software. So plan on the type of information you need to gather from these devices keeping in mind other NMS functions available in your network.

For chatty devices that sends traffic bursts, ISE has a TACACS+ feature called “single connect mode” that retains the TCP connection instead of tearing it immediately, however you need to make sure to keep track of the number of sessions not to overwhelm ISE with too many open connections.

Next step is to know the functionalities your network/security devices support for management and monitoring (for e.g., Support for external authentication servers using RADIUS or TACACS+. Finally you need to gather information on commands to enable in your network device for TACACS+ authentication, authorization, accounting, command authorization and command accounting based on what you want to monitor. It is also good to setup a Proof of concept for your use case in a lab to explore the options you need from these commands and identify the exact commands and arguments you need to complete AAA.

External Services Consideration

One of the main advantages of ISE is its rich capability to integrate with a whole range of external ID stores that provide authentication and authorization support natively or using RADIUS/TACACS+.

ISE supports standard external Identity stores such as Active directory, LDAP to two factor authentication servers such as RSA/Duo to SQL environments with ODBC support. Please check the network component compatibility chart for full ISE compatibility support with external identity sources. For Token support, ISE supports external servers that are RADIUS RFC 2865 Compliant.

Figure 9: External ID Sources supported

For external servers such as RSA, Duo etc. that provides Token support with two factor authentication, you need vendor specific documentation to add ISE as a RADIUS/TACACS+ server. You can also check Two factor authentication community page for details and ask your vendor for specific information.

If it is a standard external servers such as Active Directory (AD), you need to know the AD domains your users are part of, location of domain controllers (global catalog), Domain Name and AD administrative user name/password for configuring ISE. ISE inherited the AD connecter from ACS and optimized further in later releases.

Here are the following key features that assists ISE and AD integration

Figure 10: Key facts on ISE – AD integration

• ISE supports up to 50 AD domain across forests.
• It allows you to create an allow list of domains to be contacted for authentication.
• Use AD groups for user authorization to different network devices
• You can use attributes from Active directory for authorization that are sent to network devices.
• You could rewrite incoming usernames.
• Optimize the behavior of how ISE tries to talk to Active Directory (From ISE UI: Administration => Identity Management => External Identity Sources => Active Directory, go to your AD entry and go to Advanced settings tab).

Here is some key information about this admin (service) account that is needed to join Active Directory to ISE. First, this user account should already be available in AD to join ISE to the AD domain. This AD user account also needs to be permanently stored in ISE for its continuous operation including upgrades, backup/restore etc. It should have minimally following permissions and few others

• To add the workstation to the domain to which you are trying to connect.
• On the computer where the Cisco ISE account was created, establish permissions for creating computer objects or deleting computer objects before you join Cisco ISE to the domain.
• Permissions for searching users and groups that are required for authentication.

  For full information on ISE and AD integration, please check the published article AD integration with ISE 2.x. Remember, Cisco ISE does not support Microsoft Active Directory Servers that reside behind a network address translator and have a Network Address Translation (NAT) address.

ISE Deployment Models

ISE supports different deployment model depending on small, medium and large customer. Before we dive deep into deployment model, you need to have an idea of what is an ISE node. What functions does ISE node support and how does ISE split the functions in a multi-node deployment.

A Cisco ISE standalone node ( as mentioned in the picture below) is a dedicated appliance or Virtual Machine that can support different functions such as Administration (Management and configuration), Policy Service( TACACS and RADIUS service), Monitoring(Monitoring and Troubleshooting), and PxGrid. Details about the functional roles are described here. For this document, we are interested on the first three functions and not pxGrid.

Figure 11: Standalone Node vs Multi Node ISE

Now I hear you saying “Great!! But wait a minute what about me, I have a small/medium sized network. Is it one size fit all?” No it is not. ISE deployment is flexible for different types of customers. The functions of ISE as shown above 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 functions can be part of a standalone or a distributed deployment.

Simple Two Node Deployment

In a simple 2 node ISE deployment, ISE node can have a Primary and Secondary HA pair in an active/standby mode for Administration functions and active/active pair for Monitoring functions. Policy Service is the work horse of ISE providing network access, device administration, guest access, profiling services etc. This type of deployment serves typically a single location.

Figure 12: Basic ISE 2-Node Deployment

Basic Distributed Deployment

In ISE, we can expand the 2 node setup above to a basic distributed deployment, for a network that spans across geographies, business units where you can add up to 5 PSNs as shown below.

Figure 13: Basic ISE Distributed Deployment

In this topology, you have two PAN/MnT nodes as primary and secondary in a redundant setup in the same datacenter. Here the Primary and Secondary PAN is an Active/Standby HA pair where if the Active goes down you can either manually bring back the Standby. There is also a mechanism for Secondary PAN which is in a standby state to get automatically promoted to Primary PAN to ensure service continuity. This feature was introduced in ISE 1.4. This topology supports different geographies, locations and sites.

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, the Policy Services nodes can be spread across different sites. In a large network with global sites, the primary, secondary admin and monitoring nodes are dedicated nodes that can be in different datacenters as shown. The full distributed topology requires datacenters to be connected with a high speed and low latency links.

Figure 14: Fully Distributed ISE Deployment

If you are saying “wait a minute”, I am not sure about the link speed, latency between regions etc. and feel that you would prefer a regional model and was wondering how it works. It looks very similar to what you see above, except that this is per region, for example. AMER, EMEA and APAC can have dedicated ISE deployments per region. Each deployment can have their own Admin and Monitoring node centrally located and Policy Services Node (PSN) spread across different location in that region.

Lastly, there is an ISE deployment model based on operational or IT function. You can have separate ISE deployment for Security devices (VPN) and network devices (Wired/ Wireless) etc. Point is that based on the business function and how you manage your global infrastructure you can design the ISE deployment as per your need.

How to avoid TACACS+ service failure at a location, site or region?

For redundancy and to avoid point of failure of TACACS+ services for that location, you can use an additional 1 or 2 Policy Service Node per location. You can setup a network device to trigger failover, from Primary to Secondary to Tertiary PSN, if a PSN designated as primary PSN fails to respond back or if there is a network failure.

Figure 15: Single Site Failover

This will enable you to have at least one secondary PSN for every Primary PSN. This will ensure continuity of services smoothly however it could add more costs if for every PSN you have an additional one. In a distributed deployment, PAN pushes the configuration and policies out and synchronizes with PSN. So all PSNs will have the same copy of the configuration.

To minimize cost, you can also use a model where, for every set of PSNs for that region, you can have 1 or 2 additional PSN based on your need for failover and redundancy. These PSNs can be in the same site or centrally co-located in a Datacenter along with the Primary and Secondary PAN/ MnTs.

Figure 16: Multi-Site Failover

Finally, you could use Anycast on the switches or load balancers for distributing the traffic for TACACS+ AAA services. Now that you know the types of deployment and failover scenarios, let us dive into the designing your deployment for TACACS+ services.

Design

When deploying for the first time or when migrating an ACS deployment to ISE, you need to under basic deployment considerations mentioned in the section above for enabling Device Administration (TACACS+) services in your network. First question when designing ISE deployment is if you need a dedicated TACACS+ only deployment or if it can be shared with other ISE services (Secure access, guest and other ISE services) that uses RADIUS backend. This is more of a security and operational policy decision.

Note: Cisco Access Control Server (ACS) software is a precursor to ISE used by large number of customers that offers secure access and TACACS+ services. This is an End of Life’d product. Please check ACS to ISE Migration for details related to migrating ACS customers to ISE.

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. If these are separated in ACS deployment today, then continue doing so if that model serves you well.

Device Administration Model

The question is whether Secure Access and other services using RADIUS and Device Admin using TACACS+ should co-exist in the same node or as independent nodes. Here is some general guidance that will help you answer the question:

When you use scripts to monitor and manage network devices, recommend dedicated Policy Services Nodes for Device Admin service. We will call this Scripted Device Admin model.

In a Human Device Admin model, human admin users monitor and manage devices. Let us 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 ISE 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 may dictate the need for dedicated PSN nodes for Device Admin function, or separation of ISE deployment to separate RADIUS and TACACS+ control.

Design Options

There are 3 ways you can design your ISE deployment with TACACS+ only or with a combination of TACACS+ and RADIUS services. Each has its own pros and cons and use cases.

Dedicated Deployment is where you have 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.

Dedicated PSNs in the deployment means that the Administration Node and Monitoring Node are shared for managing Identities, policies, policy related configurations, logging for both TACACS+ and RADIUS. However you will still have a dedicated PSNs for servicing incoming TACACS+ or RADIUS requests and they are not shared.

Shared Deployment where all the node types (Administration Node, Monitoring Node, and Policy Services Node) are shared between both RADIUS and TACACS+ services and it comes one integrated deployment for your entire network.

Here is a table that gives you a good snapshot of the three types of deployment and lets you choose one of them based on the IT policy and use case.

Deployment	Dedicated deployment RADIUS vs TACACS	Dedicated PSN (Shared PAN/ MnT, dedicated PSNs)	Shared deployment (Shared PAN/ MnT and PSNs)
Architecture
Pros/Cons	Pros: • Complete separation of policy & management for Device Administration and Secure Access. • Provides total ownership. Cons: • Separate ISE deployments to maintain and additional cost.	Pros: • Centralized policy, monitoring for all AAA needs. • Dedicated PSNs allows scaling device administration services independently from Secure 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 in all PSNs. • Scale all AAA services incrementally by adding a PSN when or where needed. Cons: • Load from Network Access may impact Device Administration services and vice versa.
Use Case	Large networks, where IT functions are managed by different groups. Separation of Network access and Device admin users are critical. Where scripts are used extensively generating large amounts of logs for IT Audit.	Large/medium sized network where device administration and network access services are managed by same group. Both scripts and human admin users. Where separation of Network access and Device admin users are essential.	Medium/Small sized network where device administration and network access service managed by same group. Only human admin users. Where separation of Network access and Device admin users are not critical.

Let us start with the design and steps necessary based on the type of customer, deployment needs etc.

1. Choose the Device admin deployment design that fits your need. Use the above table as reference.
2. Choose the type of deployment, Two Nodes (HA) vs Basic or fully distributed deployment as discussed above.
   
   

TACACS Deployment Scale

Once a right deployment method is chosen, think about number of PSNs you need for TACACS+ and for other services.

Tip: For TACACS+ only deployment, if using ACS now, you can replace each ACS authentication server with an ISE PSN node. This is a simple, fool proof approach. ACS supports 100k Network devices, 22 total servers in a deployment. If ACS is oversubscribed beyond its limit, understand the constraints, then use ISE performance guideline for reference.

If your environment uses other TACACS+ servers then first step is to determine the number of Transactions Per Second. Here is a quick set of questions you can use to gather the information from customers.

Remember, this is design and we need certain inputs to determine scalability of Device administration services. For example number of network devices in your network, number of human administrators managing the environment or how many commands they execute every time they login to a network device.

Please take time gather answers to the questions as best as you can by scoping the number of Transactions in your network. In the end you may save yourself some money!

Question	Answer
How many network and security devices are managed using TACACS+?
Can you provide the Device types?
How many Cisco/Third party devices are managed on the network using RADIUS?
What are the device types, model/manufacturer?
Where are network devices located with respect to AAA servers?
Device administration using TACACS+:
How many network devices uses TACACS+ Authentication, Authorization and Accounting?
How many network/security devices uses command authorization?
How many commands per user (and/or) commands per script executed per session?
How many network/security devices uses command accounting?
How many human admins are managing the network and security devices?
How many network/security devices do they manage every day?
How many times do they login to these devices per day? and how long do the admins take to complete gathering information each time?
How many scripts do you run for managing these devices?
How many commands per script are executed every session?
How many sessions per day does the script run to gather information? How long is each

Calculate the Number of Transactions per Second (TPS)

Calculate the number of Transactions per second using a simple formula based on the inputs from questions above

#_Transactions_per_session = #_network_devices x (3 + 2 x Number of commands executed).

Now you can use this formula to plug in the numbers you received from questions above. A quick note about the next paragraph “If you are a thinker and your cerebral cortex does not allow you to proceed without understanding the reasoning behind formula continue reading the next paragraph, if not skip”.

This formula helps you calculate number of transactions for each TACACS+ session. This is based on the 5 TACACS+ transactions we saw before (Authentication, Authorization, Accounting, Command authorization and command accounting). The number 3 in the formula is for Authentication, Authorization and Accounting transactions in TACACS+ that is specific to every session. The multiplier 2 in the formula is for Command Authorization and Command accounting transaction that happens when every command is executed per session. So when you combine both you get the total number of transaction per command per session. Now if you scale the session to x number of network devices, you need to use the ‘number of network devices’ as a multiplier to calculate TPS for the deployment per session.

Let us consider this scenario. A customer is managing 10,000 network devices. A script or human admin logs into all the network devices 4 times a day executing 10 commands to gather information from the network device. Let us assume Customer has turned on command authorization and command accounting. Note that command accounting is different than session accounting that is part of AAA transaction.

Then based on the formulae,

#_transactions_per_day = 10,000 x (3 + 2x10) = 230k logs/session = 920k logs for 4 sessions.

Now that you have done the first step, rest is easy. The script that is used to gather information is usually fast and takes just few minutes to execute and gather information from 10 commands. Let us say it takes 20 minutes to gather all the information for four session.

Peak TPS needs to be calculated for the 20 minute time the script runs to gather with an overall transaction of 920k.

So, Peak TPS = 920k / (20*60sec) = 767 TPS

Now that we know the Peak TPS the network consumes, it becomes much easier.

Calculate Number of PSNs

The next step is to calculate number of PSNs.

Here is a chart that will help you determine number of PSNs needed as you scale the number of network devices in your network and also tracks logs consumed by MnT. The number of PSNs for a certain number of network devices is based on TPS calculated above. Following chart is made for 3595 appliance that supports 1500 TPS.

Let us examine the chart closer. From the chart, you can see that for 10000 network devices, you need one PSN dedicated for TACACS+ in your network. You can look at the logs/day for 10k network devices amounting to 0.92million logs/day. As you increase the scale of the network devices just above 30k you see that the log consumption is around 3M logs/ day. This is a limit for standard MnT before it shows performance drops. Beyond this, you may need to forward the logs to an external logging server or Super MnT that is introduced in ISE 2.4. Super MnT provides twice the size of standard MnT in terms of disk capacity. It increases the log retention.

Let us discuss another example, what happens if your scripts runs more than 4 times a day or your admin user executes less command per session?. That’s easy, you can extrapolate the result from the above chart easily.

This chart was created based on 4 TACACS+ session each day and 10 commands/session for x number of Network devices. So what happens if you have 10 sessions per day? Simple, logs generated per day will be 2.5 times the number of sessions (10 sessions divided by 4 sessions) used in the chart that is 2.3M logs for 10000 network devices. This increases the number of transactions and number of PSNs needed to support the transactions. You can observe that from the graph if your scripts generate 2.3M logs then you need 2 PSNs to support the number of transactions. Similarly if you have less commands executed per session, say 5 commands. It cuts down the number of transactions for TACACS+ to approximately 0.57.

Finally, if you want to use 3515 as your PSN you need 0.7 PSN for every 1 PSN supported in 3595 appliance. 3515 supports 1000 TPS as against 3595 that supports 1500 TPS. This might save you some cost but additional capacity may be needed for future. So choose your appliance/ VM size for PSN wisely based on your current and future needs.

How to Size ISE Nodes for Maximum Log Retention

Hardware and Software Requirements:

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.

Tip: Hard disk capacity is relatively inexpensive these days, you can choose up to 2.4TB capacity with ISE MnT. For a 3595 appliance or VM equivalent, you would have a 4 x 600-GB 10k SAS HDDs. With RAID 10, the HDD capacity comes to 1.2TB. This applies for standalone ISE deployment with HA or medium deployment (with 5 PSNs). If you have fully distributed deployment with independent MnT and you have log storage requirements due to audit, then do the same.

If you are sizing ISE VM please make sure the VM resources are dedicated. If it is a shared environment then resource reservation should be made available for ISE VM’s so that performance is similar to Hardware. Choosing a 3515 or its VM equivalent will get you only 16GB RAM, that is not sufficient to handle large reports, log refresh etc. Remember, we are speaking about Device administration and logs are critical part of it, you do not want your helpdesk folks complain that it takes a while to do a log refresh while they are troubleshooting an issue. So choose your VM sizing wisely. Also dedicate the number of CPU cores for optimum performance based on the hardware appliance.

ISE 2.3 supports new Policy UI, IPv6 capability for TACACS+ and options to include IP ranges in all octets when creating Network device, import/export command sets. ISE 2.4 is a more robust version in terms of stability with superior MnT performance. ISE 2.2 with latest patch is the recommended stable release. If you are looking for latest ISE version the move to ISE 2.4 that is the latest patch (Patch 5 or above).

Note: ISE 2.4 made significant performance improvements in-terms of better process and memory utilization and faster response. So you will see significant improvements in logs, reports and export capability in a standard MnT with 64MB memory.

Step 1: Choose the Hardware (appliance/VM) for ISE MnT and choose the software version for ISE.

If you have specific 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 scenarios:

• Scenario 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.
• Scenario 2: Managing devices using scripted device administration: An automated script that runs against 30K network devices. For e.g.: @ 4 times per day with 10 commands per session; Log size per day = (5K +10 * 3K) * 30000 * 4 = 4.1GB approx. per day.

Here is simple chart that relates the log size and log retention based on certain parameters as mentioned. This will give you an idea how long you will have the ISE MnT logs before it gets overwritten.

Based on the chart above, if your network has 30k network devices assuming you consume the same amount of logs as mentioned here then your logs can be retained for 143 days that is close to 4 2/3 months.

Step 2: Once you choose the deployment design, calculated number of PSNs and sized out the hardware and software for VM/appliance, next step is to account for service availability and redundancy across locations. We have seen that you can have different levels of redundancy to help with failure scenarios. We have two options here

1. First option is having a PSN pair for network devices to failover for each location or each site/region.
2. Second one is for every 5 PSNs you can setup 1 or 2 backup PSN in a central location. Choose the latter that gives value for the money but make sure your central location PSN is not across a slow WAN link. Your network device talks to PSN via TACACS+ which is a TCP protocol that is more reliable across connections but your scripts may timeout.

Step 3: Placement of PSNs are very important. It is highly recommended for Active Directory server that authenticates the domain users to be co-located with PSN in the same site. ISE has a robust Active Directory connector, however we have seen that when Active directory needs to gather user related information such as groups and in certain cases if these is a large blob of data, it takes time for AD to respond to ISE while the user authentication times out due to this delay. This is more pronounced when AD authentication server is across a WAN link from PSN.

Step 4: Now recall the deployment model discussion, choose the appropriate deployment model based on the number of PSNs and log capacity. If you have scripts generating Millions of logs recommend having a fully distributed deployment with 2 PAN and 2 MnTs. If your log exceed 3M logs then consider external log repository. Once you have everything designed, make sure to create a network topology diagram with details on placement of all ISE nodes with failover so that you can visualize it and change it as needed. Next step is configuration.

Step 5: Before that you need to get the right license for the device administration service and for the appliances. For newer deployments, Device administration requires a node license based on the number of PSNs in the deployment. You need a minimum 100 base license to get access to the UI and the services. Check out the ISE ordering guide for more information.

Deploy

The next step is to put everything in action. In this section, I will cover some of the global configuration that needs to be done to ensure good workflow for Device administration starting with ISE. Later, we will dive into the specifics for each platform. I am planning to cover IOS, Wireless Controller, Nexus, ASA, Prime and third party devices using TACACS+/RADIUS. This list can go on and on but I wanted to focus on platforms that are used more.

ISE Configuration for Device Administration

Bootstrapping

You need to first download and install ISE software in your VM or appliance and get it bootstrapped. Before that you need to gather information few things such as your DNS domain name, DNS server IP, NTP Server IP without which ISE would not start installing. You also need connectivity to your default gateway. Also make sure to choose a Hostname for ISE server and have a DNS entry for that. ISE by default uses self-signed certificates the first time it comes up. You can change the CA signed certificate at a later time.

During the setup, ISE will prompt you for answers and expects response from the administrator. ISE installation will not progress if you do not provide answers to these, so it makes sense to know answers to the question prior to installing ISE so that the bootstrapping and install goes faster and smoother.

Attribute	Value
Hostname
IP Address of ISE
Netmask
Default Gateway
DNS Domain
Primary Name Server
Secondary Name Server
Primary NTP Server
Secondary NTP Server
Time Zone
Enable SSH
Username
Password

Note: If you plan to use IPv6 for your network devices, you have to configure global IPv6 address at the eth0 interface of the ISE appliance after completing the steps to bootstrap ISE using IPv4 address with information mentioned below. Once ISE gets fully installed and reboots you can login to the appliance and add IPv6 address to the interface. ISE bootstrapping still uses IPv4 as of ISE 2.4 release that may change post ISE 2.4. Internode communication, external communication, logging and ntp still use IPv4 when using ISE 2.4, so you need both IPv6 and IPv4 address for ISE to work.

Note: If you buy ISE hardware appliances you will receive ISE pre-deployed. This information below focuses on installing ISE on VM.

Here is a great reference that discusses how to Install ISE on a VMware Virtual Machine for ISE installation. Please take a look at the system requirements to make sure you use the right VM size.

Anyway, the Large VM is meant for Super MnT. We don’t have to use it unless you are a big enterprise and want to use ISE MnT as a primary logging server for all logging needs and have thousands of network devices. It is a beefed up 3595 appliance with 256GB RAM

ISE software comes in two bundles OVA and ISO files. Using OVA will automatically dedicate VM resources when you install ISE and is the best way to make sure you have the right resources for all your nodes. ISE checks for minimum CPU and Memory for installation to complete.

ISE 2.4 and upwards you may need to purchase a VM license for your deployment. Please make sure you have appliance/VM licenses for PAN/MnT and PSNs. For Device administration service, you may also need a license per PSN node the service is used. This is essentially a TACACS+ license.

Once you complete the ISE install and bootstrapping that would take ½ hour to an hour in all at the most, ISE reboots, log into ISE via SSH with your user credentials that you created in the initial setup (This will verify that both SSH and user credentials are working correctly ) . Check NTP status and make sure clock is synchronized.

Navigate to ISE GUI by applying either your ISE DNS name (If you have DNS support) or IP address in web browser

Login as the admin and the password you supplied in initial setup.

Once logged in you should be presented with ISE dashboard. Bingo!!! You are in.

The following steps will give you necessary steps to create a workflow for Device administration

Licensing Device Administration on ISE

Device Administration (TACACS+) is licensed per PSN with ISE 2.4 and onwards, but requires existing and valid ISE base. Go to Administration > System > Licensing. Verify that the licensing for Device Admin is enabled.

Enabling Device Administration on ISE

The Device Administration service (TACACS+) is not enabled by default in an ISE node. The first step is to enable it.

1. Log in to the ISE admin web portal using one of the supported browsers.
2. Navigate to Work Centers > Device Administration. You will land in the Overview > Introduction, which is the default screen for this menu. It outlines three stages for Device Administration – Prepare, Define, and Go Live & Monitor to create a workflow. The submenus under Device Administration are entities to accomplish various tasks for this workflow.
3. Select Deployment side menu from the left pane that takes you to ‘Device Administration Deployment’. If this is your first ISE server, it is standalone, select either All Policy Service Nodes or Specific Nodes and select þ your ISE node (e.g.: ise-1.demo.local), under Activate ISE Nodes for Device Administration. ISE also allows to use customizable ports for TACACS+ that you can specify if you intend to use a non-default port. Click Save when done.
   
4. There is a little tool hidden when you hover over side menus that makes these menus default view in the Work Center. Use that to your advantage to setup your Work Center views.
   

Creating Internal or External Identities

This section defines an Identity Store for the Device Administrators, which can be the ISE Internal Users and any supported External Identity Sources.

ISE internal user identities and user Identity groups

Create User Identity groups based on roles:

If you are using ISE internal store, you first create groups based on the roles defined in the earlier section. Do you remember the discussion? We had 3 roles defined Network Admin, Security Admin and Helpdesk. So you need to create User Identity Groups for these three roles from Work Centers > Device Administration > User Identity Groups.

Create User Identities:

Then create users from Work Centers > Device Administration > Identities. ISE also allows you to import users from a pre-filled template. It allows you to export users as well. You can also enable/disable users.

When creating users, you can find options to create login and enable passwords for TACACS+. Also with ISE you can use internal users with external store passwords. Please make sure the username is the same in your external store. If you are wondering who uses that, this was supported by ACS and for migration and service continuity we had to bring this in to help smoother migration.

You can also use API’s to add/remove User Identities, User Identity Groups etc. To check out the API’s you can browse to https://(PAN):9060/ers/sdk and look at what is supported.

Now you start really appreciating ISE, right? I am optimistic that you will become a believer after reading this document.

Just a few more details not to be too long winded here. Read the next paragraph only if you are wondering how to create custom attributes for users. Else skip the next paragraph.

When creating User Identities, ISE lets you create custom attributes for users so that you can use that for authorizing users in the authorization policy. For example: If you are in an environment where user needs to use a dedicated workstation for performing the task, you can use these fields to configure an IP address and check that against the attributes received during Authentication. You can check Date, String, a number, IP address etc. You can browse to Administration > Identity Management > Settings >User Custom Attributes to learn more. If your environment has a TACACS server with custom attributes, here is where you need to create those.

For example: If you want to check the IP address of admin user’s machine or port to which the machine is connected, you can create a user custom attribute called ‘Admin-machine-IPaddress’. Then go to the internally created admin user and type in the value as mentioned below.

If you are using external Identities, you can create these attribute and value in Active Directory schema and use that in ISE policies.

Using External Identity Sources for User identities

In this document we are using Active Directory (AD) as an External Identity Source. So you need to add the Active directory domain as a join point in ISE. ISE supports one or more AD domains and forests. It allows up to 50 Active directory join points across your AD domains and forests. A join point is simply the point where you join the AD domain.

If you have multiple domains across different businesses and want to authenticate based on separate AD join points turn on the scope mode. This is a less known feature but useful in situations where you need to use single or multiple join points in an authentication policy as authentication results. When you enter scope mode, ISE creates a container called initial scope and allows you to create multiple scopes.

In the section earlier, I discussed about AD benefits, one of that is it allows you to allow-list the authentication domains you want the user to authenticate against. This optimizes performance. When users authenticate, it is highly recommended to use fully qualified names (that is, names with domain markup e.g.: UPN: jdoe@abc.com, NETBIOS: ACME\jdoe or FQDN DNS: host/machine.example.com) for users and hosts during authentication.

Adding Active Directory join point

1. To add an AD join point, browse to Work Centers > Device Administration > External Id Sources > Active Directory. Click Add to define a new AD Joint Point. Specify the Join Point name and the AD domain name and click Submit.
   
   
2. If the status shows Not Joined, click the checkbox next to ISE node and click Join.
3. In Join Domain pop-up window, fill in the Active Directory administrator username and password.
4. Click OK to start the join operation. A window Join Operation Status will pop up. Wait until the node status turns Completed, and then click Close.
5. The Connection tab will show ad.securitydemo.net as the domain controller and Default-First-Site-Name as the site.
6. Step 10 Click on the tab [ Groups ] and look at the list of AD groups. The groups we will use in the document are Contractors, Employees, and Staff, and map to TACACS+ authorization policy rules such that. This is to give an example of the AD groups that you can map to a role.
   Staff => Network Admin
   Employees => Security Admin
   Contractors => HelpDesk

As Staff is also member of Employees, we will arrange the Admin rules higher in priority. Create the groups as needed in Active Directory for this.

Creating Network Devices and Network Device Groups

ISE provides powerful way to group Network devices with multiple device group hierarchies. Each hierarchy represents a distinct and independent classification of network devices. Now you are wondering why in the heavens this is necessary.

We discussed this in the previous section where I showed you a table and a nice picture about policy workflow for an organization. For those of you who are thinking ‘let us move on’, continue reading. I am not going to explain the same here. Here is a recap of what we discussed, if you have different types of network devices and security devices spread across different regions in the world, ISE helps you group these network devices into these Network Device Groups that can be applied to a policy in a very flexible way. In short, it makes your policy organization simpler and we highly recommend this.

Now, pause and take your time to think through the policy construct and come up with classifications of Network Device Groups based on not only device type, location, you can use business groups names, your vendors, 3^rd parties etc. If you are an ISP and managing customers then your customer name or group of similar customers or based on how you change your customers etc. Think out of box to come up with classifications for Network Device Groups. This would make your life easier when you configure policies.

Create Network Device Groups to classify Network Devices

1. To create Network Device Groups, navigate to Work Centers > Device Administration > Network Resources. Click on Device Groups from the left side panel. ISE UI has the option of viewing the table as a Tree or a Flat table. By default the view has a Tree format. You can see three default groups (All Device Types, All Locations, Is IPSEC Device).
2. Click on the + to add a group for Wired and/or Wireless device type under parent group ‘All Device Types’. Create Switches, Routers under that (nested groups). You can create another group called Firewalls and add ASA or other firewalls under that. Create a separate parent category if needed based on the environment you have (Cisco or non-Cisco) based on your need.
3. Click on the + for adding Network device groups based on location Germany/ Asia-Pacific/ South Africa. You need to choose ‘All Locations” as your parent group. Be creative when creating nested groups based on how you want to use it.
   Note: ISE 2.3+ supports 6 level hierarchy and 10,000 Network Device Groups with max 32 characters. You can also import/ export

Figure: Network Device Groups from the UI.

Finally, ISE does provide API support for creating/updating Network Device Groups if you want to integrate it with your network management system.

Create Network Devices for TACACS+ and add them to Network Device Groups

1. Step 4 To create Network devices, browse to Work Centers > Device Administration > Network Resources. It displays the Network Devices screen. Click + Add to add a new network device (using subnets) and fill in the data as below. In this example we are creating CSRv as router and add IOS-SW as Device Type and SJC as Device location.
   

   Name	CSRv
   Description	-
   IP Address	2001:EF8::1 / 64
   Device Profile	Cisco
   Model Name	-
   Software Version	-
   Device Type	IOS-SW
   Location	SJC
   o RADIUS Authentication Settings
   o TACACS+ Authentication Settings
   Shared Secret	ISEisC00L
   Enable Single Connection Mode	▢ ◉ Legacy Cisco Device ◯ TACACS+ Draft Compliance Single Connect Support
   ▢ SNMP Settings
   ▢ Advanced TrustSec Settings

2. Click Save in the bottom left corner of the screen when done.

Tip: Network Device IPv6 address has to be the global IPv6 address. Link local IPv6 addresses are not supported.

Note: IPv4 and IPv6 supports Single connect Mode connection. Optionally you can enable Single Connect Mode with TACACS+ Draft Compliance Single Connect support option if you have chatty Network devices. The TCP connection for Single mode connections is not disconnected for every single Transactions and would ensure reliability but it is very resource intensive. Use it with caution only on certain Network devices.

Change your shared secret without network disruption

If your network security policy mandates changing the shared secret every few months, there is a great tool for you. Once you create an entry for the Network Device, you can find a Retire button in TACACS+ Authentication settings. If you click that Retire button, you will be asked to enter another shared secret and a timeframe. By default it is 7 days that is the timeframe when the old shared secret and new shared secret can both be used by the network device to connect to ISE. After 7 days, the old shared secret will retire and new one will be used from then on. Timeframe to retire shared secret is configurable in that setting and you also need to configure the global setting for TACACS from Workcenter >Device Administration > Settings

Configure ISE as proxy to other TACACS+ Server

This paragraph is meant for advanced admin users who have played around with other TACACS+ server such as ACS etc.

If you have an environment where you have a third party TACACS+ server or ACS and want to move to ISE. There are two options.

1. Place ISE behind your current TACACS+ server and proxy the request to ISE
2. Place ISE in front of your current TACACS+ Server and make ISE proxy the request to ISE

While the first one does not need change to the network device, second one does. You need to add ISE IP address to the TACACS server list and change the order of TACACS server in your network device. So the choice is yours. However when you do the latter it will let you move the users much faster as you configure ISE with additional configuration for your users, devices and policies.

ISE supports being a proxy to an external TACACS+ server. You have to go to Work Centers > Device Administration > Network Resources and choose TACACS External Servers from UI to add ACS as an external TACACS+ Server. TACACS Server Sequence option in the UI allows you to prioritize multiple external TACACS+ Servers. You need to add ISE an AAA client in ACS. There are customers still using Cisco ACS or open source software for TACACS+ and evaluating ISE. Plan to use ISE as proxy to ACS for a small set of network devices then use this functionality and slowly switch the network devices from ACS to ISE. This gives you the opportunity to groups users based on network devices and test it with ISE.

Policy Elements

Policy Elements was a name given for the components you need to add to a policy. A policy typically will have a conditions and results. After the admin user gets authenticated, ISE authorizes her/him based on a condition or a group of conditions. If ISE is able to successfully match the conditions with the incoming requests from the Network devices, it sends result in the form of permissions and privileges back for an administrator to access the network device and complete their task. This is specific to TACACS+.

For Network devices supporting RADIUS, ISE needs to send something called an authorization profile that has the attributes that Network devices understands to allow administrator access to the Network device.

Policy Elements in the UI (Work Center > Device Admin > Policy Elements) has three components

Conditions

There are conditions that you can build and use in ISE authorization policy for TACACS+. Conditions option allow you to create a canned list of conditions, so that you can add this to a policy later. Exception being the Time and Date condition that allows you to create sets of policies (or Policy Set) based on time and date. You will find that when you browse Work Center >Network Access >Policy Elements since this is applicable to both TACACS+ and RADIUS.

Network Conditions

The three Network Conditions you see under Work Center > Device Administration > Policy Elements was mainly carried over from ACS to support migration. I do not see much use of Device Port Network Condition in TACACS+. However, TACACS does have a port attribute that you can use to gather port information of the remote machine. That said, the other two network condition under policy elements section may be more easy to use. The ‘Device Network Condition’ can be used to group network devices using its network device name, IP range, or group of different Network Device Groups in the Network condition, and use it as a criteria in the Policy set. You can use the ‘EndStation Network Condition’ to build a list of IP addresses of endpoints permitted and use that as a criteria for the Policy set.

Results > Allowed Protocols

There are three Policy Elements specific to TACACS+ that is mostly used that you can find under Results. Allowed Protocols let you create a list of protocols allowed within TACACS+ to authenticate users. ISE supports PAP, CHAP and MSCHAPv1 protocol to receive user credentials compatible with TACACS+ draft. You can also see a list of canned entries created under Allowed protocols that includes Default Device Admin that you can use. You can also create a list of protocols if you want to trim down further by clicking Add button.

Results > TACACS Profiles and Command Sets

For those of you who used ACS, TACACS Profile this is akin to Shell Profile in Cisco ACS. TACACS profiles typically assigns user privileges and basic permissions to perform a task.

Let us think about Privileges and Permissions with a real life example. If you are an employee of a company you are privileged to get a salary, benefits, holidays (Paid Time Off) etc. When you are in office campus, you are eligible to walk to certain parts of the building with your badge. You may still not have access to sensitive areas, but in general you have access to your workspace, your group workspace, lab etc. If you are a contractor, you may have limited privileges and access. You may get paid by the hour and have access to workspace, labs to perform your task with your badge.

Figure 17: Campus access based on Role

A person that has higher privilege may have greater permissions to execute their task. For example, an employee may automatically have access to different buildings within your campus that gives them permission to go in and out to do their business. Now just because someone is an employee and have access to get into the building are they entitled to do what they want? Maybe not.

Imagine your IT admin walking into your CEO’s office without appointment or prior notice in the middle of a business meeting. The admin user will be sent back and will have to get an appointment before using the CEO’s office or their computer. In this case, a permission from the CEO’s office was needed for an employee to do their task. So, though privilege can get you basic permission to enter into the building you need to get additional permission to perform your tasks.

Now let us consider an example of Network device administrators. Say, you want to allow a Helpdesk admin to execute certain commands such as ‘show configuration’, but not ‘configuration terminal’. How are you going to accomplish that given the level of privileges Helpdesk admin already has in this network device?

‘Command Sets’ does this exactly for you in ISE, you can create a list of commands your admin user is allowed to perform and deny others. This helps you design the Device admin policies on much more granular way based on the role of the administrator and other criteria.

How do you create TACACS Profile?

ISE TACACS profiles also allows you to create configuration on privileges, timers etc. that are sent as attribute value (AV) pairs that are supported by the network and security device.

When you add a TACACS profile, you land up in the tab that says ‘Task Attribute View’, that shows all the common tasks associated in creating the profile. ISE UI gives a list of easy to use templates that will help you create profiles for different types of network devices. You can find this selection in ‘Common tasks type’. Choose the one from the list in the dropdown. Choose Shell for IOS or IOS-XE device, WLC for Wireless Controllers and Nexus for Nexus devices. Generic can be used for non-Cisco device where you want to add Custom attributes.

You can also add attributes in the ‘RAW View’ as attribute value pair. These appear as MANDATORY attribute in the custom attribute section below. If you plan to manage users in Active Directory or LDAP server, you can add the values to the attributes added in ‘Common Tasks’ from an Active Directory attribute.

How do you create TACACS+ policies that can be applied to the Network device?

Now that I described the TACACS Profile functionality as seen in ISE UI, the first thing for you is to understand what your Network device supports. If you are using Cisco, a trivial search in the internet will yield you a list. Then you need to come up with specific tasks list you need to accomplish what you need to do when the Admin user is authorized.

A simplest thing is to allow the admin perform tasks in the network device up to a certain time after the authentication is complete. I have outlined a list of tasks you need to complete:

1. You need to allow user’s access to the Shell prompt of the Network device. By selecting the Common Task Type as ‘Shell’, Cisco ISE intuitively uses this profile if network device sends a request with “Service=Shell” for authorization.
2. The next thing is for you to configure the privileges, the Default privilege that an admin user gets after the login to the network device and Maximum privilege admin user is allowed. Maximum privilege can be used with the enable command to authenticate user again for higher privileges.
3. You can configure commands to be executed automatically when Admin users login with auto-command. You can setup boundaries for the admin user session such as timeout, idle timer etc.

The rest is up to you based on, the capability of network device, policies you want applied to the network device, and what you need to monitor. For e.g.: You can configure IP addresses to be sent to remote hosts via ‘addr’ attribute. You can use ‘inacl’ to send the ACL’s when your users are dial-in clients using PPP to be applied at the incoming interface etc. These attributes are specific to the OS the network device supports. If it is Cisco device you can get this from Cisco documentation or a trivial internet search.

Now that you know how to create TACACS profile, let us look at what are command sets and how you create command sets and rules associated with that.

What is a TACACS Command sets? How does it work?

A Command set allows you to create a list of commands in ISE that an admin user is authorized to execute after she logs in to the network device. You have to browse to Work Center > Device Administration > Policy Elements >Results from ISE UI to create one. Command set allows you to stack a list of commands in the form of Commands and Arguments. You assign permission to each command in the list to either permit or deny that specific command along with its arguments. ISE UI calls these permissions as GRANT as shown below.

In the ISE UI, you will also see a checkbox that says ‘Permit any command not listed below’. This is meant, to create a list of commands that will automatically be denied, to simplify creation of Command Sets based on block list of commands that are not allowed for that admin role.

Remember each command set can be written specific to the admin role, so name your command set in an intuitive way for you to understand the role and permissions associated

Command Set syntax

In a command set, a Command is the first word of any command that your network device supports, argument is the rest. ISE supports wild cards in the commands and standard regular expression for arguments.

There are three aspects to configure Command Sets from ISE UI, they are GRANT, COMMAND and ARGUMENTS.

1. GRANT is something that permits, denies or denies always a certain command and argument.
2. COMMAND allows you to type the command and it accepts wild cards. They are case insensitive.
3. ARGUMENTS can be one or more parameters that follows the command. Argument takes regular expressions.

Rules for matching across multiple command sets

It is easy to remember the order of match across command sets as Deny Always > Permit > Deny

A match of command and arguments that has ‘Deny Always’ have higher precedence over a match that has ‘Permit’, rest all are denied. This is across all the command sets that you add in the authorization policy.

Here are some examples. The command set indicates that interface GigabitEthernet 1 or interface GigabitEthernet 0-999/0 are denied always if there is a match. show/ config / no shut commands are permitted. Commands to configure other interfaces are permitted as well.

Grant	Command	Argument
PERMIT	config*
DENY_ALWAYS	interface	GigabitEthernet 1
DENY_ALWAYS	interface	GigabitEthernet [0-9]{1,3} 0
PERMIT	interface
PERMIT	SHO?
PERMIT	no	shut

When you have multiple command sets in the policy, the order of operation for command authorization when ISE receives an incoming command and arguments is as follows. First ISE looks at the commands and arguments across all command sets for a match.

Then, ISE searches for a command set that has ‘Deny Always’ for that command match. A command set that has ‘Deny Always’ takes precedence over everything except when you have the check box clicked that says ‘Permit any command that is not listed below’.

After ISE analyzes all the command sets, it authorizes the command in the following way. If ISE sees a Command set that has ‘Deny Always’, it denies the command. If not, ISE permits the command based a first match that was permitted; otherwise, ISE denies the command.

Best Practices for command sets

To represent small command sets, do the following

Deny unmatched commands

Use PERMIT option to specify allow-list

To represent large command sets:

Permit unmatched commands

Send DENY option to specify block-list

For intermediate command sets:

Consider building policy from small sets of re-usable small command sets

Remember first word is the command, even if it is “no”

Now, let us look at how this is used in ISE policies.

Device Admin Policy Sets

The operational challenge of Policies

Figure 18: Security policy complexity

ISE in its core is a policy server using different AAA protocol to Authenticate and Authorize the users. It provides you a list of Authentication and Authorization policy in ISE that can be used to authenticate users and send privileges and permissions to admin users. However, customer environments can vary based on their nature and type of business, security and IT environment, type of network devices, locations and policies that should be applied to different set of network devices etc. So a monolithic list of authorization policies that takes into consideration the complexity managing your Network devices will be too complicated, intractable and a nightmare to manage.

What if you have a layer of policies that helps you wade through complexity that we spoke about easily where you really have to be concerned about only admin user role and level of access for them.

That would be awesome right?. Believe it or not we have exactly that in ISE. We call it a Policy set.

What is a Policy set? How does it work?

Policy set helps you filter out the requests from Network devices based on several criteria or conditions. It simplifies the art of applying policies on the right set of resources in your network by weeding out request at different levels so that your administrators get the right privilege and permissions for the network/security device they are managing based on their role. The beauty is that you can apply different conditions at different levels. So, here is how an ISE policy set works.

Figure 19: Policy set behavior

At the highest level, you have the Policy set conditions that is an uber filter allowing incoming requests based on conditions or group of conditions defined in ISE. This could include network devices groups classified by device type, location or a combination of these. This can be used along with conditions for ‘Time and date’ or with TACACS attribute such as user name etc. Idea is to create a set of condition that the incoming traffic would match against initially to take it to a next step, authentication.

In a policy set UI, by default there is a canned list of Allowed protocols to choose for authentication. You can use Default device admin from the drop down under Allowed protocols used for TACACS+ authentication between the network device and ISE. This typically includes PAP, CHAP, and MSCHAPv1 protocol. From the policy set view, you can create a new Policy set or use the default one. You can also create a different list of Allowed protocol from Policy elements. Here is a procedure to create a Policy set and the corresponding policies under.

1. Navigate to Work Centers > Device Administration > Device Admin Policy Sets. You will see a new Policy set UI that is new in ISE 2.3. Observe the new tabular UI with Hits (hit counts).
   
   
   
2. Click the + button to insert a new row above. You can create additional policy sets for Wireless Controllers, Firewalls, Cisco/Non-Cisco devices based on Network Device Group (Device type or location or other criteria) along with other conditions as described previously. Here is an example below for all IOS devices.
   

   Status	Name	Description	Conditions
   ✓	IOS Devices		DEVICE:Device Type EQUALS All Device Type#IOS-SW

3. Click on the + button to add Conditions from the Conditions studio. Conditions studio has a pre-built list of conditions that you can use in your policy set. From the condition studio you can combine multiple conditions from the pre-built list and/or create new ones from ISE pre-defined dictionary and attributes.

4. The Pre-built list on the left will have some of the most utilized conditions that are made available in the Conditions Studio.

5. To create a new condition, to the right of the screen under the Editor, Click to add an attribute from the list of pre-defined attributes in ISE.
   

6. Choose the Device Type attribute from the Device Dictionary as shown above. Now from the dropdown select All Device Types#IOS-SW as value as shown below. This was the Network Device Group we added for CSRv initially.
   
7. You will see buttons appear to Duplicate or to Save. This allows you option to save the condition for future use in the conditions library. Click Save. ISE UI will ask you to save as existing library condition or new library condition. You can save the condition with an intuitive name, for example let us use “Device_Type_IOS”.
8. Click on the Use button at the bottom right of the screen. This will allow the condition to be used in the Policy set.
9. Click the drop down under the Allowed protocol/Server Sequence and choose Default Device Admin from the list. Click Save.
   Note: If you have to configure ISE as a proxy to your existing TACACS+ server, be it ACS or other open source. You have to create external servers from Device Administration > Network resources, add it to External Server Sequence if you have more than one server, then create Policy set. From Allowed protocol drop down you have to choose the name of the External entity you just created.
   
10. Your policy set will look as shown below:
    
    
    

Authentication Policy

Once incoming request matches the policy set criteria, the request is sent to authentication policy that authenticates the users against a user database store. Authentication condition is optional, however it facilitates differentiating different type of requests, for example to authenticate users based on certain period of time and create exclusions etc.

Another example is to verify if the incoming request for TACACS service login vs TACACS service enable (one is request for default privilege and the second is for enable access). You can also combine this with ‘Time and date’ condition and TACACS service attribute. The users are verified against a list of internal and external user store (AD, LDAP, RSA, ODBC etc.). If the authentication fails user is denied access. If it is successful and if TACACS authorization is configured in the network device, requests go through the authorization policy.

Here is a list of steps to create an authentication policy to verify admin user credentials with a user identity store such as Active Directory. In this document we are using Active Directory as an external Identity store

1. Click the > right arrow to expand the policy sets. You can find this on the right end of the policy set. You will see the default authentication, authorization and exception policies listed as shown below.
   
2. Define the Authentication Policy by clicking on the Authentication Policy option shown in screenshot above.
3. In the Default rule, click the drop down box to add the user identity store you want to use. You can also create a rule by clicking + provide a name and use the conditions as described before and map it to a user identity store of your choice.
4. When selecting Default rule, in this example the UI will show ‘All_User_ID_Stores’, change it to ‘demoAD’ or your Active Directory join point you created earlier. Click Save at the bottom right of the screen. In this example for Authentication, we use the Active Directory as the ID Store.
   

   Authentication Policy
   ✓	Default Rule (if no match) : Allow Protocols : Default Device Admin and use: demoAD

Note: Before ISE 2.3, ISE was sending an authentication pass even if the authorization policy says deny access. This is changed since ISE 2.3. If there is no authorization policy match, ISE will use the default authorization policy and send an auth fail.

Authorization Policy

Typically authorization policy is used to verify if a user is part of certain Active Directory Group or LDAP group to determine the role of the user. . If it is a match then ISE will sends Privileges and Permissions in the form of TACACS profile only or a combination of TACACS profile with Command set for more granular control. Authorization policy you can also stack multiple Command sets if needed but can have one TACACS profile only.

We also saw in the earlier section in this document on ‘Creating internal and external identities’ that ISE also supports user customized attribute if you want to create attributes to internal user database.

Authorization policy conditions helps you to match an internal user attribute or attribute from Active Directory with the one ISE received from the network device via TACACS.

For example: If you want to check the IP address of admin user’s machine (or port), you can create an authorization condition that verifies if the value received from TACACS remote address attribute equals an internal user attribute as shown below

Once authentication is successful, ISE will process the authorization policy list top down. The first matching policy will be applied.

1. Define the Authorization Policy by clicking the Authorization Policy option in the Policy sets => Set view screen. Here we define the authorization policy based on the user groups in Active directory.
2. The steps to create a new Policy set, authentication and authorization policy are the same. Create the authorization rule by clicking +, then add the conditions that the authorization policy should satisfy. After that, you need to add the result when these conditions match by choosing the right Command Sets and Shell profile.
3. Here are steps to add conditions to Authorization policy just in case you need help. From the Conditions studio right panel Click to add an attribute as shown in screenshot below.
4. Select the Dictionary, in this case we are using the AD join point (e.g:demoAD) and “External Groups” attribute available in the list. You can use the filters for this too as shown above.
   
5. Select the right operator from the drop down window. Choose the value as in the table above.
   Note: When you have special characters in the value make sure to test this against the values received from the Network Device
6. Click Submit to save the policy set.

In defining Policies you can have two strategies.

• Strategy 1: Use Network Device Groups to filter out user requests based on the device type/OS/location and a combination of those at the policy set level and use Active Directory to authorize users based on the role.
• Strategy 2: Use Network Device Group to filter out request based on one criteria for e.g.: Device type and use Active directory (AD) to authorize users based on the role and location. The idea is to keep the policy set simple at a higher level. The second strategy will work if you already have an AD infrastructure in place and a way to authorize users based on different criteria since they would belong to groups. You can choose the best strategy based on how your AD environment is set.

While considering these you need to understand the scale number of policy sets, authorization policies etc. ISE 2.4+ supports 200 policy sets with a maximum of 2000 Authentication and 3000 Authorization policies.

In the next section we will go through the example of configuring different set of network and security devices and walk through the Privileges, Permissions and Policies for each.

Cisco IOS – Switches/Routers

First step before configuring TACACS profiles is to make sure the Network Device has an associated Network Device Group (NDG) based on device type, location etc. In the previous section on ISE configuration we discussed this.

This section is focused on creating a set of privileges, permissions for device administrator based on Cisco IOS supported in switches/routers. Once you create that we will see how to map the privileges, permissions to an authorization policy. We will also see examples of criteria/conditions that has to be satisfied for authorization policy to work.

We all know that an admin user needs certain privileges to operate and perform their device administration task. So, let us first try and understand what these privileges supported in IOS devices are, so that we can map it to a specific Admin user role.

Privileges in a network device allows admin user to perform a range of functions, from monitoring to change in global and interface configuration etc., as they get assigned higher levels.

Access Privileges via TACACS Profile

Cisco IOS provides 16 levels of access privileges. Three are defined by default:

• Privilege level 0 – permits disable, enable, exit, help, and logout commands. Since the minimal accessible level after login is 1, all the commands in this level-0 are available to all users.
• Privilege level 1 – non-privileged or user EXEC mode is the default level for a logged-in user. The shell prompt is the device name followed by an angle bracket, for example “Router>”.
• Privilege level 15 – privileged EXEC mode is the level after the enable command. The shell prompt is the device hostname followed by the pound sign, e.g. “Router#”.

With EXEC authorization, an IOS device sends a TACACS+ authorization request to the AAA server right after authentication to check whether the user is allowed to start a shell (EXEC) session. For this we configure ISE to push two attributes to customize it per-user:

• Default Privilege: Specifies the initial (default) privilege level for the shell session. Authorized users land in this level instead of 1. If this level provides enough access, the users need not use the enable command.
• Maximum Privilege: Specifies the maximum level permitted for the shell session. Authorized users can log in with a lower default level and use the enable command to move to a higher level, up-to the value assigned by this attribute.

The ISE admin roles are Helpdesk, Network Admin and Security Admin. We may need just two sets of privileges Helpdesk and Admin. We will later, look into the permission we can control for Admins that would be different for Security and Network Admins.

We define two TACACS Profiles: IOS_HelpDesk_Privilege and IOS_Admin_Privilege

IOS Helpdesk Privilege

For helpdesk troubleshooting, the commands at Level-1 are usually sufficient, so we assign that as the default privilege to the helpdesk analysts. Occasionally they need more privileges, so we allow 15 as their maximum privilege level.

1. On the ISE GUI, go to Work Centers > Device Administration > Policy Results > TACACS Profiles. Add a new TACACS Profile and name it IOS_HelpDesk_Privilege.
2. Scroll down to the Common Tasks section. Choose Common task type as Shell from the drop down list. Enable the Default Privilege with a value of 1 from the drop-down selector, and the Maximum Privilege with a value of 15 from the drop-down. This is just an example, you can give the Maximum Privilege of 2 for Helpdesk based on the commands allowed.
   
3. Click Save to save the profile.

IOS Admin Privilege

Network administrators need more privileges in general so defaulted to Level-15 directly.

1. Add another profile and name it IOS_Admin_Privilege.
2. Scroll down to the Common Tasks section. Enable the Default Privilege with a value of 15 from the drop-down selector, and the Maximum Privilege with a value of 15 from the drop-down.
   
3. Click Save to save the profile.

TACACS Command Sets

Cisco IOS can authorize every command executed by the admin user. This needs to be enabled on the network device to perform command authorization. When enabled, it queries the configured TACACS+ server to verify whether the device administrators are authorized to issue the commands. ISE can provide a list of commands granted to the users to fine tune which commands are available at various privilege levels.

We have defined three commands sets based on the roles Helpdesk, Security Admin and Network Admins. Those are helpDeskCmds, iosSecurityCmds, and permitAllCmds. These can be imported or exported using csv file using a template that can be downloaded from ISE UI.

helpDeskCmds Commands

1. On the ISE GUI, go to Work Centers > Device Administration > Policy Results > TACACS Command Sets. Add a new set and name it HelpDesk_Commands.
2. Click +Add to configure entries to the set:
   

   Grant	Command	Argument
   PERMIT	*debug
   PERMIT	traceroute
   DENY	ping	([0-9]{1,3}\.){3}255
   PERMIT	ping
   PERMIT	show

   We allow helpdesk analysts to perform debug, undebug, traceroute, and show. For ping, they are restricted from broadcast pings, assuming the network subnets with broadcast addresses ending with .255, as shown in the regular expression in the argument column.
3. Click the check mark P at the end of each entry to keep the line.
4. Click Save to persist the command set.

iosSecCmds Commands

1. Add a new set and name it IOS_Security_Commands.
2. Click +Add to configure entries to the set:
   

   Grant	Command	Argument
   PERMIT	config*
   DENY_ALWAYS	interface	GigabitEthernet 1
   DENY_ALWAYS	interface	GigabitEthernet [0-9]{1,3} 0
   PERMIT	interface
   PERMIT	shut
   PERMIT	no	shut

   In this sample command set, security administrators may perform shut and no shut operations on any interfaces except the two types of interfaces specified in the DENY_ALWAYS entries, where the second type designates an interface pattern GigabitEthernet <0-999>/0, where '/' is replaced with a space character.

3. Click the check mark P at the end of each entry to keep the line.

4. Click Save to persist the command set.

pemitAllCmds

1. Add a new set and name it Permit_All_Commands.
2. Tick the checkbox ☑ next to Permit any command that is not listed below, and leave the command list empty.
3. Click Save to persist the command set.

Now that you have completed creating the components used in the Policies. Let us take a look at how we can create Policy sets, Authentication and Authorization policy.

Policy sets; Conditions, Authentication and Authorization policy

Policy set condition - An Uber filter

Let us create a Policy set with a condition to filter out the requests from a group of Network devices so that you can apply specific Privileges and permissions. Here we are going to use Network Device Group categorized by Device Type. We already created Network device group for IOS devices that we are going to use here.

1. Navigate to Work Centers > Device Administration > Device Admin Policy Sets. You will see a new Policy set UI that is new in ISE 2.3. Observe the new tabular UI with Hits (hit counts).
2. Click the + button to insert a new row above to add a new Policy Set IOS Devices:
   

   Status	Name	Description	Conditions
   ✓	IOS Devices		DEVICE:Device Type EQUALS All Device Type#IOS-SW

3. Your policy set will look as shown below. Click the > that will give you a policy set view to create authentication and authorization policies
   

Authentication policy

1. Define the Authentication Policy by clicking on the Authentication Policy option.
2. In the Default rule, click the drop down box to add the user identity store you want to use. The UI will show ‘All_User_ID_Stores’, change it to ‘demoAD’ which is the Active Directory join point we configured earlier. Click Save at the bottom right of the screen. In this example for Authentication, we use the Active Directory as the ID Store.
   

   Authentication Policy
   ✓	Default Rule (if no match) : Allow Protocols : Default Device Admin and use: demoAD

Note: Before ISE 2.3, ISE was sending an authentication pass even if the authorization policy says deny access. This is changed since ISE 2.3. If there is no authorization policy match, ISE will use the default authorization policy and send an auth fail.

Authorization Policy

Once authentication is successful, ISE will process the authorization policy list top down. The first matching policy will be applied.

1. Define the Authorization Policy by clicking the Authorization Policy option in the Policy sets => Set view screen. Here we define the authorization policy based on the user groups in Active directory.
2. Create the authorization rule by clicking +, then add the conditions that the authorization policy should satisfy. After that, you need to add the result when these conditions match by choosing the right Command Sets and Shell profile. You need to create 3 authorization rules defined as in the table below.
   

   Status	Rule Name	Conditions	Command Sets	Shell Profiles
   ✓	Admin	demoAD:ExternalGroups EQUALS demo.local/HCC/Groups/Staff	permitAllCmds	iosAdminPrivs
   ✓	Security	demoAD:ExternalGroups EQUALS demo.local/HCC/Groups/Employees	iosSecCmds	iosAdminPrivs
   ✓	HelpDesk	demoAD:ExternalGroups EQUALS demo.local/HCC/Groups/Helpdesk	helpDeskCmds	iosHelpDeskPrivs
   ✓	Default	if no matches, then	Deny All Shell Profile

3. Remember to click Submit to save the policy set each time.

IOS Configuration for TACACS+

Cisco IOS device can be configured in the following sequence for TACACS+:

• Enable TACACS+ Authentication and Fallback
• Enable TACACS+ Command Authorization
• Enable TACACS+ Command Accounting
• Test accessing CSRv router with different credentials

TACACS+ Authentication and Fallback

For device administration using TACACS+, ISE supports both IPv4 and IPv6. A secure remote connection protocol like SSH needs to be enabled as a transport and allowed to connect to the network device. The following sample configuration uses IPv6 for TACACS+

hostname CSRv
no ip domain-lookup
ip domain-name securitydemo.net
crypto key generate rsa modulus 2048

ip ssh version 2

enable secret ISEisC00L
username local-admin privilege 15 secret ISEisC00L

aaa new-model
aaa authentication login CON none
aaa authentication login default local

ipv6 unicast-routing

interface GigabitEthernet1
 ip address 10.1.100.160 255.255.255.0
 ipv6 enable
 ipv6 address 2001:ef8::1/64
  no shutdown

ip access-list extended vtyAccess
 permit tcp 10.1.100.0 0.0.0.255 any eq 22

ipv6 access-list vtyaccessv6
 permit tcp 2001:EF8::/64 any eq 22

line con 0
 exec-timeout 0 0
 login authentication CON
 logging synchronous

!! Below assumes only 5 VTY lines (from 0 to 4)
line vty 0 4
 access-class vtyAccessv6 in
 transport input ssh
 logging synchronous

At this stage, you can SSH to this IOS device from a client in 2001:EF8::/64 subnet using the configured local user while the console login remains without authentication. Note that we disable EXEC timeout for CONSOLE so to avoid possible access issue during AAA configuration.

1. Start a new PuTTY window to SSH to 2001:ef8::1 (CSRv’s IP) login as local-admin/ISEisC00L and enable using the same password ISEisC00L.
2. Issue “exit” after the previous step tested ok to close the test SSH session window.
   Next, we will enable TACACS+ authentication.
3. Back to the console window for CSRv, and issue the following command lines. Note that the TACACS server commands below uses IPv6 address which is the ISE server IPv6 address that you added manually after the initial bootstrap and reboot.
   

   conf t
   
   TACACS server ise-1
    address ipv6 2001:ef8::250:56ff:febd:1aa4
    key ISEisC00L
   
   aaa group server TACACS+ demoTG
    server name ise-1
   
   aaa authentication login VTY group demoTG local
   aaa authentication enable default group demoTG enable
   
   line vty 0 4
    login authentication VTY
   end

You have now switched to TACACS+ to authenticate the VTY lines. Note that the “enable” authentication has the default list only so both VTY and CONSOLE use TACACS+ to authenticate “enable” access.

Note: Note the trailing ‘local’ in ‘aaa authentication command. This is important to ensure service availability even if the TACSACS+ server becomes unavailable. The login authentication then falls back to use the “local” user database while the enable authentication to the “enable” secret.

TACACS+ EXEC Authorization

EXEC Authorization is a special form of command authorization. It happens right after a user login to verify the users’ privileges.

1. At the CSRv console, issue the following to initiate EXEC authorization.
   

   conf t
   
   aaa authorization exec CON none
   aaa authorization console
   aaa authorization exec VTY group demoTG local if-authenticated
   
   line con 0
    authorization exec CON
   line vty 0 4
    authorization exec VTY
   end

   At this point, the shell profiles with the default privilege attribute apply to new SSH sessions.

TACACS+ Command Authorization

TACACS+ Command authorization allows the network device to send a request to ISE when a command is executed. ISE tries to match the request from the network device to list of command sets and allow the command to be executed if there is a match. This is needed to monitor administrator’s actions as well as for audit.

TACACS+ Command Authorization for the configuration mode and for various privilege levels can be enabled by adding the following:

aaa authorization config-commands
aaa authorization commands 1 VTY group demoTG local if-authenticated
aaa authorization commands 15 VTY group demoTG local if-authenticated

line vty 0 4
 authorization commands 1 VTY
 authorization commands 15 VTY

TACACS+ Command Accounting

Command accounting sends info about each command executed, which includes the command, the date, and the username. This can be used for audit. The following adds to the previous configuration example to enable this accounting feature:

aaa accounting exec default start-stop group demoTG
aaa accounting commands 1 default start-stop group demoTG
aaa accounting commands 15 default start-stop group demoTG

Here uses the default method list as we need not distinct accounting based on connection types.

We are done with the IOS configuration for TACACS+.

Testing TACACS+ User Access to CSRv

Last step is to test if the configuration works. Before testing you need to make sure that you use a remote access tool to connect to the network device. You may also want to create some sample test users to validate the behavior and verify the privileges and permissions assigned

1. Use PuTTY to launch a new session to SSH to 2001:ef8::1 (CSRv’s IP), login in turn as various users given in the table below.
2. Make sure you create 3 users admin1, Security1 and helpdesk1 in Active Directory in the respective user group.

Check the results at PuTTY SSH CLI and ISE Admin web console. The table below lists the expected results.

Login Users	Expected Results
	Switch CLI ( Use Putty for CLI access)	ISE TACACS+ Live Logs @ Work Center > Device Administration > Overview > TACACS Livelog
local-admin of the switch	Access denied	Message Text : Authentication Failed: Failure reason: Subject not found in the applicable Identity Store Remote Address: 2001:EF8::DDE3:DD41:xxxx:xxxx (Open up a command prompt window from the Client machine and type ipconfig/all to verify the IPv6 address)
Admin1	Get privileged mode CLI prompt “#”	Authentication and Session Authorization succeeded (Two log entries). Observe the Authorization Policy, Shell profiles, Remote Address used in Authorization logs.
Security1	Get user mode CLI prompt “>” Then, enable OK	Authentication and Session Authorization succeeded ( Two log entries). Observe the difference in Authorization Policy, Shell profiles used in Authorization logs. Observe Authentication Service attribute is enable Optional: Observe the Device Port in the logs, go back to the router (original session using 10.0.0.1) and execute the command “sh line” to view the lines used.
Helpdesk1	Access denied.	Message Text Failed-Attempt: Authentication failed Failure Reason 13036 Selected Shell Profile is DenyAccess Response {AuthenticationResult=Passed; AuthorizationFailureReason=ShellProfileDenyAuthorization; Authen-Reply-Status=Fail; }

Troubleshooting TACACS+ User Access to CSRv

1. Look at the user connections. A sample output is :
   

   CSRv#show users
       Line       User       Host(s)              Idle       Location
      0 con 0                idle                 01:54:52
   *  1 vty 0     neo        idle                 00:00:00 10.1.100.6

2. The following debugs are useful in troubleshooting TACACS+:
   

   debug aaa authorization

   debug TACACS

   debug TACACS packet
   
   

   Here is a sample debug output:
   

   CSRv#debug TACACS
   TACACS access control debugging is on
   ...
   *Jan  4 06:24:43.001: tty2 AAA/AUTHOR/CMD (2087247696): Port='tty2' list='VTY' service=CMD
   *Jan  4 06:24:43.001: AAA/AUTHOR/CMD: tty2 (2087247696) user='admin1'
   *Jan  4 06:24:43.001: tty2 AAA/AUTHOR/CMD (2087247696): send AV service=shell
   *Jan  4 06:24:43.001: tty2 AAA/AUTHOR/CMD (2087247696): send AV cmd=debug
   *Jan  4 06:24:43.001: tty2 AAA/AUTHOR/CMD (2087247696): send AV cmd-arg=TACACS
   *Jan  4 06:24:43.001: tty2 AAA/AUTHOR/CMD (2087247696): send AV cmd-arg=<cr>
   *Jan  4 06:24:43.001: tty2 AAA/AUTHOR/CMD(2087247696): found list "VTY"
   *Jan  4 06:24:43.001: tty2 AAA/AUTHOR/CMD (2087247696): Method=demoTG (TACACS+)
   *Jan  4 06:24:43.001: AAA/AUTHOR/TAC+: (2087247696): user=admin1
   *Jan  4 06:24:43.001: AAA/AUTHOR/TAC+: (2087247696): send AV service=shell
   *Jan  4 06:24:43.001: AAA/AUTHOR/TAC+: (2087247696): send AV cmd=debug
   *Jan  4 06:24:43.001: AAA/AUTHOR/TAC+: (2087247696): send AV cmd-arg=TACACS
   *Jan  4 06:24:43.001: AAA/AUTHOR/TAC+: (2087247696): send AV cmd-arg=<cr>
   *Jan  4 06:24:43.203: AAA/AUTHOR (2087247696): Post authorization status = PASS_ADD
   *Jan  4 06:24:43.203: AAA/MEMORY: free_user (0x7FF239502490) user='admin' ruser='CSRv' port='tty2' rem_addr='10.1.100.203' authen_type=ASCII service=NONE priv=15 vrf= (id=0)
   ...

3. From the ISE GUI, navigate to Operations > TACACS Livelog. All the TACACS authentication and authorization requests are captured here, and the details button provides detailed information about why a particular transaction passed/failed.
4. For historic reports: Go to Work Centers > Device Administration > Reports > Device Administration to get the authentication, authorization, and accounting reports.

Wireless Controllers – WLC

First step before configuring TACACS profiles is to make sure that WLC is added as a Network device(AAA client) and has associated Network device group based on device type, location etc.

Configuring TACACS Profiles

We will define the three TACACS Profiles based on the access privileges required by the administrator

• WLC_Monitor_Only: For Helpdesk with access to the Monitor tab
• WLC_Security_Access: For Security Operators with access to Security and Commands tabs
• WLC_Admin: For Administrators with full access.

Access privileges in Wireless controller are provided based on roles of the administrator. WLC uses attributes that need to be defined in TACACS profiles. The available roles in WLC are MONITOR, WLAN, CONTROLLER, WIRELESS, SECURITY, MANAGEMENT, COMMAND, ALL, and LOBBY. The first seven correspond to the menu options on the WLC admin web UI. You may enter one or more roles to allow read and write access to the particular features, and read-only for the rest. In ISE UI, we have templates for TACACS profiles that has a very similar structure that makes configuration so easy as shown in the snapshot below.

To grant read and write access to WLAN, SECURITY and CONTROLLER, you need the following attributes and values to be sent.

1. In the ISE GUI, go to Work Centers > Device Administration > Policy Results > TACACS Profiles. Add a new TACACS Profile called WLC_Monitor_Only. Scroll down to the Custom Attributes section to define access to only the ◉Monitor. You can check the Raw View for the exact attribute and value associated.
   
   Click Submit button to save the profile.
2. Add another profile called WLC_Security_Access. Choose Selected to provide access to the SECURITY and COMMANDS. Click on Submit to save the profile.
3. Add a third profile called WLC_Admin. Choose ◉All from the selection. This provides access to all the tabs with an attribute and value of ‘role1=ALL.
   
   
   The number in the bottom of the menu changes from 0x0 for MONITOR to 0xfffffff8 for ALL. This is the debug value used by WLC in the logs for each role. This value helps you to troubleshoot access issues to WLC.

Device Admin Policy Sets

Policy Sets are enabled by default for Device Admin. Policy Sets can divide polices based on the Device Types so to ease application of TACACS profiles. For example, Cisco IOS devices use Privilege Levels and/or Command Sets whereas WLC devices use Custom Attributes.

1. Navigate to Work Centers > Device Administration > Device Admin Policy Sets. Add a new Policy Set called WirelessLanControllers with the condition.
   

   Status	Name	Description	Conditions
   ✓	WLC Devices		DEVICE:DeviceType EQUALS DeviceType#All Device Types#Network Device#Wireless Devices

2. Create the Authentication Policy. For Authentication, we will be using the Active Directory (demoAD) as the ID Store.

3. Define the Authorization Policy. Here we will be defining the authorization policy based on the users Group in Active Directory and the location of the user. For example, the users in Active Directory group in each location can access only the devices located in that region whereas other admin users cannot.

   Status	Rule Name	Conditions	Shell Profiles
   ✓	WLC HelpDesk Europe	demoAD:ExternalGroups EQUALS demo.local/HCC/Groups/HelpDesk AND demoAD:ExternalGroups EQUALS demo.local/HCC/location/Germany	WLC_Monitor_Only
   ✓	WLC Security SA	demoAD:ExternalGroups EQUALS demo.local/HCC /Groups/Security_Operators AND demoAD:ExternalGroups EQUALS demo.local/HCC /location/SouthAfrica	WLC_Security_Access
   ✓	WLC Admin APAC	demoAD:ExternalGroups EQUALS demo.local/HCC /Groups/Network_Operators AND demoAD:ExternalGroups EQUALS demo.local/HCC /location/APAC	WLC_Admin
   ✓	Default	DenyAllCommands

This completes the policy configuration in ISE.

WLC Configuration for TACACS+

In order to configure TACACS+ in the WLC controller, you need to complete these steps:

1. Add a TACACS+ Authentication Server
2. Add a TACACS+ Authorization Server
3. Add a TACACS+ Accounting Server
4. Configure the Priority Order of Management User Authentication

Add a TACACS+ Authentication Server

Complete these steps in order to add a TACACS+ Authentication Server.

1. From the WLC GUI, navigate to Security > AAA > TACACS+ > Authentication, and click New...
   
2. Enter the IP address of the ISE server as the TACACS+ server and the shared secret key. Leave the rest as default. Make sure the Server Status is Enabled
3. Click Apply.

Add a TACACS+ Authorization Server

Complete these steps in order to add a TACACS+ Authorization Server.

1. From the WLC GUI, navigate to Security > AAA > TACACS+ > Authorization, and click New...
2. Add the IP address of the ISE server as the server IP address and the shared secret key.
3. Click Apply

Add a TACACS+ Accounting Server

Complete these steps in order to add a TACACS+ Accounting Server.

1. From the WLC GUI, navigate to Security > AAA > TACACS+ > Accounting, and click New...
2. Enter the IP address of the ISE server as the server IP address and the shared secret key.
3. Click Apply

Configure the Priority Order of Management User Authentication

This step explains how to configure the priority order for management user authentication. The default controller configuration is local and RADIUS. With TACACS+, the order of authentication can be TACACS+ and local. You definitely need to have a local authentication method in case the Wireless Controller could not reach ISE. Your administrator should still be able to access WLC with local authentication being a fallback method.

1. From the GUI, go to Security > Priority Order > Management User. Using the arrows, Up, and Down buttons, select and order the Authentication to be TACACS+ followed by LOCAL.
   
2. Click Apply.

Testing TACACS+ User Access

At this point, all the needed configuration for Device Admin for WLC is completed. You will need to validate the configuration.

1. Login to WLC as various users belonging to the different groups and accessing different devices.
2. When you login, verify that the user has access to the right tabs.
3. For a user, who is a Helpdesk user, navigate to the different tabs and try to add/modify/delete. For example, go to WLANs and try to delete one of the WLAN. As this user has only MONITOR access, the operation should be denied with the following error
   
4. From the ISE GUI, navigate to Operations > TACACS Livelog. All the TACACS authentication and authorization requests are captured here and the details button will give detailed information of why a particular transaction passed/failed.
5. For historic reports, on ISE go to Work Centers > Device Administration > Reports > Device Administration to get the authentication, authorization and accounting reports.

Troubleshooting TACACS+ User Access

When a user logs in, you will see traps On the WLC MONITOR page, under Most Recent Traps you should see the following

Wireless controller provides different user roles an assigned number and calls it mgmtRoles.

• LOBBY = 2 < Cannot Be Used with Other Menu Values>
• WLAN = 8
• CONTROLLER = 10
• WIRELESS = 20
• SECURITY = 40
• MANAGEMENT = 80
• COMMANDS = 100

Combination of these roles in the ISE TACACS profile results in the addition of these numbers. For example, if you have WLAN + CONTROLLER + WIRELESS, then the mgmtRole = 0x38.

Here is the debug command used in Cisco Wireless Controller:

(Cisco Controller) debug>aaa TACACS enable
(Cisco Controller) debug>*tplusTransportThread: Aug 31 20:55:43.218: Conecting to TACACS server 10.1.100.243 on port=49
*tplusTransportThread: Aug 31 20:55:43.229: Received tplus auth response: type=1 seq_no=2 session_id=0acd1e9e length=15 encrypted=0
*tplusTransportThread: Aug 31 20:55:43.229: TPLUS_AUTHEN_STATUS_GETPASS
*tplusTransportThread: Aug 31 20:55:43.229: auth_cont get_pass reply: pkt_length=25
*tplusTransportThread: Aug 31 20:55:43.229: processTplusAuthResponse: Continue auth transaction
*tplusTransportThread: Aug 31 20:55:43.544: Received tplus auth response: type=1 seq_no=4 session_id=0acd1e9e length=6 encrypted=0
*tplusTransportThread: Aug 31 20:55:43.545: Created TACACS author request payload(rc=0)
*tplusTransportThread: Aug 31 20:55:43.545: TPLUS_AUTHEN_STATUS_PASS: username=[NetOps1]
*tplusTransportThread: Aug 31 20:55:43.545: Conecting to TACACS server 10.1.100.243 on port=49
*tplusTransportThread: Aug 31 20:55:43.571: author response body: status=1 arg_cnt=3 msg_len=0 data_len=0
*tplusTransportThread: Aug 31 20:55:43.571: arg[0] = [10][role1=WLAN]
*tplusTransportThread: Aug 31 20:55:43.571: arg[1] = [14][role2=WIRELESS]
*tplusTransportThread: Aug 31 20:55:43.571: arg[2] = [16][role3=CONTROLLER]
*tplusTransportThread: Aug 31 20:55:43.571:                User has the following mgmtRole 38

Navigate to Work Centers > Device Administration > Overview > TACACS Livelog to see the authentication/authorization information. You should see the livelogs similar to the following for the two different users.

Navigate to Work Centers > Device Administration > Reports. Go through the TACACS Authentication, Authorization and Accounting reports to get the history of the AAA activities.

Cisco Nexus Platform

Cisco NX-OS helps create logical separation of single Nexus device into multiple logical devices. It introduced support for virtual device contexts (VDCs), which allows the switches to be virtualized at the device level. Each configured VDC presents itself as a unique device to connected users within the framework of that physical switch. The VDC runs as a separate logical entity within the switch, maintaining its own unique set of running software processes, having its own configuration, and being managed by a separate administrator.

Firstly, you need to make sure the network device (AAA client) and corresponding network device groups for device type, location are created in ISE. If you have not done so please go to the earlier section “Creating Network Devices and Network Device Groups” in this document and take care of that first before proceeding further. The AAA client IP address has to correspond to the IP address you plan to use in Nexus for TACACS. In our example below we use the ‘mgmt 0’ interface for this.

Next step is to create a TACACS profile for Nexus. With Nexus you may have to create multiple profiles based on the type of the Nexus switch and its use.

TACACS Profiles

When Cisco NX-OS devices use TACACS+ for authentication, the TACACS+ server returns user attributes along with authentication results, in Cisco VSAs. A vendor-specific attribute (VSA) option is sent using a Cisco-av-pair attribute in the format

<protocol>: <attribute> <separator> <value>

For TACACS+ authentications, the Cisco NX-OS software supports:

• Shell – as the protocol in access-accept packets to provide user profile information.
• Roles – as the attribute in access-accept packets to list all the roles to which the user belongs. The role names are delimited by spaces.

Each user role contains one or more rules that define the operations allowed for the users assigned to the role. Each user can have multiple roles so to execute a combination of all commands permitted by the roles.

The predefined roles on NX-OS devices differ among NX-OS platforms. Two common ones are:

• network-admin – predefined network admin role has complete read-and-write access to all commands on the switch; available in the default virtual device context (VDC) only if the devices (e.g. Nexus 7000) have multiple VDCs. Use NX-OS CLI command “show cli syntax roles network-admin” to see the full command list available for this role.
• network-operator – predefined network admin role has complete read access to all commands on the switch; available in the default VDC only if the devices (e.g. Nexus 7000) have multiple VDCs. Use NX-OS CLI command “show cli syntax roles network-operator” to see the full command list available for this role.

Note: From Cisco NX-OS Release 7.1(4)N1(1), a user with the network-operator role with authorization to create interfaces will not be able to create interfaces. Only a user with the network-admin role can create interfaces.

There are two other ones that are ‘vdc-admin’ and ‘vdc-operator’ meant to manage VDC’s only on Nexus 7000 series. Nexus 6000 and Nexus 5000 series supports the two roles above and an additional role called ‘san-admin’ to separate the tasks on LAN and SAN. Nexus 3000 and below supports only the two roles mentioned above. Please refer the Nexus platform documentation for the support of the user roles across different NX-OS versions.

The recent NX-OS releases allow to create up to 64 user-defined roles in a VDC. User-defined roles, by default, permit access to the commands show, exit, end, and configure terminal only, so we need to add rules and role features to grant additional access.

To see the list of commands allowed by each role feature, issue NX-OS CLI “show role feature name <feature-name>”. To see that for all role features, issue NX-OS CLI “show role feature detail”. The following example shows what is available for the feature interface:

N1Kv# show role feature name interface
interface       (Interface configuration commands)
show interface *
 config t ; interface *

If TACACS+ users have the same user names defined locally on the Cisco NX-OS device, the Cisco NX-OS software applies the user roles for the local user accounts but not those configured on the TACACS+ server.

We will define three TACACS Profiles: NX-OS Operator, NX-OS Admin, and NX-OS Security.

NX-OS Operator

1. From ISE UI, go to Work Centers > Device Administration > Policy Results > TACACS Profiles. Add a new TACACS Profile and name it NX-OS Operator. Go to the Common Task Type drop down and choose Nexus.
   You can see the template changes specific to user role. You can select these options corresponding to the user role you want to configure.
   
2. Select Mandatory from the ‘Set attributes as’ drop down. Select Operator from Network-role option under Common Tasks.
3. If you want to manually configure the VSA, scroll down to the Custom Attributes section to add the attribute as:
   

   Type	Name	Value
   Mandatory	shell:roles	network-operator

4. Click the check mark ✓ at the end of the entry to keep the line.
5. Click the [ Raw View ] tab, and you can see the attributes:
   

   Profile Attributes

   shell:roles=network-operator

   Note: The protocol is a Cisco attribute for a particular type of authorization, the separator is = (equal sign) for mandatory attributes, and * (asterisk) indicates optional attributes.
6. Click Submit to save the profile.

NX-OS Admin

1. Add another profile and name it NX-OS Admin.
2. Select Mandatory from the ‘Set attributes as’ drop down. Select Administrator from Network-role option under Common Tasks.
3. Click the [ Raw View ] tab, and it shows:
   

   Profile Attributes

   shell:roles=network-admin

4. Click Submit to save the profile.

NX-OS Security

1. Add a new TACACS Profile and name it NX-OS Security. Here we will use multiple roles in the profile along with a newly defined user role demo-security, which we will create later in NX-OS, as it is not a standard user role in NX-OS. To create a rule with two roles let us use Custom attributes from ISE UI that will help us configure the roles manually
2. Scroll down to the Custom Attributes section to add the attribute as:
   

   Type	Name	Value
   Mandatory	shell:roles	”network-operator demo-security”

   We enclose the value with double quotes because it has two role names, which are separated by a space character.

3. Click the check mark P at the end of the entry to keep the line.

4. Click the tab [ Raw View ], and it shows:

   Profile Attributes

   shell:roles=”network-operator demo-security”

5. Click Submit to save the profile.

TACACS Command Sets

NX-OS command authorization queries the configured TACACS+ server to verify whether the Device Administrators are authorized to issue the commands. NX-OS normally authorizes on user roles. Nexus 7000, 6000, 5000 series supports command authorization. Nexus 3000 and lower may not support this feature.

Warning! Remember, command authorization disables user role-based authorization control (RBAC), including the default roles in NX-OS. Please be very careful when using this feature. Desist using this in a production environment without proper testing. By default, context-sensitive help and command tab completion show only the commands that are supported for a user as defined by the assigned roles. When you enable command authorization, the Cisco NX-OS software displays all commands in the context sensitive help and in tab completion, regardless of the role assigned to the user.

Here ISE can let you create a list of available commands allowed for command authorization granted to the users.

Let us define three commands sets: NX-OS_HelpDesk, NX-OS_NetworkAdmin, and NX-OS_Security.

HelpDesk Commands

This is the same as that in the guide for IOS devices. Please skip this section if it already defined.

1. On the ISE Administrative Web Portal, go to Work Centers > Device Administration > Policy Results > TACACS Command Sets. Add a new set and name it NX-OS_HelpDesk
2. Click +Add to configure entries to the set:
   

   Grant	Command	Argument
   PERMIT	debug
   PERMIT	undebug
   PERMIT	traceroute
   DENY	ping	^([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.255$
   PERMIT	ping
   PERMIT	show

   We allow helpdesk analysts to perform debug, undebug, traceroute, and show. For ping, they are restricted from broadcast pings, assuming the network subnets with broadcast addresses ending with .255, as shown in the regular expression in the argument column.
3. Click the check mark ✓ at the end of each entry to keep the line.
4. Click Save to persist the command set.

NX-OS NetworkAdmin Commands

This is the same as that in the guide for IOS devices. Please skip this section if it already defined.

1. Add a new set and name it NX-OS_NetworkAdmin.
2. Tick the checkbox next to Permit any command that is not listed below þ, and leave the command list empty.
3. Click Save to persist the command set.

NX-OS Security Commands

1. On the ISE Administrative Web Portal, go to Work Centers > Device Administration > Policy Results > TACACS Command Sets. Add a new set and name it NX-OS_Security.
2. Tick the checkbox next to Permit any command that is not listed below þ.
3. Click +Add to configure entries to the set:
   

   Grant	Command	Argument
   DENY	interface	mgmt0
   DENY	interface	control0

   We allow security analysts to execute any commands other than to configure interfaces mgmt0 and control0.
4. Click the check mark P at the end of each entry to keep the line.
5. Click Save to persist the command set.

Device Admin Policy Sets

Policy Sets are enabled by default for Device Administration. Policy Sets can divide polices based on the Device Types so to ease application of TACACS profiles. For example, Cisco IOS devices use Privilege Levels and/or Command Sets whereas Cisco NX-OS devices use Custom Attributes.

1. Navigate to Work Centers > Device Administration > Device Admin Policy Sets. Add a new Policy Set NX-OS Devices:
   

   Status	Name	Description	Conditions
   ✓	NX-OS Devices		DEVICE:Device Type EQUALS Device Type#All Device Types#Network Devices#NX-OS Devices

2. Create the Authentication Policy. For Authentication, we use the AD as the ID Store.
   

   Authentication Policy
   ✓	Default Rule (if no match) : Allow Protocols : Default Device Administration and use: demoAD

3. Define the Authorization Policy. Here we define the authorization policy based on the user groups in AD and the location of the device. For example, the users in AD group Germany can access only the devices located in Germany.
   

   Status	Rule Name	Conditions	Shell Profiles
   ✓	NX-OS HelpDesk Europe	demoAD:ExternalGroups EQUALS demo.local/HCC/Groups/HelpDesk AND demoAD:ExternalGroups EQUALS demo.local/HCC/location/Germany	NX-OS_Helpdesk
   ✓	NX-OS Security SA	demoAD:ExternalGroups EQUALS demo.local/HCC /Groups/Security_Operators AND demoAD:ExternalGroups EQUALS demo.local/HCC /location/SouthAfrica	NX-OS_Security
   ✓	NX-OS Admin APAC	demoAD:ExternalGroups EQUALS demo.local/HCC /Groups/Network_Operators AND demoAD:ExternalGroups EQUALS demo.local/HCC /location/APAC	NX-OS_NetworkAdmin
   ✓	Default	DenyAllCommands

We are now done with the ISE configuration for Device Administration for NX-OS devices.

NX-OS Configuration for TACACS+

SSH is enabled by default on Cisco NX-OS devices so we need to ensure proper IP addressing for the management interface, before configuring TACACS+.

ip domain-name securitydemo.net
switchname N1Kv

interface mgmt0
ip address 10.1.100.180/24
no shutdown

vrf context management
ip route 0.0.0.0/0 10.1.100.1

!!! disable DNS lookup !!!
no ip domain-lookup

!!! VLANs !!!!
vlan 100
name mgt

!!! Define VTY access !!!
ip access-list vtyAccess
10 permit tcp 10.1.100.0/24 10.1.100.180/32 eq 22
20 deny ip any any

line console
exec-timeout 0
line vty
access-class vtyAccess in

Since we have a valid IP address for the above sample network device at this stage, we can SSH to this NX-OS device from a client in 10.1.100.0/24. Note that we disable EXEC timeout for CONSOLE so to avoid possible access issue during AAA configuration.

Note: Choosing TACACS server at login: You can configure the switch to allow the user to specify which TACACS+ server to send the authenticate request by enabling the directed-request option. By default, a Cisco Nexus device forwards an authentication request based on the default AAA authentication method. If you enable this option, the user can log in as username@hostname, where hostname is the name of a configured RADIUS server. This is supported only for Telnet.

TACACS+ AAA on a Cisco NX-OS device can be configured in the following sequence:

1. Enable TACACS+ Authentication and Fallback
2. Enable TACACS+ Command Authorization
3. Enable TACACS+ Command Accounting

TACACS+ Authentication and Fallback

TACACS+ authentication can be enabled with a configuration similar to the following:

We have thus switched to TACACS+ to authenticate the VTY lines. Since no TACACS+ command authorization yet, the TACACS+ users are currently authorized based on their user roles. You can see that we have enabled a new role called ‘demo-security’ allowing read-write access to feature interface, then limiting access to only vethernet1.

TACACS+ enable

role name demo-security
description A user-defined role example for demo purposes
rule 10 permit read-write feature interface
interface policy deny
   permit interface Vethernet1

TACACS-server host 10.1.100.21 key ISEisC00L timeout 10
TACACS-server host 10.1.100.21 test username tp-test password tp-test idle-time 60

aaa group server TACACS+ demoTG
server 10.1.100.21
deadtime 10
use-vrf management
source-interface mgmt 0

aaa authentication login ascii-authentication
aaa authentication login default group demoTG
aaa authentication login console local

In the events that the configured TACACS+ server becomes unavailable, the login authentication falls back to use the “local” user database.

TACACS+ Command Authorization

This is optional, as users can be authorized on their roles. TACACS+ Command Authorization for the configuration mode and for the EXEC mode can be enabled by adding the following:

aaa authorization config-commands default group demoTG local
aaa authorization commands default group demoTG local

 

TACACS+ Command Accounting

Command accounting sends info about each command executed, which includes the command, the date, and the username. The following adds to the previous configuration example to enable this accounting feature:

aaa accounting default group demoTG

We are done with the NX-OS configuration for TACACS+.

Test and Troubleshoot User access for NX-OS

Configuration for Device Administration for Cisco NX-OS is completed. We will need to validate the configuration.

1. SSH and log into the NX-OS devices as various roles.
2. Once on the device command-line interface (CLI), verify that the user has access to the right commands. For example, a Helpdesk user should be able to ping a regular IP address (e.g. 10.1.10.1) but denied to ping a broadcast address (e.g. 10.1.10.255).
3. To show the user connections and role(s), use the following commands.

   show users
   show user-account [<user-name>]
   A sample output is shown below:
   N1Kv# show users
   NAME     LINE         TIME         IDLE          PID COMMENT
   admin    ttyS0        Jan 11 02:50   .         21234
   hellen   pts/0        Jan 11 02:52   .         21697 (10.1.100.6) session=ssh *
   N1Kv# show user-account hellen
   user:hellen
          roles:network-operator
   account created through REMOTE authentication
   Credentials such as ssh server key will be cached temporarily only for this user account
   Local login not possible...

4. The following debugs are useful in troubleshooting TACACS+:
   

   debug TACACS+ aaa-request
   2016 Jan 11 03:03:08.652514 TACACS[6288]:  process_aaa_tplus_request:Checking for state of mgmt0 port with servergroup demoTG
   2016 Jan 11 03:03:08.652543 TACACS[6288]:  process_aaa_tplus_request: Group demoTG found. corresponding vrf is management
   2016 Jan 11 03:03:08.652552 TACACS[6288]:  process_aaa_tplus_request: checking for mgmt0 vrf:management against vrf:management of requested group
   2016 Jan 11 03:03:08.652559 TACACS[6288]:  process_aaa_tplus_request:port_check will be done
   2016 Jan 11 03:03:08.652568 TACACS[6288]:  state machine count 0
   2016 Jan 11 03:03:08.652677 TACACS[6288]:  is_intf_up_with_valid_ip(1258):Proper IOD is found.
   2016 Jan 11 03:03:08.652699 TACACS[6288]:  is_intf_up_with_valid_ip(1261):Port is up.
   2016 Jan 11 03:03:08.653919 TACACS[6288]:  debug_av_list(797):Printing list
   2016 Jan 11 03:03:08.653930 TACACS[6288]:  35 : 4 : ping
   2016 Jan 11 03:03:08.653938 TACACS[6288]:  36 : 12 : 10.1.100.255
   2016 Jan 11 03:03:08.653945 TACACS[6288]:  36 : 4 : <cr>
   2016 Jan 11 03:03:08.653952 TACACS[6288]:  debug_av_list(807):Done printing list, exiting function
   2016 Jan 11 03:03:08.654004 TACACS[6288]:  tplus_encrypt(659):key is configured for this aaa sessin.
   2016 Jan 11 03:03:08.655054 TACACS[6288]:  num_inet_addrs: 1 first s_addr: -1268514550 180.100.1.10 s6_addr : 0a01:64b4::
   2016 Jan 11 03:03:08.655065 TACACS[6288]:  non_blocking_connect(259):interface ip_type: IPV4
   2016 Jan 11 03:03:08.656023 TACACS[6288]:  non_blocking_connect(369): Proceeding with bind
   2016 Jan 11 03:03:08.656216 TACACS[6288]:  non_blocking_connect(388): setsockopt success error:22
   2016 Jan 11 03:03:08.656694 TACACS[6288]:  non_blocking_connect(489): connect() is in-progress for server 10.1.100.21
   2016 Jan 11 03:03:08.679815 TACACS[6288]:  tplus_decode_authen_response: copying hostname into context 10.1.100.21

5. From the ISE GUI, navigate to Operations > TACACS Livelog. All the TACACS authentication and authorization requests are captured here, and the details button provides detailed information about why a particular transaction passed/failed.
6. For historic reports: Go to Work Centers > Device Administration > Reports > Device Administration to get the authentication, authorization, and accounting reports.

Adaptive Security Appliance (ASA – VPN/Firewall)

ASA supports TACACS+ server authentication and also provides support for TACACS+ attributes. TACACS+ attributes separate the functions of authentication, authorization, and accounting. The protocol supports two types of attributes: mandatory

and optional. Both the server and client must understand a mandatory attribute, and the mandatory attribute must be applied to the user. An optional attribute may or may not be understood or used.

Firstly, you need to make sure the network device (AAA client) and corresponding network device groups for device type, location are created in ISE for ASA VPN/Firewall. If you have not done so please go to the earlier section “Creating Network Devices and Network Devices group” and take care of that first before proceeding further. AAA client IP address should be the IP address of the interface ASA uses to talk to ISE (e.g.: Management IP in the example below).

TACACS Profiles

Cisco ASA provides 16 levels of access privileges for command authorization. Three are defined by default:

• Privilege level 0 – permits show checksum, show curpriv, show history, show version, enable, help, login, logout, pager, show pager, clear pager, and quit commands. Since the minimal accessible level after login is 1, all the commands in this level-0 are available to all users.
• Privilege level 1 – non-privileged or user EXEC mode is the default level for a logged-in user. The shell prompt is the device name followed by an angle bracket, for example “Ciscoasa>”.
• Privilege level 15 – privileged EXEC mode is the level after the enable command. The shell prompt is the device hostname followed by the pound sign, e.g. “Ciscoasa#”.

By default, all commands in ASA are either privilege level 0, 1 or 15. ASDM role-based control predefines three ASDM user roles – Level 15 (Admin), Level 5 (Read Only), and Level 3 (Monitor Only). We will use them in ISE policies and set them up later in ASDM Defined User Roles.

With EXEC authorization, an ASA device sends a TACACS+ authorization request to the AAA server right after authentication to check whether the user is allowed to start a shell (EXEC) session. ISE may push these two attributes to customize it per-user:

• Default Privilege: Specifies initial (default) privilege level for the shell session. Authorized users land in this level instead of 1.
• Maximum Privilege: Specifies the maximum level permitted for the shell session. Authorized users can log in with a lower default level and use the enable command to move to a higher level, up-to the value assigned by this attribute. With external AAA servers, ASA allows enable to 15 only.

ASA Monitor Only

This is to restrict the user to the Home and Monitoring panes in ASDM.

1. On the ISE Administrative Web Portal, go to Work Centers > Device Administration > Policy Results > TACACS Profiles. Add a new TACACS Profile and name it ASA Monitor Only.
2. Scroll down to the Common Tasks section. Enable the Default Privilege with a value of 3 from the drop-down selector, and the Maximum Privilege with a value of 4 from the drop-down.
   
   The maximum privilege of 4 is for illustration only but not used in our case because ASA enable allows for 15 only when using an external AAA server.
3. Click Submit to save the profile.

ASA Read Only

This is to give the user read-only access in ASDM.

1. Add a new TACACS Profile and name it ASA Read Only.
2. Scroll down to the Common Tasks section. Enable the Default Privilege with a value of 5 from the drop-down selector, and the Maximum Privilege with a value of 7 from the drop-down.
3. The maximum privilege of 7 is for illustration only but not used in our case because ASA enable allows for privilege level 15 only when using an external AAA server.
4. Click Submit to save the profile.

ASA Admin

This is to grant unrestrictive access in ASDM.

1. Add another profile and name it ASA Admin.
2. Scroll down to the Common Tasks section. Enable the Default Privilege with a value of 15 from the drop-down selector, and the Maximum Privilege with a value of 15 from the drop-down.
   
   The maximum privilege of 15 is used at ASA CLI when the user issues “enable” at the user EXEC mode.
3. Click Submit to save the profile.

TACACS Command Sets

ASA command authorization queries the configured TACACS+ server to verify whether the device administrators are authorized to issue the commands, regardless of the privilege levels.

We define four commands sets:

1. HelpDesk_Commands
2. Permit_All_Commands
3. ASA Basic
4. ASA_ReadOnly_Extra

HelpDesk_Commands

This is the same as that in the guide for IOS devices. Please skip this section if it already defined.

1. On the ISE GUI, go to Work Centers > Device Administration > Policy Results > TACACS Command Sets. Add a new set and name it HelpDesk_Commands.
2. Click +Add to configure entries to the set:
   

   Grant	Command	Argument
   PERMIT	debug
   PERMIT	undebug
   PERMIT	traceroute
   DENY	ping	^([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.255$
   PERMIT	ping
   PERMIT	show

   We allow helpdesk analysts to perform debug, undebug, traceroute, and show. For ping, they are restricted from broadcast pings, assuming the network subnets with broadcast addresses ending with .255, as shown in the regular expression in the argument column.
3. Click the check mark √ at the end of each entry to keep the line.
4. Click Submit to persist the command set.

Permit_All_Commands

This is the same as that in the guide for IOS devices. Please skip this section if it already defined.

1. Add a new set and name it Permit_All_Commands.
2. Tick the checkbox next to Permit any command that is not listed below þ, and leave the command list empty.
3. Click Submit to persist the command set.

ASA_Basic

1. Add a new set and name it ASA_Basic.
2. Click +Add to configure entries to the set:
   

   Grant	Command	Argument
   PERMIT	show	checksum|curpriv|history|pager|version
   PERMIT	enable
   PERMIT	help
   PERMIT	login
   PERMIT	logout
   PERMIT	pager
   PERMIT	clear	pager
   PERMIT	quit
   PERMIT	exit

   The first entry demonstrates a list of acceptable arguments to follow the command show. It matches any of show checksum, show curpriv, show history, show pager, and show version.
3. Click the check mark √ at the end of each entry to keep the line.
4. Click Submit to persist the command set.

ASA_ReadOnly_Extra

1. Add a new set and name it ASA_ReadOnly_Extra.
2. Click +Add to configure entries to the set:
   

   Grant	Command	Argument
   PERMIT	more
   PERMIT	dir
   PERMIT	export

3. Step 24 Click the check mark √ at the end of each entry to keep the line.
4. Step 25 Click Submit to persist the command set.

Device Admin Policy Sets

Policy Sets are enabled by default for Device Admin. Policy Sets can divide polices based on the Device Types so to ease application of TACACS profiles. For example, Cisco ASA devices use Privilege Levels and/or Command Sets whereas WLC devices use Custom Attributes.

ASDM is driven by menus and other graphical user-interface elements so ASDM access will need more commands allowed compared to ASA CLI.

We will define two policy sets – one to authorize for ASDM access and the other for the rest of ASA administrative access using CLI.

ASDM Access

1. Navigate to Work Centers > Device Administration > Device Admin Policy Sets. Add a new Policy Set ASDM Access:
   

   Status	Name	Description	Conditions
   ✓	ASDM Access		DEVICE:Device Type EQUALS Device Type#All Device Types#Network Devices#Firewalls AND TACACS:Type EQUALS Authorization AND TACACS:Port EQUALS 443

   
   ASDM authorization requests are sent with 443 as the value for TACACS port when using the default HTTPS port. Update the value for this condition to the customized port if ASDM uses an alternative port. The device type called Firewalls should have been created as part of organizing Network Device Groups prior to this step for all the firewalls in your organization or based on location.
2. Create the Authentication Policy. For Authentication, we use the AD as the ID Store and will be used to identify the username in the authorization requests.
   

   Authentication Policy
   ✓	Default Rule (if no match) : Allow Protocols : Default Device Admin and use: demoAD

3. Define the Authorization Policy. ASDM access is governed by the three pre-defined privilege levels so we will give Permit_All_Commands to all authenticated administrators for simplicity.
   

   Status	Rule Name	Conditions	Command Sets	Shell Profiles
   ✓	ASA HelpDesk Europe	demoAD:ExternalGroups EQUALS demo.local/HCC/Groups/HelpDesk AND demoAD:ExternalGroups EQUALS demo.local/HCC/location/Germany	ASA_Basic AND HelpDesk _Commands	ASA Monitor Only
   ✓	ASA Security SA	demoAD:ExternalGroups EQUALS demo.local/HCC /Groups/Security_Operators AND demoAD:ExternalGroups EQUALS demo.local/HCC /location/SouthAfrica	Permit_All_Commands	ASA Admin
   ✓	ASA Admin APAC	demoAD:ExternalGroups EQUALS demo.local/HCC /Groups/Network_Operators AND demoAD:ExternalGroups EQUALS demo.local/HCC /location/APAC	ASA_Basic AND Helpdesk_Commands AND ASA_ReadOnly_extra	ASA Read Only
   ✓	Default	if no matches, then	DenyAllCommands

ASA CLI Access

1. Navigate to Work Centers > Device Administration > Device Admin Policy Sets. Select the existing policy set ASDM Access and [ Duplicate Below ]. As the new policy set ranks below the previous, its conditions can be less specific. Update the duplicated copy and condition it solely on Device Type as below:
   

   Status	Name	Description	Conditions
   ✓	ASA_CLI_access_		DEVICE:Device Type EQUALS Device Type#All Device Types#Network Devices#Firewalls

2. Create the Authentication Policy. For Authentication, we use the AD as the ID Store.
   

   Authentication Policy
   ✓	Default Rule (if no match) : Allow Protocols : Default Device Admin and use: demoAD

3. Define the Authorization Policy. Here we define the authorization policy based on the user groups in AD and the location of the user. You can also include location of the device in the policy set above if you want more granular policies.
   

   Status	Rule Name	Conditions		Command Sets	Shell Profiles
   ✓	ASA HelpDesk Europe	demoAD:ExternalGroups EQUALS demo.local/HCC/Groups/HelpDesk AND demoAD:ExternalGroups EQUALS demo.local/HCC/location/Germany		ASA_Basic AND HelpDesk_Commands	ASA Monitor Only
   ✓	ASA Security SA	demoAD:ExternalGroups EQUALS demo.local/HCC /Groups/Security_Operators AND demoAD:ExternalGroups EQUALS demo.local/HCC /location/SouthAfrica		Permit_All_Commands	ASA Admin
   ✓	ASA Admin APAC	demoAD:ExternalGroups EQUALS demo.local/HCC /Groups/Network_Operators AND demoAD:ExternalGroups EQUALS demo.local/HCC /location/APAC		ASA_Basic AND HelpDesk_Commands AND ASA ReadOnly_extra	ASA Read Only
   ✓	Default	if no matches, then	DenyAllCommands

We are now done with the ISE configuration for Device Admin for ASA devices.

ASA Configuration for TACACS+

Before configuring TACACS+, you need to select the IP address to be used for TACACS+ and a secure transport mechanism for users to login and administer the security appliance. The following configuration enables SSH for the ASA CLI access and HTTP for the ASDM access.

hostname ASAv
domain-name securitydemo.net

crypto key generate rsa modulus 2048 noconfirm

console timeout 0

interface Management0/0
management-only
nameif management
security-level 100
ip address 10.1.100.150 255.255.255.0
no shutdown

route management 0.0.0.0 0.0.0.0 10.1.100.1 1

ssh 10.1.100.0 255.255.255.0 management
ssh timeout 30
ssh version 2

http server enable
http 10.1.100.0 255.255.255.0 management

username sec-admin password ISEisC00L privilege 15

aaa authentication ssh console LOCAL
aaa authentication enable console LOCAL
aaa authorization exec LOCAL auto-enable

Since the sample network device has a valid IP address at this stage, we can SSH to it from a client in 10.1.100.0/24 while the console login remains no authentication. Note that we disable EXEC timeout for CONSOLE so to avoid possible access issue during AAA configuration.

Starting Version 9.5(1), ASA has separate routing table for management-only interfaces. We add a default route to connect the file server that is not in any connected subnet(s).

The auto-enable option for EXEC authorization was added in ASA Version 9.2(1) to make the enable behavior in ASA closer to Cisco IOS so that a device administrator with sufficient privileges needs not enter the password a second time.

To use ASDM, we would need to upload the ASDM binary to disk0: on ASA; for example:

copy http://a.web.file.server/path/to/asdm-752.bin disk0:/

If the Cisco ASDM-IDM Launcher not yet installed, use a web browser to go ASA using https://10.1.100.150/admin and click either [ Install ASDM Launcher ] or [ Run ASDM ]. Without a global enable password, we may point the ASDM-IDM launcher to <ASA management only IP address > and login either with empty username and password or use the local-admin credential.

ASDM allows you to easily configure AAA features using the UI. For the sake of clarity CLI is used in the example below. If you want to use UI a couple of hints I would like to provide. In ASDM, you have to go to Configuration > Device Management > Users/AAA > AAA Server groups to create groups for AAA servers using TACACS+. Next you have to go Configuration > Device Management > Users/AAA > AAA Access and select the set of options in all the three tabs you see for Authentication, Authorization and Accounting. This configuration in turn will be pushed to the ASA appliance as CLI command as described in the next section.

ASDM Defined User Roles

ASDM Defined User Roles represent three privilege levels (3, 5, and 15) for ASDM access. To set them up, ASDM reassigns commands to the three privilege levels. They are then used either in local command authorization directly or as the fall back for TACACS+ command authorization.

Login to ASDM as an ASA admin with full access, navigate to Configuration > Device Management > Users/AAA > AAA Access > Authorization and click on the button [Set ASDM Defined User Roles... ]. Click [ Yes ] in the pop-up window ASDM Defined User Roles Setup.

To see the list of privilege commands configured for this, we may turn on the option [ ☑ Preview commands before sending them to the device ] from Tools > Preferences >General. Click [ Apply ] to send the configuration to ASA and, if the preview option enabled, click [ Send ] in the Preview CLI Commands pop-up window.

AAA on a Cisco ASA device using TACACS+ can be configured in the following sequence:

1. Enable TACACS+ Authentication and Fallback
2. Enable TACACS+ Command Authorization
3. Enable TACACS+ Command Accounting

TACACS+ Authentication and Fallback

TACACS+ authentication can be enabled with a configuration similar to the following:

aaa-server demoTG protocol TACACS+
aaa-server demoTG (management) host 10.1.100.21
key ISEisC00L

clear configure aaa
aaa authentication ssh console demoTG LOCAL
aaa authentication enable console demoTG LOCAL
aaa authentication http console demoTG LOCAL
aaa authentication secure-http-client

We have thus switched to TACACS+ to authenticate the access for SSH and ASDM. All successful logins using TACACS+ for SSH have the privilege level 1 and those for ASDM have the privilege level 15.

The “enable” authentication line is for all types of connections so both VTY and CONSOLE use TACACS+ to authenticate “enable” access. Only the administrators with 15 as the maximum privilege level are able to issue “enable” successfully, because AAA authentication for “enable” is carried out without argument and defaulted to 15.

When configured TACSACS+ server becomes unavailable, both login and enable authentications fall back to use the “local” user database. The users allowed to fall back access should have their local passwords synchronized with the external AAA server for transparent accesses.

Command Authorization

EXEC Authorization

EXEC Authorization is a special form of command authorization. It happens right after a user login and can be enabled by adding the following:

aaa authorization exec authentication-server auto-enable

As noted previously, auto-enable is added in ASA 9.2(1) so skip this option if ASA running older codes. At this point, the shell profiles with the default privilege attribute apply to new SSH sessions.

Starting with Version 9.4(1) ASA separates the EXEC authorization for ASDM from the other types of connections, so we also add:

aaa authorization http console demoTG

Local Command Authorization

Local command authorization allows administrators to use the commands assigned to their privilege levels or below. It is configured as the following:

aaa authorization command LOCAL

TACACS+ Command Authorization

To use TACACS+ command authorization, configure the following:

aaa authorization command demoTG LOCAL

This overrides the lists available for each of the privilege levels and the command list from the TACACS+ server may include commands from higher privilege levels than the administrators’ current privilege levels.

TACACS+ Accounting

ASA may be enabled to log administrative user activities to a TACACS+ server group by

aaa accounting ssh console demoTG
aaa accounting serial console demoTG
aaa accounting enable console demoTG

Command accounting sends info about each command executed, which includes the command, the date, and the username. The following adds to the previous configuration example to enable this accounting feature:

aaa accounting command demoTG

This sends accounting messages for any commands, other than “show” commands. It can take an optional privilege keyword to specify the minimal privilege level; e.g. “aaa accounting command privilege 3 demoTG” will send command accountings for those in Level 3 or above, except for “show”.

We are done with the ASA configuration for TACACS+.

Test and Troubleshoot ASA CLI user access

1. SSH and log into the ASA devices as various roles.
2. Once on the device command-line interface (CLI), verify that the user has access to the right commands. For example, a Helpdesk user should be able to ping a regular IP address (e.g. 10.1.10.1) but denied to ping a broadcast address (e.g. 10.1.10.255).
3. To show the user connections, issue
   

   show ssh sessions
   show asdm sesssions
   show curpriv

   Example:
   

   ASAv# show ssh sessions
   SID Client IP       Version Mode Encryption Hmac     State            Username
   2   10.1.100.6      2.0     IN   aes256-ctr sha1     SessionStarted   hellen
                              OUT  aes256-ctr sha1     SessionStarted   hellen
   ASAv# show asdm sessions
   0 10.1.100.6
   AASAv# show curpriv
   Username : hellen
   Current privilege level : 3
   Current Mode/s : P_PRIV

4. The following debugs are useful in troubleshooting TACACS+:
   

   debug aaa common
   
   debug TACACS
   
   Example debug output:

   mk_pkt - type: 0x1, session_id: 495
   user: neo
   Tacacs packet sent
   Sending TACACS Start message. Session id: 495, seq no:1
   Received TACACS packet. Session id:1117437566  seq no:2
   tacp_procpkt_authen: GETPASS
   
   mk_pkt - type: 0x1, session_id: 495
   mkpkt_continue - response: ***
   Tacacs packet sent
   Sending TACACS Continue message. Session id: 495, seq no:3
   Received TACACS packet. Session id:1117437566  seq no:4
   tacp_procpkt_authen: PASS
   TACACS Session finished. Session id: 495, seq no: 3
   
   mk_pkt - type: 0x2, session_id: 496
   mkpkt - authorize user: neo
   Tacacs packet sent
   Sending TACACS Authorization message. Session id: 496, seq no:1
   Received TACACS packet. Session id:63315798  seq no:2
   tacp_procpkt_author: PASS_ADD
   tacp_procpkt_author: PASS_REPL
   Attributes = priv-lvl
   TACACS Session finished. Session id: 496, seq no: 1
   
   mk_pkt - type: 0x2, session_id: 498
   mkpkt - authorize user: neo
   cmd=ping
   cmd-arg=10.1.1.255  Tacacs packet sent
   Sending TACACS Authorization message. Session id: 498, seq no:1
   Received TACACS packet. Session id:244563180  seq no:2
   tacp_procpkt_author: FAIL
   TACACS Session finished. Session id: 498, seq no: 1

5. From the ISE GUI, navigate to Operations > TACACS Livelog. All the TACACS authentication and authorization requests are captured here, and the details button provides detailed information about why a particular transaction passed/failed.
6. For historic reports: Go to Work Centers > Device Administration > Reports > Device Administration to get the authentication, authorization, and accounting reports.

Role Based Access Control using Prime Infrastructure (PI)

Cisco Prime Infrastructure is a network management tool that supports lifecycle management of your entire network infrastructure from one graphical interface.

Cisco Prime Infrastructure (PI) provides RBAC for administrative access and functions admin users can perform in different parts of PI. The access privileges are built within the user groups that the users are part of. Admin users also need access to virtual domain that groups and helps you manage the network infrastructure. Let us look at these two aspects, User groups and Virtual domains, a little closer for a more complete understanding of RBAC using AAA server such as ISE.

User Groups in PI

User groups carry a list of tasks to control different parts of Prime Infrastructure admin users can access and the functions they can perform when accessing those parts. Users who are part of the user group have all of the privileges assigned to that user group.

When using ISE server to control access to PI, the admin users can be externally defined in Active Directory or in the ISE user database. For RBAC using AAA server, we need to copy the list of tasks from the user groups in PI to a TACACS profile in ISE. The tasks list copied should include the role, task and virtual domain for the admin user to have right access privileges on the PI. The attributes in the TACACS profile are sent to PI once ISE successfully authenticates the user as part of authorization.

Virtual domain in PI

A virtual domain is a logical grouping of sites, devices and access points. You choose which of these elements are included in a virtual domain, and which Prime Infrastructure users have access to that virtual domain. Users with access to a virtual domain can configure devices, view alarms, and generate reports for the parts of the network included in the virtual domain. As part of best practice before you set up virtual domains, always start by determining which admin users are responsible for managing particular sites, devices and access points in your network.

If there is only one virtual domain defined (“ROOT-DOMAIN”) in the system and the user does not have any virtual domains in the attributes listed in the TACACS profile of ISE server, the user is assigned the “ROOT-DOMAIN” virtual domain by default. If there is more than one virtual domain, and the user does not have any specified attributes, then the user is blocked from logging in.

The following diagram captures the idea behind the configuration of PI and ISE.

Here is the default list of user groups available in PI 3.0 add here as reference.

User Group	Provides access to	Editable?
Admin	All Prime Infrastructure administration tasks.	Yes
Config Managers	All monitoring and configuration tasks.	Yes
Lobby Ambassador	User administration for Guest user only.Members of this user group cannot also be members of any other user group.	No
Monitor Lite	Monitoring of assets only. Members of this user group cannot also be members of any other user group.	No
NBI Credential	The Northbound Interface Credential API.	No
NBI Read	The Northbound Interface Read API.	No
NBI Write	The Northbound Interface Write API.	No
North Bound API User	Before the introduction of Prime Infrastructure’s RESTful APIs, there were SOAP-based APIs used for guest user manipulation. This user group is intended for access to such APIs. This group does not control access to RESTful APIs.	No
Root	Superuser access to the web root user. This user group is reserved for the local root user only; no other users should be assigned to this user group.	No
Super Users	All Prime Infrastructure tasks.	Yes
System Monitoring	Monitoring tasks only.	Yes
User Assistant	Local Net user administration only. Members of this user group cannot also be members of any other user group.	No
User-Defined 1	A user-selectable mix of functions.	Yes
User-Defined 2
User-Defined 3
User-Defined 4
mDNS Policy Admin	All mDNS policy administration functions only. ( Note to be used with RADIUS or TACACS or SSO)	No

Prime Infrastructure (PI) Configuration

Adding TACACS+ Servers

1. Open a browser and login to Prime Infrastructure with your Super-User or root privileges.
2. Choose Administration > Users > Users, Roles & AAA > TACACS+ Servers.
3. From the top right, from the drop down ‘Select a command’ choose Add TACACS+ Server > Go.
4. Enter the TACACS+ server information as below, then click Save.
   

   ◉ IP Address	10.1.100.21
   ◯ DNS Name
   Port	49
   Shared Secret Format	ASCII
   Shared Secret	ISEisC00L
   Confirm Shared Secret	ISEisC00L
   Retransmit Timeout	5
   Retries	1
   Authentication Type	PAP
   Local Interface IP	10.1.100.16

   
   Note: Use the local interface IP as IP address of AAA client in ISE.

Setting the AAA Mode

1. Select Administration > Users > Users, Roles & AAA > AAA Mode Settings.
2. Select ◉ TACACS+. Check the [☑ Enable Fallback to Local] check box to enable the user of the local database when the external AAA server is down.
3. With the Enable Fallback to Local selected, select the right option from the drop down when the fallback should occur. Choose “On authentication failure or no server response”.
4. Click Save.

Exporting User Group task list attribute/value pairs

1. Choose Administration > Users > Users, Roles & AAA > User Groups.
2. Locate the row for [Super Users] and click on its [Task List].
3. Right-click on TACACS+ Custom Attributes and Select All. Right-click again and Copy.
4. From your admin PC open a text editor paste the content from the previous step there.
5. Go back to PI admin web UI. Locate the foot note [Virtual Domain custom attributes are mandatory. To add custom attributes related to Virtual Domains, please click here.] and click the hyper-link. Copy the T+ custom attribute for the virtual domain and paste it to the top of the same text editor for the previous step and save the file as pi-superUsers.txt
6. Repeat the steps for the group [ System Monitoring ] and save the contents of text editor as pi-sysMonitoring.txt.

ISE Configuration

ISE Network Devices and AAA Clients

1. 15 Navigate to Work Centers > Device Administration > Network Resources.
2. From the left side panel, go to Network Device Groups, create a new group under Device type and Location for PI, Save it.
3. Now from the left side panel go to Network Devices option. Click ╋Add to add a new network device called ‘PI’ and fill in the necessary information (IP address, shared secret etc), add the Network Device Groups you created above and click the Submit from the bottom.

 

ISE TACACS Profiles

piSuperUsers

1. On the ISE GUI, go to Work Centers > Device Administration > Policy Elements > Results > TACACS Profiles. Add a new TACACS Profile called piSuperUsers.
2. In Common Tasks, select [Generic] as the Common Task Type.
3. Click on the tab [ Raw View ] and copy-and-paste the content of pi-superUsers.txt.
4. Click [ Submit ] when done.
   
   

piSysMon

1. On the ISE GUI, go to Work Centers > Device Administration > Policy Elements > Results > TACACS Profiles. Add a new TACACS Profile called piSysMon.
2. In Common Tasks, select [ Generic ] as the Common Task Type.
3. Click on the tab [ Raw View ] and copy-and-paste the content of pi-sysMonitoring.txt
4. Click [ Submit ] when done.

ISE TACACS Policy Set

1. Navigate to Work Centers > Device Administration > Device Admin Policy Sets. In the left-hand pane, select the Default policy set, and then click on ╋ > Create Above to add a new Policy Set PI:
   

   Status	Name	Description	Conditions
   ✓	PI		DEVICE:Device Type EQUALS Device Type#All Device Types#PI

2. Create the Authentication Policy. For Authentication, we use the AD as the ID Store
   

   Authentication Policy
   ✓	Default Rule (if no match) : Allow Protocols : Default Device Admin and use: demoAD

3. Define the Authorization Policy. Here we define the authorization policy based on the user groups in AD
   

   Status	Rule Name	Conditions		Command Sets	Shell Profiles
   ✓	Admin	demoAD:ExternalGroups EQUALS demo.local/HCC/Groups/Network_operators			piSuperUsers
   ✓	HelpDesk	demoAD:ExternalGroups EQUALS demo.local/HCC/Groups/Helpdesk			piSysMon
   ✓	Default	if no matches, then	Deny All Shell Profile

4. Click Submit to save the policy set.
   
   

Test and Troubleshooting User Access to PI

1. Logoff from PI
2. Create 3 sets of users for network admins, helpdesk and a regular employee in Active directory/ ISE user database.
3. Login to the PI as in turn various users, the expected results are listed below:
   

   Usernames	Login	Administration > Users > Users, Roles & AAA
   Admin	ok	ok
   Helpdesk	ok	Permission Denied You do not have enough permissions to perform this operation.
   Employee	No authorization information found for Remote Authenticated User. Please check the correctness of the associated task(s) and Virtual Domain(s) in the remote server	N/A

Device Administration for Third-Party Devices

For those of you using third party devices, Cisco supports all kind of third party devices because both AAA protocols that ISE supports are based on the TACACS+ protocol. So as long as the third party supports the RADIUS and TACACS+ protocol standards the third party device will work with ISE for device administration. View the ISE compatibility charts for the many devices that we have validated interoperability with.

That said, to implement AAA using TACACS+ you need to know the capability of third party devices as to what it supports for AAA, we have TACACS+ authentication that is usually supported by a lot of vendors and TACACS+ EXEC authorization by lesser number of vendors. TACACS+ command authorization and command accounting may not be supported by every vendor so it is important to know what the third party device support with the help of documentation or by talking to those vendor support if you already bought their appliance.

Then, you need to know the attributes that have to be sent via TACACS+ profile to authenticate, authorize users based on privileges/roles etc.

If your vendor supports RADIUS only, you need to configure these as custom attributes in ISE authorization profile from the respective RADIUS dictionary. ISE has a way to import the RADIUS dictionary in Work Center > Network Access > Dictionaries, go to System > RADIUS > RADIUS Vendors. You will be able to see the vendor dictionaries supported. ISE also allows you to import RADIUS vendors dictionaries from here. Here is the list of Vendors ISE supports out of box.

Here are some additional resources for heterogeneous network device integration with ISE

• Juniper
• Riverbed
• PaloAlto
• Checkpoint
• Other Cisco and Third party
• TACACS community docs/videos, links and two factor authentication
  
  

Operate

Your day to day operations may consist of understanding the global settings, logging, reporting, users changing passwords, retiring passwords for Network devices, purging logs etc.

Global Settings

The global setting under Work Center > Device Administration > Global settings is for TACACS+ lets you tune different parameters such as protocol session timeout, connection timeout for TCP, packet size etc. Please leave this at default. You can allow [Single Connection Support] globally that will enable long term connection for chatty devices. This has to be configured in conjunction with the ‘Single Connect mode’ setting you configure when you add a network device. If this is disabled, then the settings under network devices does not take effect. Another option ‘Retire shared secret’ helps you change the shared secret in the network devices gradually over a time period and works in conjunction with per Network device setting same way ‘Single Connect Mode’ does.

Authorization cache is a feature added during ISE 2.3, that caches the user name and user specific attributes after the first authorization request that can be used for subsequent authorization until the end of TTL. This is to speed up the time taken to authorize the users based on their attributes.

Logging

TACACS logs provides comprehensive logging of events and the steps leading to the events. You have to go to Operatons > TACACS Livelogs to look at the logs. Here is a sample logs that shows authentication, exec authorization and command authorization. You have to click the page icon under details to look at the details

Log Details

Log details provide you with step by step insight on the progress of authentication

Here is a sample log for the use case when admin users tries to change the password (This setting can be found under Work Center > Device administration > Global Setting > Password change control that controls support for password change foe Telnet)

Use PuTTY to launch a new session to SSH to IOS device (e.g:CSR1Kv IPv4 address).

1. Login using the credentials netadmin2 (netadmin2 should be a user account created in AD for Network administrators). if the user is not created in AD you will get the following error in the live log details
   
2. When asked for password, press Enter. It should prompt us for OLD password, followed by new password to change the password. The sequence would be as below:
   

   login as: netadmin2
   Using keyboard-interactive authentication.
   Password: <Hit Enter>
   Using keyboard-interactive authentication.
   Enter Old Password: ISEisC00L
   Using keyboard-interactive authentication.
   Enter New Password: default1A
   Using keyboard-interactive authentication.
   Enter New Password Confirmation: default1A
   CSR1Kv>

   Note: The password change in AD could fail either due to not conforming password complexity policy or due to minimum password age https://technet.microsoft.com/en-us/library/hh994570(v=ws.10).aspx.

   The OLD password in AD might work for a short while after a password change for authentications via NTLM. This is a “feature” of Active Directory introduced in Server 2003 SP1. See http://support.microsoft.com/kb/906305/en-us

3. Check out the steps of the authentication event in the ISE TACACS+ live log. Below is a sample output.

   13013 Received TACACS+ Authentication START Request
   15049 Evaluating Policy Group
   15008 Evaluating Service Selection Policy
   15048 Queried PIP - DEVICE.Device Type
   15048 Queried PIP - TACACS.Service
   15006 Matched Default Rule
   15041 Evaluating Identity Policy
   15006 Matched Default Rule
   15013 Selected Identity Source - demoAD
   13045 TACACS+ will use the password prompt from global TACACS+ configuration
   13015 Returned TACACS+ Authentication Reply
   13014 Received TACACS+ Authentication CONTINUE Request ( [Step latency=1686ms] Step latency=1686ms)
   13046 TACACS+ ASCII change password request
   13015 Returned TACACS+ Authentication Reply
   13014 Received TACACS+ Authentication CONTINUE Request ( [Step latency=5071ms] Step latency=5071ms)
   13046 TACACS+ ASCII change password request
   15041 Evaluating Identity Policy
   15004 Matched rule - Default
   15006 Matched Default Rule
   15013 Selected Identity Source - demoAD
   24430 Authenticating user against Active Directory - demoAD
   24325 Resolving identity – netadmin2
   24313 Search for matching accounts at join point - demo.local
   24319 Single matching account found in forest - demo.local
   24323 Identity resolution detected single matching account
   24343 RPC Logon request succeeded - contractor2@demo.local
   24402 User authentication against Active Directory succeeded - demoAD
   22037 Authentication Passed
   13015 Returned TACACS+ Authentication Reply
   13014 Received TACACS+ Authentication CONTINUE Request ( [Step latency=5061ms] Step latency=5061ms)
   13046 TACACS+ ASCII change password request
   13015 Returned TACACS+ Authentication Reply
   13014 Received TACACS+ Authentication CONTINUE Request ( [Step latency=4752ms] Step latency=4752ms)
   13046 TACACS+ ASCII change password request
   15041 Evaluating Identity Policy
   15004 Matched rule - Default
   15006 Matched Default Rule
   15013 Selected Identity Source - demoAD
   24434 Performing Change Password in Active Directory - demoAD
   24326 Searching subject object by UPN - netadmin2@demo.local
   24328 Subject object not found in a cache
   24330 Lookup SID By Name request succeeded
   24332 Lookup Object By SID request succeeded
   24336 Subject object cached
   24345 RPC Change Password request succeeded
   24425 User change password against Active Directory succeeded - demoAD
   24325 Resolving identity - contractor2
   24313 Search for matching accounts at join point - demo.local
   24319 Single matching account found in forest - demo.local
   24323 Identity resolution detected single matching account
   24343 RPC Logon request succeeded - contractor2@demo.local
   24402 User authentication against Active Directory succeeded - demoAD
   22037 Authentication Passed
   13015 Returned TACACS+ Authentication Reply

Purging Logs

ISE 2.2+ offers extended logging where ISE server can make use of MnT disk space for syslog to up to 60% of the disk space.

However purging logs is a best practice to reutilize space that otherwise may be occupied by unnecessary logs. If you IT policy does not need excessive logging then clean up the logs at regular frequency. You have to go to Administration > System > Maintenance > Operational data purging to configure data retention period (default is 30 days). You can also schedule data purging based on x number of days or Purge now. The tables in the performance and scale community site has information of TACACS data retention period based on your hard disk configuration under ISE Storage requirement section. Use the table as reference for logging. You can also export the logs to a data repository configured as CSV as needed.

Reporting

ISE provides several options for TACACS reports. Beyond the traditional reports for TACACS authentication, authorization, accounting and command accounting, ISE offers summary report for authentication organized by user, network device, PSN, failure reason etc. This will give statistics based on which you can scale the user authentication in your deployment to determine the best way to add additional PSN or to load balance the user authentication. ISE will also provide information on Top N users authenticated, Top N network device used and failed authentications.

Once you view the report, ISE allows you to save the report in ‘My report’ as a favorite or export it as PDF file. You can create report at different time interval. ISE also has active sessions report that will have up to 100 active sessions. Traditional reports also provide an ability to schedule the reports to run at certain time interval. This is not available in the Authentication summary or Top N category reports.

Here is a sample of authentication summary report.

Here is TACACS command accounting report that gives you list of commands and arguments executed per user.

How Do I Get Support?

For technical questions about ISE, please reach out to the ISE Support community page, your partner or local account team.

For advanced troubleshooting issues and outages, contact the Cisco Technical Assistance Center.

 

[Nadav]

This was a great read Krishnan! Thanks for your time and efforts. I think it would be a concise document for network operators who don't feel like going into the nitty gritty of the admin guide. Here are a couple of small notes regarding the document: 1) Page 22: "Patch 5 or above". At present the latest is Patch 4, unless you're aware of a Patch 5 that's meant to be released over the next few weeks. If so that's great news. 2) Page 24: The installation also asks if you want to enable SSH. I was hoping you could address the following question: Have the TACACS+ TPS numbers not improved since ISE 2.1? The ISE Performance & Scale document is updated for RADIUS but for TACACS+ it stops at ISE 2.1.

[kthiruve]

Hi Nadav,

Thank you for the comments. For Device administration around TACACS+ there is nothing new in ISE 2.4. However we are waiting to see when ISE 2.4 is mature and stable and hence the note. The recommended stable release is ISE 2.2 latest patch.

Page 24: Noted your point about SSH, I will update the document. For TACACS+, nothing has changed since ISE 2.2.

Thanks

Krishnan

[Per W]

Thanks for a very nice guide! I think theres a broken link on page 67, Step 13 - "To add custom attributes related to Virtual Domains, please click here." / Per

[quevedo_lopez]

Hi,

How can i download this guide.

Thanks advanced.

[Tom@s!!]

Thanks for this document!!

[Marvin Rhoads]

Note for devices that are using a tacacs source-interface that's in a VRF, be sure to add a statement to that effect in the server-group. e.g.:

ip vrf forwarding Mgmt-vrf

...would be the most common one for devices with a management VRF.

If you don't have this command, the ISE server will get a TACACS request on tcp/49 but not a well/fully-formed one and it will reply with a TCP RST.