Objective I would like to protect access to my network devices (Wired switches, Wireless lan controllers and Firewall) and enhance authentication using MFA. Network Policy Employee’s can connect to my network devices and can view and edit the configurations. Contractors can connect to my network devices but can only view the configurations. Connection Flow   1. User initiates a SSH connection to the router  2. Router sends TACACS+ authentication request to ISE 3. ISE sends RADIUS to Duo Security's authentication proxy 4. Primary authentication uses Active Directory 5. Duo authentication proxy connection established to Duo Security over TCP port 443 6. Secondary authentication via Duo Security's service 7. Duo authentication proxy receives authentication response 8. SSH access granted per ISE Device Admin policy set Assumptions This guide assumes: The reader is familiar with the Cisco Identity Services Engine (ISE) features and functions The reader is familiar with the configuration of ISE AAA functions   Enable ISE Device Administration Service (TACACS) Step 1. Navigate to Administration->System->Deployment Step 2. Enable "Device Administration Service" on the appropriate node Step 3.  Click Save   Configuration for RADIUS communication between ISE and DUO Step 1. On ISE, navigate to WorkCenters->Device Administration->Ext Id Sources->RADIUS Token     Step 2. Click Add Step 3. Starting from left to right, configure the settings within each tab menu item as follows: a. In the General tab, configure a name for the configuration b. In the Connection tab, configure the Primary Server details:       Step 4. Click Submit   Create an Active Directory Join Point in ISE With DUO auth proxy as the authentication ID source, no group information is returned.  As a result, we also connect ISE to Active Directory as the authorization ID source.   Note: If you already have integrated ISE with AD, skip this section   Step 5. Under Work Centers->Device Administration, select the submenu Ext Id Sources. In the left-hand pane, select Active Directory Step 6. Click +Add in the right-hand pane and fill in as below and click Submit. Click "Yes" when asked "Would you like to Join all ISE Nodes to this Active Directory Domain?".     Step 7. In the Join Domain pop-up windows, fill in the necessary details:    Step 8. Click OK to start the join operation.  A window "Join Operation Status" will pop up.  Wait until the node status changes to Completed and then click Close Step 9. Navigate to the Groups tab and add the Employees and Contractors groups   Add Network Device  Step 10. Navigate to Work Centers->Device Administration-> Network Resources-> Network Devices Step 11.  Click Add. Provide Name, IP Address, select TACACS Authentication Settings checkbox and provide Shared Secret key.     Enable Device Administration Step 10. Navigate to Work Centers->Device Administration.  Select Deployment from the left-hand pane to jump to the page Device Administration Deployment.  Select the appropriate ISE node configuration option     Step 11. Click Save when finished   Assigning device administration privileges based on Active Directory group membership Step 12. Navigate to Work Centers->Device Administration->Device Admin Policy Sets Step 13. Configure the identity store for the Authentication Policy to the policy that you configured in step 3a      Step 14. Configure the authorization results within the authorization policy to assign the command sets and shell profiles for each user group.  See below for an example:   Validation SSH to the network device Log in When prompted for password, enter in this exact sequence : “ <login password>, <pin code on Duomobile app>” Once logged in, verify that the user is able to execute the defined command sets To review logs, on ISE Navigate to Operations-> TACACS->Live logs     ... View more

  The goal of this guide is to illustrate the main concepts of TrustSec which are:  Classification: Classifying endpoints and servers with a Scalable Group Tag (SGT) Propagation: Communicating SGT information through the network Enforcement: Enforcing traffic based on the SGT information This guide provides step by step configuration of a sample test environment comprised of a Cisco Catalyst switch, a Cisco Adaptive Security Appliance, and a Cisco Nexus switch. These platforms were chosen to illustrate that a typical TrustSec network utilizes a combination of different classification, propagation, and enforcement methods.  Once you are familiar with the concepts of Cisco TrustSec, you can refer to the other use case specific guides to expand your Cisco TrustSec environment.   Introduction Cisco TrustSec uses tags to represent logical group privilege.  This tag, called a Scalable Group Tag (SGT), is used in access policies. The SGT is understood and is used to enforce traffic by Cisco switches, routers and firewalls. Cisco TrustSec is defined in three phases, classification, propagation and enforcement. When users and devices connect to your network, the network a specific security group. This process is called classification.  Classification can be based on the results of the authentication or by associating the SGT with an IP, VLAN, or port-profile (more on this later in this guide).  Once user traffic is classified, then the SGT is propagated from where classification took place, to where enforcement action is invoked. This process is called propagation.   Cisco TrustSec has two methods of SGT propagation, inline tagging and SXP.  With inline tagging, the SGT is embedded into the ethernet frame. The ability to embed the SGT within an ethernet frame does require specific hardware support.  Therefore network devices that don’t have the hardware support use a protocol called, SXP (SGT Exchange Protocol).  SXP is used to share the SGT to IP address mapping. This allows the SGT propagation to continue to the next device in the path.   Finally an enforcement device controls traffic based on the tag information. A TrustSec enforcement point can be a Cisco firewall, router or switch. The enforcement device takes the source SGT and looks it up against the destination SGT to determine if the traffic should be allowed or denied. If the enforcement device is a Cisco firewall it also allows stateful firewall processing and IPS deep packet inspection using the same source SGT in a single firewall rule.   Using This Guide This guide is written using a best practice approach to configuring a Cisco TrustSec solution from start to finish.  The approach is outlined below: Baseline Cisco Identity Services Engine Configuration for Cisco TrustSec TrustSec Policy Acquisition Classification Propagation Enforcement  This guide should be used as general guidance to configure your TrustSec solution in your network. Below is a sample topology diagram (Figure 2) is used to illustrate a typical enterprise network.  This guide will walk through the general configuration steps to illustrate how to enable TrustSec to classify endpoints and servers with a Scalable Group Tag, propagate Scalable Group Tag information across network, and enforce traffic based on the SGT information.  Additionally general troubleshooting and best practice tips are provided when relevant. The sample configuration used in this guide will enable access for employees, connected at campus and branch locations, to access production servers but not the development servers in the data center.       Note:   Not all platforms that support TrustSec are represented here.  However, the platforms shown cover the configuration commands for TrustSec. Please refer to the following link for a complete listing of platform support:  TrustSec Solution Matrix   Baseline ISE Configuration for TrustSec The Cisco Identity Services Engines (ISE) is commonly used as the central repository for Scalable Group Tags, Scalable Groups, and Scalable Group ACLs. In this section, we are going to configure two of the key policy elements in the TrustSec solution, the Scalable Group Tags (SGTs) and Scalable Groups.  TrustSec uses the SGT, also known as a “tag” to represent a user or device group.  For example, tags such as “Employees_SGT” and “Development Servers_SGT” can represent the user group, “Employees” and the server group, “Development Servers”. These tags are then used as sources and/or destinations in an access policy.   Note :   The scope of this document provides the minimum configuration information needed to support TrustSec functions. It does not cover the advanced ISE functions like complex authentication and authorization of users nor does it cover associated services configuration such as Profiling, Guest management, and On-Boarding for BYOD. Active Directory Integration (optional) This step prepares ISE to associate SGTs with groups in Active Directory.  Obviously, if ISE is already joined to Active Directory for user authentication, this step can be skipped. More details on associating the SGT with an AD group later on in the Classification chapter. Step 1. Navigate to   Administration->Identity Management->External Identity Sources Step 2. Pick Active Directory from the left-hand-side panel,  and click   ADD Step 3. Fill in the join point name and domain name and   SUBMIT     Step 1. Navigate to   Groups Step 2. Select   ADD   and choose "Select Groups from Directory" Step 3. Check all of the groups that you want to associate SGTs with Step 4. Click   OK   and   Save   Defining the Security Groups (SG) and Security Group Tag (SGT) When following best practice guidelines, there are three types of tags.  They are the device SGT, the SGTs used to represent security groups used to define policies, and the unknown tag. A   device tag   is used to represent network devices that communicate with ISE for policy information.  There is additional significance associated with this tag that will be explained in the Enforcement section. By default, ISE defines this tag as "TrustSec_Devices" (as highlighted below)     The   unknown tag,   by default is a SGT=0.  This value cannot be modified.  Any traffic that is not associated with a SGT is subject to the default catch policy or specific policies defined for SGT=0.    Defining Security Groups and SGTs   To accommodate different environments, there are three ways to define SGs and SGTs.  By default, ISE can auto generate the SGTs.  This method is commonly used for lab setup or small deployments. Additionally ISE does provide the ability to manually create any SGT value, the ability to auto-generated from within a specific range,   or import the information from a spreadsheet. The sample configuration uses automatic SGT creation.  The other two methods are shown for reference only.   Auto-generating SGTs Navigate to   Policy->Policy Elements->Results->TrustSec->Security Groups Click the   ADD   button. Create the security group “Employee_SGT” and   Save. Repeat Step 1 to create the remaining SGTs   Figure 3:   Creating Security Groups   Reserving a range or manually defining Security Group Tags Navigate to   Administration->System->Settings->TrustSec Check reserve a range Fill in a range and click the   Save   button Navigate to   Policy->Policy Elements->Results->TrustSec->Security Groups Create the security group using the desired method.     Figure 4:   Reserving a range or manually defining Security Group Tags   Importing SGs and SGTs from a spreadsheet Navigate to   Policy->Policy Elements->Results->TrustSec->Security Groups->Export Complete the spreadsheet Click   Policy->Policy Elements->Results->TrustSec->Security Groups->Import   to import the completed spreadsheet   Defining TrustSec Devices within ISE ISE communicates with network devices for many tasks. In the classification phase, network device queries ISE to authenticate and authorize users and devices. For enforcement, the enforcement device queries ISE to retrieve access policy and keeps its policy table up-to-date. Below you will register the Catalyst 3650, Nexus 1000v, and the Adaptive  Services Appliance  to exchange these pieces of information.   Cisco IOS, NX-OS, IOS-XE devices Navigate to   Administration->Network Resources->Network Devices Edit or Add an entry Select the   Advanced TrustSec Settings   checkbox.  This expands the SGT attributes of the Network Device definition. Enter the values as shown in the table below.     Cisco ASA5500 Adaptive Security Appliances Navigate to   Administration->Network Resources->Network Devices Edit or add a entry for the ASA Within the “Advanced TrustSec Settings”,   set the password to any value.  This password is not used because the ASA supports Out of Band PAC(OOB) PAC provisioning (details in the following step).  You must enter valid and non-empty string in order to save this object.   In the section “Out Of Band (OOB) SGA PAC”, click Generate PAC.  In the pop-up dialog box, input a string as the Encryption Key   Identity <device-id> Encryption Key <a string> PAC Time to Live 1 Years   Note: ASA uses this encryption key to import the PAC securely   Click on   Generate PAC.  In the pop-up window, click   OK   to accept the default   Save File   option to save the resulting pac file to the default Downloads folder Click   Save   to save your changes.   Network Device Authorization In a TrustSec enabled network, all network resources are classified with SGT. This includes a network device itself. All traffic initiated from network device is going to be tagged with a SGT. Previously you defined this SGT as the “TrustSec Device SGT”. Now you will configure ISE to assign this SGT when a network device authenticates against ISE.  Once the switches have this SGT, traffic that is initiated from the switch will be tagged with this SGT.   Navigate to   Policy-> TrustSec -> Network Device Authorization . You will find   Default   rule for   Network Device Authorization. Edit   link of the rule table and change value of SGT from   Unknown   to   TrustSec_Device_SGT. Click   Done   and Click   Save  button at bottom   to save this configuration.   Figure 4:   Assigning a SGT to network devices   TrustSec Policy Acquisition In the previous section, we've configured ISE as the central repository for the list of Scalable Groups and the corresponding SGT values.  In this section, we will configure the network devices to communicate with ISE to pull this information as well as to download communication specific timers.  In order for the network device to query ISE and obtain appropriate policies or policy elements, network devices authenticate to ISE, once authenticated, the device downloads policies.     Catalyst Devices Policy Acquisition 1. Configure the credentials that will be used for Network Device Authorization 3650# cts credentials id <device-id> password <password>   Note:   Device-id and password must match the TrustSec authentication password configured within the Advanced TrustSec Settings within   Administration→Network Resources→Network Devices   on ISE   2. Configure the switch to obtain policy from ISE.  Enter configuration mode and enter the following commands: aaa authorization network cts-list group ise+pac cts authorization list cts-list radius server ISE address ipv4 <ip address of ISE policy servies node> auth-port 1812 acct-port 1813 pac key <secret> exit aaa group server radius ISE server name ISE   Verifying Policy Acquisition Step 3. Verify PAC is provisioned   Switch# show cts pac    AID: 5CA42F60834DE482B716028EAA4EFA8B    PAC-Info: PAC-type = Cisco Trustsec      AID: 5CA42F60834DE482B716028EAA4EFA8B      I-ID: 3k-access A-ID-Info: Identity Services Engine Credential Lifetime: 15:53:10 UTC Oct 29 2014 PAC-Opaque: 000200B800030001000400105CA42F60834DE482B716028EAA4EFA8B0006009C00030100DCC3AF447CA810C1442E417A2FB6F8720000001353D1ABB400093A808ACFEF1042BA878EB3585CEE1B108AE45D6F5896B493430DE24C25686AE418C5EEFDE44606C9D3FB09A0E8AB261C98D00EC9F42567D377636A88CC9125A3FDB458F9A4FBE8AF4530D616584C1B146B920913422B30EA50184D6C72923A364B1735F60857591440879815021F9404868FE2DAA13C1807FCB1464C2C57    Refresh timer is set for 12w4d   Step 4. Environment data download verification   Switch# show cts environment-data CTS Environment Data ==================== Current state = COMPLETE Last status = Successful Local Device SGT:    SGT tag = 2-00:TrustSec_Device_SGT Server List Info: Installed list: CTSServerList1-0001, 1 server(s):   *Server: 10.1.100.21, port 1812, A-ID 5CA42F60834DE482B716028EAA4EFA8B Status = ALIVE auto-test = TRUE, keywrap-enable = FALSE, idle-time = 60 mins, deadtime = 20 secs Security Group Name Table:      0-00:Unknown      2-00:TrustSec_Device_SGT      3-00:Employee      4-00:Production_Servers (reserved)      5-00:Development_Servers (reserved) Environment Data Lifetime = 86400 secs Last update time = 15:54:16 UTC Thu Jul 31 2014 Env-data expires in   0:23:46:47 (dd:hr:mm:sec) Env-data refreshes in 0:23:46:47 (dd:hr:mm:sec) Cache data applied           = NONE State Machine is running    NXOS Devices Policy Acquisition Step 1. Enable TrustSec svs switch edition advanced feature cts feature dot1x cts device tracking   Step 2. Configure the switch to establish a connection with ISE. radius-server host <ip address> key <secret> pac auth-port 1812 acct-port 1813 aaa group server radius cts-radius server <name or IP of ISE Policy Services Node> use management vrf exit aaa accounting default group cts-radius aaa authorization cts default group cts-radius Step 3. Configure the device credential (this MUST match the “device-id (case sensitive) configured within the Advanced TrustSec settings for the N1Kv on ISE).  This command will initiate the communication with ISE. nexus(config)# cts device-id <device-id> password <password> Verifying Policy Acquisition Step 4. Verify PAC file is provisioned   nexus# show cts pac PAC Info : ==============================   PAC Type            : Trustsec   AID                 : a6ee87f55c7131943d615cc1d47025bf   I-ID                : N1Kv   AID Info            : Identity services Engine   Credential Lifetime : Thu Jan  2 22:47:50 2014     PAC Opaque          : 000200b00003000100040010a6ee87f55c7131943d615cc1d47025bf00060094000301005a705134937fede63969e66676ba2cfd00000013524d8aa700093a80ebcf09b38cc61b08e2e24e1e9fb4a9cb3f28907accd3785a356c0f1f3df62df8d673590614ce4adfb083d05eaa906eef3dac86e2f6de0d7e8c5a86a9845b934e6f814de0fbd0d7213d7c77e3c23b4efbf7b34d0893f2588b6768d6f545b7a9b11ce11701336bb269650cfa132df6d39240c60b6a   Step 5. Verify the CTS environment data has been downloaded Nexus# show cts environment-data CTS Environment Data ==============================   Current State           : CTS_ENV_DNLD_ST_ENV_DOWNLOAD_DONE   Last Status             : CTS_ENV_SUCCESS   Local Device SGT        : 0x0002   Transport Type          : CTS_ENV_TRANSPORT_DIRECT   Data loaded from cache  : FALSE   Env Data Lifetime       : 86400 seconds after last update   Last Update Time        : Wed Oct 23 14:40:36 2013     Server List             : CTSServerList1      AID:a6ee87f55c7131943d615cc1d47025bf IP:10.1.100.21 Port:1812 Troubleshooting TIp : If these steps fail, you probably mis-typed the device-id or password.  Below is a sample Live Log entry of the failure.     ASA Policy Acquisition 1. Navigate to   Configuration->Firewall->Identity by TrustSec   (left panel) 2. At the bottom of the resulting page, choose “10.1.100.21” for the Server group 3. Choose "Import PAC" as shown below, to import the PAC.  Enter the password configured within the "Advanced TrustSec Settings" on ISE   4.  Click Apply   Verifying Policy Acquisition 1. Verify PAC file is provisioned.  Navigate to   Monitoring->Properties->Identity by TrustSec->PAC 2. Verify environment data, device SGT, and the SGTs along with their associated group names were downloaded.  Navigate to   Monitoring->Properties->Identity by TrustSec->Environment Data.  Click "Refresh" button if needed.     Troubleshooting Tip : If the environment data download fails check whether you entered the correct password as the password configured under the TrustSec Advanced Settings configuration for your ASA and ensure your ASA has been saved in the ISE network device list. Policy Acquisition Summary Almost all devices supporting TrustSec requires both PAC file to communicate with ISE to download key policy elements and additional information available in the environment data.  Additional information related to this chapter is available in following links:   Cisco TrustSec Catalyst Switch Configuration Guide: http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/ident-conn_config.html Cisco TrustSec for ISRG2: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_cts/configuration/15-mt/sec-usr-cts-15-mt-book.html Nexus 7000: http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6.x_chapter_01101.html Nexus 5000: http://www.cisco.com/en/US/docs/switches/datacenter/nexus5500/sw/security/602_N1_2/b_5500_Security_Config_602N12_chapter_01000.html Nexus 1000v:   http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_2_1_1/security/configuration/guide/b_Cisco_Nexus_1000V_Security_Configuration_Guide_2_1_1_chapter_010001.html   Classification The process of assigning the SGT is called Classification. A SGT can be assigned dynamically as the result of an ISE authorization or it can be assigned via static methods that map the SGT to some thing, like a VLAN, subnet, IP Address, or port-profile.  Dynamic classification is typically used to assign SGT to users because users are mobile. They could be connected from any location via wireless, wired, or vpn.  On the other hand, servers tend not to move, so typically static classification methods are used.   The sample configuration in this chapter assigns users the “Employee_SGT” through dynamic SGT assignment.  SGT assignment for the production and development servers is shown using two static classification methods.  Mapping the SGT to IP addresses and mapping the SGT to a port-profile, which are the only method possible for the virtual servers connected to a Nexus 1000v. Additionally a listing of the other static classification methods is included for switches other than the Nexus 1000v.   For a list of the classification methods  that are supported across Catalyst and Nexus platforms, please refer to the following link:http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/trustsec/cisco-trustsec-platform-capability-ma… Dynamic SGT Assignment To assign the endpoint a SGT during authentication, we must modify authorization policy within ISE. This will allow employees authenticating to the network to be assigned SGT 3. 1. In ISE, Navigate to   Policy->Authorization 2. Add the Employee_SGT to all authorization policies that are associated with employees 3. Click   Save Static SGT Assignment Mapping a SGT to a port-profile (Nexus 1000v) In this section you are mapping the SGTs for production and development servers to a port profile. The port-profiles are mapped to the virtual interfaces of each of the machines using VMware vCenter.   Once the appropriate port-profile is mapped to the VM, every time the VM is powered up, the Cisco Nexus 1000V applies the appropriate port-profile, and associates the SGT to the VM.  This is how classification is done on the Nexus 1000v. 1. Assign the SGT for production server to the port-profile for production servers port-profile type vethernet production cts manual policy static sgt <hex value for SGT> no propagate-sgt Best Practice: “no propagate-sgt” command is necessary because this is a host facing port. Step 2. Assign the SGT for development server to the port –profile for development servers port-profile type vethernet development cts manual policy static sgt 0x5 no propagate-sgt Step 3. Verify the SGTs are associate with port-profiles nexus#   show port-profile name production   port-profile production     type: Vethernet   description:   status: enabled   max-ports: 32   min-ports: 1   inherit:   config attributes:    switchport access vlan 101    switchport mode access cts manual policy static sgt 0x64 no shutdown     evaluated config attributes:    switchport access vlan 101    switchport mode access cts manual policy static sgt 0x64   no shutdown   assigned interfaces:    Vethernet3 Mapping a SGT to an IP Address   Static classification is configured via the CLI or via a central management server like ISE. In this section, both methods are shown to illustrated how a SGT is mapped without the need for authentication.   Using ISE 1. Navigate to   Policy-> Policy Elements-> Results->Trustsec-> Security Group Mappings 2. Reference the following links for further detail:   For ISE 1.3+ : http://www.cisco.com/c/en/us/td/docs/security/ise/1-3/admin_guide/b_ise_admin_guide_13/b_ise_admin_guide_sample_chapter_011000.html#concept_CC328008C562473995FAD97C636BE360   For pre- ISE 1.3: http://www.cisco.com/c/en/us/td/docs/security/ise/1-2/user_guide/ise_user_guide/ise_sga_pol.html#pgfId-1059586 3. Click   Submit 4. Click   Deploy.   This will push the mapping to the switch(es)   Validate IP to SGT Mapping 1. SSH to the switch 2. Type “show cts role-based sgt-map”   Nexus# show cts role-based sgt-map IP ADDRESS SGT            VRF/VLAN       SGT CONFIGURATION 10.1.160.20 100            vrf:1 CLI Configured 10.1.160.21 101            vrf:1 CLI Configured 10.1.160.20 100            vrf:1 CLI Configured 10.1.160.21 101            vrf:1 CLI Configured Using CLI   For Catalyst Devices IP to SGT Mapping switch(config)#cts role-based sgt-map <ip address> sgt <tag value>  Subnet to SGT Mapping switch(config)#cts role-based sgt-map <network>/<length> sgt <tag value>  VLAN to SGT Mapping switch(config)#cts role-based sgt-map <vlan(s)> sgt <tag value>  Port to SGT Mapping switch(config)# port number (e.g. interface g1/0/1) switch(config)#cts manual switch(config)#policy static sgt <tag value> <trusted>   The Catalyst 6500 and 6800 series switches have support for additional static mappings to a vrf or layer 3 interface. Please refer to the following link for further details:  http://www.cisco.com/c/en/us/td/docs/switches/lan/trustsec/configuration/guide/trustsec/command_sum.html#wp1548658   For Nexus Devices IP to SGT Mapping Switch(config)#cts role-based sgt-map <ip address> <sgt-value> VLAN to SGT Mapping   Switch(config)#vlan <number> Switch(config)#cts role-based sgt <sgt-value> Port to SGT Mapping   switch(config)# port number (e.g. interface e1/2) switch(config)#cts manual switch(config)#policy static sgt <tag value> <trusted> Classification Summary You have now completed classifying the users and devices in this TrustSec deployment.  SGT Propagation Now that classification is done, the next step is to propagate the SGTs through the environment to the point of enforcement.  There are two methods of propagation, SGT inline tagging and a peering protocol called SGT eXchange Protocol (SXP).  The three platforms in the sample topology all support inline tagging.  While inline tagging is the preferred propagation method, for illustrative purposes, the connection between the 3650 and the ASA will use inline tagging and the connection between the ASA and the Nexus 1000Kv uses SXP.  Most deployments use a combination of inline tagging and SXP.   Inline SGT between 3650 and ASA   3650 On the interface connected to the ASA's outside interface 3K(config-if)#cts manual 3K(config-if)#policy static sgt <decimal value of SGT> trusted 3K(config-if)#no sap   Note: The ASA does not support SAP currently.  SAP is enabled by default on all switches. Therefore the "no sap" is required for inline tagging to work between a switch and the ASA   ASA Navigate to Configuration->Device Setup->Interfaces Edit the entry for the outside interface On the resulting window, navigate to the Advanced tab Enable inline tagging Click OK and the Apply   Verify inline tagging between 3650 and ASA The ASA has a unique packet capture tool.  Below are the steps to enable the tool to show the SGT   ciscoasa# capture <capture-name> type inline-tag interface <interface-name> real-time From the 3650, initiate a ping to the ASA outside interface 3650#ping 10.1.128.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.128.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/10/30 ms Look at the capture output on the ASA. You will see the icmp packets are tagged with the value of 2 .    1: 14:10:42.278504       INLINE-TAG 2 10.1.128.2 > 10.1.128.1: icmp: echo request    2: 14:10:42.279007       INLINE-TAG 0 10.1.128.1 > 10.1.128.2: icmp: echo reply    3: 14:10:42.282318       INLINE-TAG 2 10.1.128.2 > 10.1.128.1: icmp: echo request    4: 14:10:42.282562       INLINE-TAG 0 10.1.128.1 > 10.1.128.2: icmp: echo reply SXP between Nexus 1000v and ASA In the steps below, you will configure the N1Kv to communicate the Data Center server SGTs to the ASA via SXP.  Remember the goal is to have the ASA act as the enforcement point for user to data center server access, thus it is necessary to communicate the SGTs from the data center to the ASA. Since the N1Kv is communicating the SGTs, the N1Kv is considered the "speaker". The ASA is receiving the SGT information so it is the "listener".   ASA SXP configuration using ASDM   Step 1. Navigate to Configuration->Firewall->Identity by TrustSec and Click the ADD button.     Step 2. Enter the peer’s IP address and specify the ASA’s role     Step 3. Click OK Step 4. On the resulting window, enable SXP and set the password for the SXP connection. This password must match what is configured on the peer device     Step 5. Click Apply   Note: You can verify the SXP connection by navigating to Monitoring→Properties→Identity by TrustSec→SXP Connections.  When the SXP connection between the ASA and the N1Kv is working, the status will show as “ON”.   Configuring SXP on Switches (other than the Nexus 1000v) Between Catalyst Platforms Example: Catalyst 2K(speaker) to Catalyst 3K(listener) 2K(config)#cts sxp enable 2K(config)#cts sxp default password <sxp-password> 2K(config)#cts sxp connection peer <3K IP> source <2K IP> password default mode peer listener Catalyst 3K (listener) to Catalyst 2K(speaker) 3K(config)#cts sxp enable 3K(config)#cts sxp default password <sxp-password> 3K(config)#cts sxp connection peer <2K IP> source <3K IP >password default mode peer speaker vrf <vrf>   Note: You can verify the SXP connection from either switch with the “show cts sxp connection all” command   Between Nexus Platforms Example: Nexus 1000V(speaker) to Nexus 7000(listener) cts sxp enable cts sxp default password <sxp-password> cts sxp connection peer <N7K IP> source <N1Kv IP> password default mode listener Note: On the Nexus 1000v, SXP function is supported on the management VRF only Note: On Nexus platforms, the mode refers to the peer’s mode.  In the example above, the “mode listener” command indicates that the peer device is the SXP listener.   Nexus 7000(listener) to Nexus 1000V(speaker) cts sxp enable cts sxp default password <sxp-password> cts sxp connection peer <N1Kv IP> password default mode speaker Note: You can verify the SXP connection from either switch with the “show cts sxp connection” command   Inline Tagging on Switches (other than the Nexus 1000v)   Best Practice: Bounce (shut and no shut) the interface once configuration is completed  Nexus 5500/6000 Switches cts manual policy static sgt <hex value of SGT> [trusted] Catalyst and Other Nexus Platforms cts manual sap pmk <key> modelist [gcm-encrypt | gmac | no-encap | null] policy static sgt <decimal value of SGT> [trusted] Enforcement  Now that the SGTs are defined and communicated to all of the network devices, enforcement via SGACLs or SGFW is possible.  SGACLs are centrally defined on ISE and pushed/downloaded to both Catalyst and Nexus switches.  SGFW rules are defined locally on the ASA via ASDM. Defining Security Group ACLs (SGACLs) Step 1. On ISE, Navigate to   Policy->Results->TrustSec Step 2. Click the down arrow and select   Security Group ACLs Step 3. Click Add to create a new SGACL.  The example below is a SGACL that can be used to prevent malware propagation.  The SGACL also shows the syntax difference from a typical ACL. Step 4. Click   Save     Note: The list of rules below is provided for you to cut and paste to create your own malware prevention SGACL permit  icmp deny   udp src dst eq domain deny   tcp src dst eq 3389 deny   tcp src dst eq 1433 deny   tcp src dst eq 1521 deny   tcp src dst eq 445 deny   tcp src dst eq 137 deny   tcp src dst eq 138 deny   tcp src dst eq 139 deny   udp src dst eq snmp deny   tcp src dst eq telnet deny   tcp src dst eq www deny   tcp src dst eq 443 deny   tcp src dst eq 22 deny   tcp src dst eq pop3 deny   tcp src dst eq 123 permit tcp Defining Egress Policy within ISE Step 1. Navigate to   Policy->TrustSec->Egress Policy Step 2. Click   Matrix   Note: The matrix view highlights the cell and the corresponding row (Source SGT) and column (Destination SGT) when a cell is selected. The coordinates (Source SGT and Destination SGT) of the selected cell are displayed below the matrix content area. Step 3. Select a cell, click ADD to apply a policy Step 4. Click the orange down arrow and select “NoMalware” for   Assigned Security Group ACLs.     Step 5. Click   Save         Note: Notice the Default, “catch all”, rule is Permit IP. Traffic that does not match the policies defined in the matrix as subject to the Default Egress rule. Enabling Enforcement On Switches In order for a switch to enforce policy, enforcement must be specifically enabled.  Once enforcement is enabled, switches will pull the policy(ies) relevant to the SGTs that they are protecting. Catalyst Devices   Step 1. From the CLI, enable enforcement globally cts role-based enforcement Step 2. Now enable enforcement on the desired vlan cts role-based enforcement vlan <vlan # or all vlans> Nexus 1000v Enforcement on the N1Kv is done at the port-profile level Step 1. Enable enforcement. port-profile type vethernet development cts manual role-based enforcement   port-profile type vethernet production cts manual role-based enforcement Step 4. From the CLI, refresh the policy on the N1Kv n1kv# cts refresh role-based-policy   SGACL Download Verification Step 5. Verify the policy downloaded n1kv# show cts role-based policy sgt:4 dgt:5 rbacl:Deny IP deny ip   sgt:5 dgt:4 rbacl:Deny IP deny ip   sgt:any dgt:any rbacl:Permit IP permit ip Enabling Enforcement on the ASA In this section, we will use ASDM to configure enforcement on the ASA.  Create two rules that use the CTS environment data obtained from ISE to deny ICMP traffic but permit HTTP to each server for the correct identity.   Step 1. From ASDM, navigate to   Configuration->Firewall->Access Rules Step 2. Configure a rule to deny traffic from employees to development servers on the outside interface.  This rule will apply to traffic from employees that are connected via wired or wireless.     Step 3. Click   OK Step 4. Since policies are applied from top down, move the rule just created above the existing “any, any” policy     Step 5. Click   OK Step 6. Add a rule to allow the employees to access the production server.  Click OK Step 7. Click   Apply   Nexus Devices Step 1. Configure role-based enforcement globally and enable  role-based counters so we can verify policy enforcement n1kv(config)# cts enable n1kv(config)# cts role-based counters enable Step 3. Verify the policy is accurate on the Nexus 1000v n1kv(config)# show cts role-based policy sgt:4 dgt:5   rbacl:Deny IP deny ip   sgt:5 dgt:4   rbacl:Deny IP deny ip   sgt:any dgt:any rbacl:Permit IP permit ip    Conclusion In this guide you have learned the best approach to enabling Cisco TrustSec. You have learned that there are three foundational pillars of Cisco TrustSec technology: classification, propagation, and enforcement. Classification is the ability to accept the tag for a particular network authentication session. Propagation, or transport, is the ability to send that assigned tag to upstream neighbors through either native tagging or SXP. Enforcement may be on switches using SGACLs or on an SGFW.   Additionally, we have covered the basic configurations of all of these features across the many supported platforms. ... View more

Overview Securing the network by ensuring the right users, the right access, to the right set of resources is the core function of Cisco’s Identity Services Engine (ISE).  ISE builds context about users (Who), device type (What), access time (When), access location (Where), access type (wired/wireless/VPN) (How), and most important threats, and vulnerabilities. All of these pieces of contextual data is fed into defining logical policy groups, called Scalable Group Tags, for every connected endpoint.  These context-aware tags are then used to form the basis of security policies, centrally managed on ISE and enforced on different parts of the network in a traditional way or using the network fabric- as part of Software Defined Access (SDA).   Duo Security is highly aligned to our intent-based networking vision and strategy, and reinforces our existing ISE and DNA Center capabilities. Additionally, it will help accelerate the adoption of SDA, by extending policy into the cloud and by unifying network segmentation with cloud access control. We are bringing together application zero trust capabilities from Duo, with network zero trust capabilities from SDA, to create the industry's only comprehensive network and cloud access control solution.   Configuration Objective: “I have employees and contractors on my network.  My objective is to securely connect these users by using MFA and then assign them a secure network policy by using ISE for segmentation.  Employees and Contractor’s are on the same network but they cannot talk to each other.  Employee’s get full access to my on-prem network resources or network resources in my data center, Contractors get limited network access.   Configuration Overview: Configure ISE’s web-based authentication portal as a protected application with Duo MFA.  After successful 2FA, ISE grants users network access based upon Group-Based Policies.   Segmentation Policy: Employees connect to the network and get a network policy with SGT=Employee Contractors connect to the network and get a network policy with SGT=Contractor   Connection flow: Users connects and is redirected to ISE portal ISE redirects the unauthenticated request to the Duo Access Gateway (DAG) Because the ISE portal is a protected application, prompts the user for authentication Users’s credentials are verified against Active Directory DAG then sends notification for MFA Users get a notification for DUO PUSH, Users click “Approve” on mobile device DAG receives authentication success notification. ISE receives response ISE authorizes network access and pushes Employee or Contractor Scalable Group Tag (SGT) As per SGT-based network policy, Employees and contractors are on the same Layer 2 network but cannot talk to each other (East-West segmentation/Microsegmentation)   Configuration Part 1: Protecting ISE web portal with Duo MFA The Duo terminology “protecting an application” simply means that access to that application is redirected through the Duo Access Gateway.  This redirection is necessary to add in second factor authentication before allowing application access (this assumes that network layer access is not restricted).  In addition, the DAG can also enforce additional application policies such as checking the user, device, and network permissions specified by the DUO Administration panel.   Adding an application to Duo    Note: Before proceeding it is assumed that an identity source has been configured. If this step has not been done,  please reference Duo Access Gateway for more details. The steps below ties in the ISE Guest web portal as a protected application to add in the secondary authentication sequence with Duo PUSH. ISE Guest allows users to gain network access via a HTTP or HTTPS login. Duo Single Sign on will then initiate the 2 nd authentication back to the user via DUO push.     Log into your DUO Access Gateway In the left side bar, navigate to Applications Scroll down to the center of the page to the MetaData section and click “download XML metadata” and save the file Log into ISE Navigate to Administration->Identity Management->External Identity Sources->SAML ID Providers Click ADD On the resulting window, starting from left to right, configure the settings within each tab menu item as follows:  In the General tab, use “duoSAML” as the Id Provider Name In the Identity Provider Config tab, upload the xml file from Step 3  Skip the Service Provider Info tab, you’ll come back to it later In the Groups tab, select the user groups relevant to your authentication requirements Click Submit  8. Navigate to Work Centers->Guest Access->Portals & Components->Guest Portals 9. Click the link Sponsored Guest Portal (default) 10. Expand “Portal Settings” and select the profile name configured in step 5a. (e.g. duoSAML) 11. Click Save 12. Navigate back to Administration->Identity Management->External Identity Sources->SAML ID Providers-duoSAML 13. From the Service Provider Info tab, click Export and save the resulting zip file.   Note: The files in this zip contain the application configuration data required to bind Duo to the ISE guest portal     Binding  ISE web authentication portal with Duo 15. Extract the zip and view the extracted xml file 16. Search for the "Entity ID" string and copy the resulting string ( the string would look something link this: "http://CiscoISE/f079c670-7159-11e7-a355-005056aba474") 17. Log in to the Duo Admin Panel and click Applications, and then click Protect an Application 18. Locate SAML Service Provider in the list of applications, and then click the Protect this Application link. 19.  Enter the following information: Name Description Service Provider Name e.g. ISE Portal Entity ID copied string from Step 16 Assertion Consumer Service https://<ISE FDQN>:8443/portal/SSOLoginResponse.action   20. Scroll to the bottom and click Save Configuration button and download the configuration file.   Add ISE Portal to Duo Access Gateway 21. Log in to the Duo Access Gateway 22. Navigate to Applications. Upload the .json configuration file from Step 20   Verifying ISE and DUO MFA 23. On ISE, navigate to Work Centers->Guest Access->Portals -> Components->Guest Portals 24. Click the link Sponsored Guest Portal (default) 25. Right click and copy the link for “Portal Test URL” Paste the link address into a text editor Change the link address from using  the ISE IP to the ISE FQDN (include port 8443)   Note:  These steps are to workaround an ISE defect 26. Paste the edited link into a browser.  After successfully authenticating, you should see the following pop up   27. Click Continue.  This concludes the test Finalizing ISE and Duo MFA Integration In the steps below, you will enable web authentication so that users are redirected to the ISE Guest Portal to start the MFA process.   28. Log into ISE, navigate to Policy->Policy Elements->Results->Authorization->Authorization Profiles 29. Create an authorization profile, such as “WebAuth Wired DUO”, with the following configuration:      30. Continue to scroll down within Common Tasks to select “Web Redirection”. Configure as follows:   31. Click Submit 32. Navigate to Policy->Policy Sets 33. Expand the default policy set by clicking the > on the right of the screen     The resulting view will look like this:       34. Expand Authorization Policy. Add new policies that reference the SAML groups from Step 7.  Also modify the Default policy to user the "WebAuth Wired DUO" profile rather than "Deny Access"    Note: Also disable the Basic_Authenticated_Access rule  35.  Click Save   Configuration Part 2: Securing Network Access with Micro-Segmentation   In the previous exercise you configured ISE and DUO to work together to secure the network connection process  with Duo MFA.  Now that the user is connected, in the steps below you will further secure network access using group-based segmentation. In the example below, the policy created will mitigate the spread of malware between Employees and Contractors.     Note: For clarity, configuration specific to backend TrustSec functions is omitted from the steps below.  Please reference the Appendix for TrustSec specific configuration details.   1. On ISE, navigate to Work Centers->TrustSec->TrustSec Policy 2. Select ADD in the policy matrix menu 3. Configure new policies as follows:     4. Click Save   Note:  The “Anti-Malware SGACL” contains rules that deny specific tcp and udp traffic. To review the rules contained within this SGACL, navigate to Work Centers->TrustSec->Components->Security Group ACLs    Appendix TrustSec Configuration Configuring Identity Services Engine for TrustSec Classification Every TrustSec deployment starts with classification. Classification is the process of defining and assigning a Security Group Tag (SGT) that is used to represent the group a server or user belongs to. These classifications are downloaded to TrustSec devices that will either forward them to other TrustSec devices and/or use them for enforcement.   This example has the users categorized as employees and contractors which are pre-defined security groups in ISE.  By default, ISE has 16 pre-defined, commonly used, security groups. 1.    Defining TrustSec Devices within ISE ISE communicates with network devices for many tasks. In the classification phase, network device queries ISE to authenticate and authorize users and devices. For enforcement, the enforcement device queries ISE to retrieve access policy and keeps its policy table up-to-date. In the following section you will register the 3k-access switch to exchange these pieces of information   TrustSec Switches 1. Navigate to Work Centers→TrustSec→Components→Network Devices 2. Edit/Add your access layer switch 3. Select the Advance TrustSec Settings checkbox.  This expands the SGT attributes of the Network Device definition. 4. Set the password 5. Click Save   SGT Assignment Device SGT In a TrustSec enabled network, all switches that join the TrustSec domain are classified with a SGT (commonly referred as the “device SGT”).  This classification occurs as result of the switches authenticating to ISE, a process called Network Device Admission Control (NDAC).  Once the switches have this SGT, traffic that is initiated from the switch will be tagged with this SGT.   1. Navigate to Workcenters->TrustSec->Policy->Network Device Authorization 2. Click “Edit” (you may need to scroll to the right to see this) 3. Modify the rule to use the TrustSec_Device_SGT tag as shown below 4. Click Save   TrustSec Policy Acquisition Policy Acquisition phase in the TrustSec architecture is to establish pipeline between network device and ISE, and eventually download necessary policies for enforcement. Information exchanged in this pipeline would be Security Group Tag value and its name, Device SGT, and other policy expiration timer to keep the policy up-to-date on each device. In order for network device to query ISE and obtain appropriate policies or policy elements, network devices authenticate to ISE, claiming its privilege to download such policies. We are going through configurations based on the network device type. Policy Acquisition on 3650 1. Configure the credentials that will used for NDAC 3k-access#cts credentials id 3k-access password ISEisC00L 2. Configure the 3650 to obtain policy from ISE. Enter configuration mode (configure terminal) and enter the following commands: aaa authorization network CTS-MLIST group radius cts authorization list CTS-MLIST radius server ise-1  address ipv4 10.1.100.21 auth-port 1812 acct-port 1813  pac key ISEisC00L  exit server name ise-1 Verifying Policy Acquisition on 3650 Verify PAC is provisioned on 3650 3k-access#show cts pac    AID: 5CA42F60834DE482B716028EAA4EFA8B    PAC-Info:      PAC-type = Cisco Trustsec      AID: 5CA42F60834DE482B716028EAA4EFA8B      I-ID: 3k-access      A-ID-Info: Identity Services Engine      Credential Lifetime: 15:53:10 UTC Oct 29 2014    PAC-Opaque: 000200B800030001000400105CA42F60834DE482B716028EAA4EFA8B0006009C00030100DCC3AF447CA810C1442E417A2FB6F8720000001353D1ABB400093A808ACFEF1042BA878EB3585CEE1B108AE45D6F5896B493430DE24C25686AE418C5EEFDE44606C9D3FB09A0E8AB261C98D00EC9F42567D377636A88CC9125A3FDB458F9A4FBE8AF4530D616584C1B146B920913422B30EA50184D6C72923A364B1735F60857591440879815021F9404868FE2DAA13C1807FCB1464C2C57    Refresh timer is set for 12w4d Verify the CTS environment download data has been downloaded 3k-access#show cts environment-data  CTS Environment Data  ====================  Current state = COMPLETE  Last status = Successful  Local Device SGT:    SGT tag = 2-00:TrustSec_Device_SGT  Server List Info:  Installed list: CTSServerList1-0001, 1 server(s):   *Server: 10.1.100.21, port 1812, A-ID 5CA42F60834DE482B716028EAA4EFA8B            Status = ALIVE            auto-test = TRUE, keywrap-enable = FALSE, idle-time = 60 mins, deadtime = 20 secs  Security Group Name Table:      0-00:Unknown      2-00:TrustSec_Device_SGT      3-00:Network_Services      4-00:Employees      5-00:Contractors  Environment Data Lifetime = 86400 secs  Last update time = 15:54:16 UTC Thu Jul 31 2014  Env-data expires in   0:23:46:47 (dd:hr:mm:sec)  Env-data refreshes in 0:23:46:47 (dd:hr:mm:sec)  Cache data applied           = NONE  State Machine is running   ... View more