Cisco TrustSec
™
2.0:
Design and Implementation Guide
Contents
Contents ... 2
Introduction ... 4
What is the Cisco TrustSec System? ... 4
About This Document ... 4
Scenario Overview ... 5
Architecture ... 5
Components ... 6
Enforcement Discussion ... 9
Predeployment Check List ... 11
Common Configuration: All Use Cases ... 13
Introduction ... 13
Universal Cisco ISE Configuration ... 13
General Settings – Certificates and Certificate Authorities ... 13
Active Directory Integration ... 18
Universal Cisco ISE Configuration – Device Profiling ... 25
Universal Cisco ISE Configuration: Guest ... 37
Introduction ... 37
Supplicant Configuration ... 48
Cisco AnyConnect Network Access Manager ... 48
IP Phones ... 58
Switches – Universal Global Configuration Commands ... 59
Example Global Configuration: ... 64
Switches: Universal Switchport Configuration ... 65
Wireless – Universal Configuration ... 69
Base-‐Identity Use Cases ... 81
Introduction ... 81
Phase 1: Monitor Mode ... 85
Configure Monitor Mode ... 85
Monitoring in Monitor Mode ... 94
Phase 2: Authenticated Mode ... 99
Wired Access ... 99
Wireless Access ... 107
Elaboration on Wireless Access ... 108
Wireless in Branch Offices ... 108
Web Authentication ... 109
Committing to Authenticated Mode ... 118
Device Behind Phone Disconnects: The Link State Problem ... 139
Expanded Services ... 141
Introduction to Security Group Access ... 141
SGA Use Cases ... 141
Access Layer to Data Center ... 141
Intra-‐Data Center Enforcement ... 143
Additional Security Group Access Information ... 156
Posture Assessment ... 161
Introduction ... 161
Client Provisioning ... 161
Posture Policy ... 161
Authorization Policy ... 161
Cisco NAC Agent 4.9.0 Discovery Process ... 170
Appendix A: Cisco ISE Design Notes ... 171
Standalone: ... 171
Basic 2-‐Node Deployment: ... 171
Distributed Deployment, Up to 10,000 Endpoints ... 172
Distributed Deployment, Up to 100,000 Endpoints ... 172
Appendix B: References ... 178
Introduction
What is the Cisco TrustSec System?
The Cisco TrustSec® System is an advanced Network Access Control and Identity Solution that is integrated into the Network Infrastructure. It is a fully tested, validated solution where all the components within the solution are thoroughly vetted and rigorously tested as an integrated system.
Unlike overlay Network Access Control solutions, the Cisco TrustSec system utilizes the access layer devices (switches, wireless controllers, etc.) for enforcement. Functions that were commonly handled by appliances and other overlay devices, such as URL redirection for web authentications, are now handled by the switch itself. The Cisco TrustSec system not only combines standards-based identity and enforcement models, such as IEEE 802.1X and VLAN control, it also has many more advanced identity and enforcement capabilities such as flexible authentication, Downloadable Access Control Lists (dACLs), Security Group Tagging (SGT), device profiling, posture assessments, and more.
Figure 1: Cisco TrustSec Architecture Overview
About This Document
This document describes the best practice for Cisco TrustSec deployments. It is a validated system that has undergone thorough architectural design development and lab testing. For a configuration or feature to be included in this document, it must meet the following criteria:
• Products incorporated in the design must be generally available.
• Deployment, operation, and management of components within the system exhibit repeatable processes. • All configurations and products used in the design must have been fully tested as an integrated solution. Many features may exist that could benefit your deployment, but if they were not part of the tested solution they will not be included in this document. The Cisco TrustSec team at Cisco strives to provide regular updates to this document that will include new features as they become available, and are integrated into the Cisco TrustSec test plans, pilot deployments, and system revisions (i. e., Cisco TrustSec 2.1).
Additionally, many features and scenarios have been tested, but are not considered a best practice, and therefore are not included in this document. (Example: certain 802.1X timers and local web authentication)
Note: Within this document, we describe the recommended method of deployment, and a few different options depending on the level of security needed in your environment. These methods are examples and step-by-step instructions for Cisco TrustSec deployment as prescribed by best practices to ensure a successful project deployment.
Warning: The document has been designed to be followed from beginning to end – bypassing sections may have undesirable results.
Scenario Overview
Architecture
Figure 2 depicts an end-to-end Cisco TrustSec architecture. While all the scenarios pictured in Figure 1 were part of the solutions test, this document will focus on the wired and wireless user scenarios along with SGA
enforcement in the Data Center only. No VPN or VDI scenarios are covered in this version.
This document focuses on Authentication in the access layer of the network, applying ingress filter control (control at the entry point to the network). Additionally, future capabilities will use the power of a Cisco® infrastructure to allow tagging of traffic at the ingress point and enforcement of that control at egress.
Figure 2: Cisco TrustSec Architecture
In the previous release of Cisco TrustSec (1.99), the solution provided basic network access control by integrating 802.1X technologies with Cisco Catalyst® Switch families, Cisco Secure Access Control System 5.2 (ACS), and Cisco Secure Services Client 5.1 (Cisco SSC). With those products, managed users and devices authenticate to the network using 802.1X authentication and are authorized based on various attributes such as user role, device role, location, and time. The Cisco TrustSec 1.99 solution also added an ability to serve guest users for wired networks by integrating Cisco NAC Guest Server 2.03, making the whole guest management lifecycle much easier. Authenticated sponsors can provision guest accounts, notify users, manage duration of guest access, and monitor the account validity.
With the introduction of Cisco TrustSec 2.0, we are going to have 3 major changes on top of the previous release: First, we have consolidated the functions from Cisco ACS 5.0 and Cisco NAC Guest Server 2.0 into the Cisco Identity Services Engine 1.0 (ISE). Cisco ISE is Cisco’s next-generation policy server that provides authentication and authorization infrastructure to the Cisco TrustSec solution. It also provides two other critical services. The first service is to provide a way to profile endpoint device type automatically based on attributes Cisco ISE receives from various information sources. This service (called Profiler) provides equivalent functions to what Cisco has previously offered with the Cisco NAC Profiler appliance. Another important service that Cisco ISE provides is to scan endpoint compliancy; for example, AV/AS software installation and its definition file validity (known as Posture). Cisco has been previously providing this exact posture function only with the Cisco NAC Appliance. Cisco ISE provides an equivalent level of functionality, and it is integrated with 802.1X authentication mechanisms.
Secondly, Cisco TrustSec 2.0 adds support for Wireless user access. With Cisco TrustSec 2.0, Cisco ISE provides the same authentication methods regardless of user access methods, which could be from wired line or Wi-Fi connection. Cisco ISE is also used to provide profiling mechanisms of mobile devices such as Apple iDevices (iPhone, iPad, and iPod), Android-based smartphones, and others. For 802.1X users, Cisco ISE can provide the same level of services such as profiling and posture scanning. Guest services on Cisco ISE can also be integrated with the Cisco Wireless LAN Controller by redirecting web authentication requests to Cisco ISE for authentication. The last major change in the Cisco TrustSec 2.0 revision is the introduction of Security Group Access (SGA) with Cisco ISE integration. Security Group Access (SGA) is a technology where a unique security tag is used to filter traffic from a specific source to a specific destination. For instance, a contractor authenticates to the network using the Web Authentication portal, and that contractor can be assigned to a specific security group named:
CONTRACTOR. All the traffic this user is going to inject into the network will be tagged as CONTRACTOR and routed to the point where policy is enforced. When this tagged traffic reaches to the point where the destination resource is connected, the network infrastructure enforces a policy known as the Security Group Access Control List (SGACL). SGA moves the traffic filtering point from traditional ingress enforcement to egress enforcement, making the system much more scalable to support today’s business requirements.
Components
Table 1: Cisco TrustSec 2.0 System Tested Components
Component Hardware Features Tested Cisco IOS® Software
Release Cisco Identity
Services Engine (ISE)
Any: 1121/3315, 3355, 3395, VMware
Integrated AAA, policy server, and services (guest, profiler, and posture)
ISE 1.0(377) Cisco Catalyst 29xx Switch Cisco Catalyst 3xxx Switches 2960, 2960S, 3560, 3560E, 3560X, 3750, 3750E, 3750X
Basic Identity features, 802.1X authentication, Profiling, and Change of Authorization (CoA)
12.2(55)SE3
3560X, 3750X MACsec Switch-to-Switch 15.0(1)SE1 Cisco Catalyst 4500
Switches
Not tested in 2.0 Not tested in 2.0 Not tested in 2.0 Cisco Catalyst 6500
Switches
Supervisor Engine 32 and Supervisor Engine 720
Basic Identity Feature, 802.1X authentication, SXP, SXP IPv6, VRF-Aware Cisco TrustSec security, Profiling, and Change of
Authorization (CoA)
12.2(33)SXI7
Supervisor Engine 2T Basic Identity Features, 802.1X authentication, SXP, MACsec Switch-to-Switch, SGT and SGACL enforcement, Profiling, and Change of Authorization (CoA)
12.2(50)SY
Cisco Nexus® 7000 Switches
MACsec switch-to-switch, SGT, and SGACL enforcement
5.2.1 Cisco AnyConnect™
technology
Integration of 802.1X supplicant (no MACsec) AnyConnect 3.0.0631 Wireless LAN
Controller (WLC)
Profiling and Change of Authorization (CoA) Unified Wireless 7.0.116 Cisco ASR 1000 Series Aggregation Services Router Cisco ASR 1000 Series Route Processor 1 (RP1) and RP2, 1001, 1002, 1004, 1006, and 1013; Cisco ASR 1000 Series Embedded Services Processor 10 (ESP10), ESP20, and ESP40; and
Cisco ASR 1000 Series SPA Interface Processor 10 (SIP10) and SIP40
SGA integration – SXP/SGT for tagging at WAN aggregation layer or extranet
3.4
Cisco IP Phone Cisco Unified IP Phone 7960 and 7961; 7962 and 7969; and 7940, 7941, and 7942
Cisco IP Phones tested in the system-level test
Table 2: Supplicants Tested in Cisco TrustSec 2.0
Vendor Software Supplicant
Microsoft Windows 7 Wired Auto Config Service (Native Supplicant) Cisco Secure Services Client 5.1.1.17 Cisco AnyConnect 3.0.0631
Windows Vista with SP2 Wired Auto Config Service (Native Supplicant) Cisco Secure Services Client 5.1.1.17 Cisco AnyConnect 3.0.0631
Windows XP with SP3 Wired Auto Config Service (Native Supplicant) Cisco Secure Services Client 5.1.1.17 Cisco AnyConnect 3.0.0631
Apple MacOS 10.6.5 Eapolclient (Native Supplicant)
In the architecture for this document, we have used various Cisco network devices to validate component interaction, functions, and integration. We have a Campus network segment, a Data Center network segment, a WAN segment, and a Branch-office segment. In the Campus network, a Cisco Catalyst 3560-X Series Switch is used for the access layer. A Cisco Catalyst 6500 switch with Supervisor Engine 2T is used to aggregate all access layer switches. This Cisco Catalyst 6500 Switch is connected to the Data Center segment, which consists of 2 sets of Cisco Nexus 7000 switches (Core and Distribution) using Virtual Device Context (VDC) technology, and a Cisco Catalyst 4948 Switch as the Data Center access (Top Of the Rack) switch.
Table 3 lists the components (Non-network Equipment) and associated information.
Table 3: Components
Component IP Address Description
Microsoft Windows Server 2008
10.1.100.100/24 Active Directory, CA, DHCP, DNS Cisco Unified
Communications Manager
10.1.100.40/24 Communications Manager for IP Phone Voice service
Target Servers 10.1.40.100, 10.1.40.200, 10.1.200.100,
10.1.200.200/24
Servers to be used for SGACL access
Table 4: User Accounts in Active Directory:
Username Group Membership Password
Enforcement Discussion
In the Cisco TrustSec 2.0 architecture, the system provides three major functions to allow more scalable network access control: authentication, classification, and authorization.
Authentication identifies endpoints by acquiring and validating the device credentials to ensure that only
appropriate endpoints (including users and devices) are connecting to the network. In the authentication process, the system matches several endpoint attributes to specific policies in order to classify those endpoints into a certain category or group. After classifying endpoints, we can finally match the final policy to authorize endpoints in the network.
The Cisco TrustSec system provides three methods of authentication:
• 802.1X-based endpoint authentication. This process includes 802.1X-based user authentication as well as device authentication.
• MAC Authentication Bypass. This method is used to authenticate a device using its MAC Address as credential.
• Web Authentication using Captive Portal. This method is used when the endpoint is attended with a user but there is no 802.1X supplicant installed or enabled on the machine.
Table 5: Authentication Methods Summary
Methods Description Pros Cons
802.1X Uses IEEE 802.1X technology to authenticate endpoint in Layer 2 mode using Extended Authentication Protocol (EAP)
Standard-based authentication provides the most secure authentication methods.
Supplicant (agent) needs to be installed and running on the endpoint. Supplicant behavior can be different based on OS type and supplicant vendor type. MAC
Authentication Bypass (MAB)
When an endpoint is not equipped with an 802.1X supplicant (authenticating software) and no user is attended to this device (such as with network printers), the switch can be configured to send the endpoint MAC Address on behalf of the endpoint, to be used as its credential.
Easy way to provide an authentication method for non-802.1X devices. Useful when device such as Network Printers or IP Phone does not support 802.1X supplicant.
Least secure method; MAC Address is used for its credential, and this address can be easily spoofed. MAC Address needs to be stored in the database to be authenticated. Web Authentication User is prompted to provide credential
on web browser. Method does not require any 802.1X supplicant; therefore it is used frequently for Guest Access Management.
Browser is needed to provide user credential. Since supplicant is not required, there is no OS dependency for this authentication method.
There are some variations in methods (Local Web Auth and Centralized Web Auth). VLAN assignment is not currently supported with wireless WebAuth.
Table 6: Summary of Authorization Methods
Methods Description Pros Cons
Dynamic VLAN Assignment (dVLAN)
As an authorization, the VLAN attribute is returned by Cisco ISE to the switch or WLC.
Result:
Wired: The switchport that the endpoint is connected to is assigned to a specific VLAN and segmented.
Wireless: The wireless clients traffic will be tagged out of the WLC into the wired network in the appropriate VLAN. Cisco WLCs will do this through a “dynamic interface” on the WLC.
This authorization is based on RFC 3580 and utilizes RADIUS Attributes 64, 65, and 81.
Easiest way to enforce and segment endpoints because this method is supported by standards: other vendor switches and AAA servers also support this method.
VLAN assignment can result in subnet change, and usually this change is not communicated to the endpoint. Detection of subnet change is completely based on OS/supplicant implementation. VLAN-to-VLAN policy control needs to be implemented to control traffic from one segment to others. Adding VLANs in the large corporate network can be costly.
Downloadable ACL (DACL) / Wireless ACL (wACL)
Wired (DACL): Cisco ISE sends specific attributes that contain a set of Access Control Entries (ACEs) to the switch. Switch then apply this ACL to a session based on IP address of the endpoint. Wireless ACL (wACL): Cisco ISE sends the name of the ACL that is configured on the WLC. The WLC will apply that preconfigured ACL to the endpoints session.
More flexible way to block traffic from source to certain destination. Since all ACLs are configured on Cisco ISE centrally, there is no need to change ACL on local switch. With Wireless all wACLs may be configured on the WLC or through WCS.
Since ACL consumes TCAM space on the switch, the amount of ACLs that the switch downloads per user needs to be well examined and limited.
wACLs may not be configured or managed via Cisco ISE today. They must be created on the WLC or through WCS.
Security Group Tag / Security Group ACL
In an authorization process, authorized endpoint IP address is tagged with special Tag called Security Group Tag (SGT). This tag can be used in the network to be filtered when tagged traffic reaches an egress switch at the packet destination. Using SGACL, packet can be permitted / dropped based on the TAG value and policy.
Since SGT is used to classify user and filter traffic, the management of the access control becomes easier and more efficient than the other two methods. Also SGACL is a method to filter traffic right before the packet reaches out to destination resource. Therefore there is no effect on access switch TCAM space.
Predeployment Check List
Table 7 shows a simple Pre-deployment Check List. Filling this out will help ensure you have some of the required basic information before beginning the Cisco TrustSec deployment. For a more complete High-Level Design, contact a certified Cisco Advanced Technology Partner for Cisco ISE / Cisco TrustSec deployments.
Table 7 Pre-‐Deployment Check List
Are the Switches and Wireless LAN Controllers running a supported Version?
þ Model Cisco IOS Software Release
☐ Cisco Catalyst 3750 Switch Cisco Catalyst 3560 Switch Cisco Catalyst 2960 Switch
12.2(55)SE3
☐ Cisco Catalyst 6500 Switch 12.2(33)SXJ1 ☐ Cisco Wireless LAN Controller 7.0.116 ☐ Cisco Nexus 7000 Switch 5.2.1
Are the corporate endpoints running recommended versions (or newer)? þ Operating System Minimum Version Supplicant ☐ Microsoft Windows 7 - Dot3 Service
Cisco SSC 5.1 SSC AnyConnect 3.0 ☐ Microsoft Windows Vista Service Pack 2 Dot3 Service
Cisco SSC 5.1 SSC AnyConnect 3.0 ☐ Microsoft Windows XP Service Pack 3 Dot3 Service
Cisco SSC 5.1 SSC AnyConnect 3.0 ☐ Apple Mac OS X 10.6.5 10.6.6 10.7.1 Native
Cisco Identity Services Engine
þ Minimum Version Personas Installed Notes: ☐ Cisco ISE
1.0.3.377
It is recommended to install Cisco ISE MR2 (1.0.4.573) because of bug fixes; however, that is not the version that was used in this system test.
Best Practice: Use lowercase letters in hostnames Best Practice: Use UTC time zone
☐ Administration Node All Personas may be installed on a single Cisco ISE node or distributed across multiple Cisco ISE nodes. For more on Cisco ISE Deployment Design, see Appendix A: Cisco ISE Design
☐ Monitoring Node
☐ Policy Services Node
Active Directory
þ Service Information
☐ AD Domain Domain Name:
☐ AD Sites and Services Will the Domain Controller Selection be predictable, based on the source subnet of the client?
☐ Multiple Domains? Will there be Multiple Domains? If so, Trust-Relationships will be required.
Make note of other Network and Endpoint Services:
þ Service Information
☐ NTP Servers ☐ DNS Servers ☐ DHCP Servers
☐ LDAP (non-AD) Servers ☐ Certificate Services (PKI)
Common Configuration: All Use Cases
Introduction
Within this document, we describe the recommended path for deployment and a few different options depending on the level of security needed in your environment. This section provides a “universal configuration” that applies to all deployment models and stages while following deployment best practices.
Universal Cisco ISE Configuration
Note: This stage of the document assumes you have already successfully installed Cisco ISE.
See http://www.cisco.com/en/US/docs/security/ise/1.0.4/user_guide/ise104_user_guide.html for the Cisco ISE user guide. We will follow Cisco ISE as a single node installation. For information on Cisco ISE design and scale, see Appendix A: Cisco ISE Design.
General Settings – Certificates and Certificate Authorities
When installing Cisco ISE, it generates a default, self-signed certificate. While this is usually good enough for labs and demonstrations, it is not good practice to put Cisco ISE into production with a self-signed certificate.
Note: Time synchronization is extremely important to certificate operations. Ensure that you have configured NTP and have the correct time.
Cisco ISE Configuration – Certificates and Trusting the CA
Note: For Certificate Chains: The entire chain should be imported successfully before the Certificate Request is created.
Procedure 1 Request a Certificate from the Certificate Authority.
Step 1 Go to Administration à System à Certificates à Local Certificates Step 2 Click Add à Generate Certificate Signing Request
Step 3 Enter the fully qualified domain name (FQDN) for the Cisco ISE node into the Certificate Subject field, and click Submit.
Step 4 Click Certificate Signing Requests and select your new request. Click Export.
Step 5 Save the .pem file to an easily accessible location.
Procedure 2 Download the Certificate Authority root certificate, and issue a certificate for Cisco ISE.
Step 1 Browse to your CA. Click “Download a CA certificate, certificate chain, or CRL”.
Note: We are using a Microsoft Certificate Authority; therefore we are browsing to http://ad.cts.local/crtsrv/. Depending on the Certificate Authority in your organization, the certificate request will follow a different procedure. When using the Microsoft CA, it has been noted that using Internet Explorer will provide a better experience.
Step 3 Save the resulting .cer file in a location that can be easily accessed later. Name the file something unique, such as “RootCert.cer”.
Step 4 Click Home, in the upper right corner. Step 5 Click “Request a Certificate”.
Step 6 Click “advanced certificate request”.
Step 7 Select the option of using a base-64-encoded CiscoWorks 2000 Management Connection (CMC).
Step 9 Paste the contents from the certificate request .pem file into the text box in the Certificate Authority Window. Certificate Template should be set to “Web Server”.
Step 10 Click Submit.
Step 11 Click “Download certificate”.
Procedure 3 Install the Root Certificate in Cisco ISE to be trusted for 802.1X.
Step 1 In the Cisco ISE administrative interface, navigate to Administration à System à Certificates à Certificate Authority Certificates. Click “Add”.
Step 2 Browse for the Root CA Certificate saved in Step 3. Select the Check Box for “Trust for client with EAP-TLS”. Click Submit.
Procedure 4 Install the new local Certificate.
Now that the Root CA is trusted, it is time to replace the self-signed certificate with the CA-issued certificate, and delete the completed Certificate Signing Request.
Step 1 From Administration à System à Certificates à Local Certificates, Click Add à Bind CA Certificate.
Note: If you did not create the certificate request with the same full name as the Cisco ISE server, you will receive an error message. Delete the old Certificate Signing Request, and start again.
Procedure 5 Clean Up Old Certificates and CSRs
Step 1 Delete the Old Certificate. Select the Self-Signed Certificate and Click Delete.
Step 2 Click “Certificate Signing Requests”. Select the Certificate Signing Request (CSR), and delete.
Active Directory Integration
The single most common Policy Information Point (PiP) used with Cisco TrustSec deployments is Active Directory. Cisco ISE uses an Active Directory connector where each Cisco ISE node in a Cisco TrustSec deployment will join the AD Domain, and access AD resources just like any other Windows domain member. This scenario allows for tremendous increase in speed, ease of use, and flexibility when using Active Directory with Cisco TrustSec security.
Cisco ISE Configuration – Active Directory Integration
Procedure 1 Join the Domain.
Note: Each Cisco ISE node joins the domain separately. The following is a list of ports that must be open between all Cisco ISE Nodes and Active Directory: SMB(TCP/445); KDC(TCP/88); Global Catalog(TCP/3268 & 3289); KPASS(TCP/464), NTP(UDP/123); LDAP(TCP & UDP/389), and LDAPS(TCP/636).
Step 1 Administration à Identity Management à External Identity Sources à Active Directory Step 2 Enter the AD Domain Name and click Save Configuration.
Step 3 Click Join.
A “Join Domain” pop-up window will appear. Enter a username and password for an AD account with rights to join a workstation to the domain, such as “administrator”.
Note: Time synchronization is extremely important to successfully join the domain. Ensure you have the correct Time and have configured NTP.
Step 4 Click Groups à Add à Select Groups From Directory.
Cisco ISE allows a network administrator to select specific groups and attributes from Active Directory. This scenario enables faster lookup times when authenticating a user against AD. It also ensures that when building policy related to AD groups, the administrator needs to look through only a small list instead of every group in AD.
Step 5 Select groups that you will want to use in policy decisions.
Cisco ISE Configuration – Base Authentication Policy
Identity sequences are used in only ISE to provide a single “object” that is actually a sequence of Identity Stores that only ISE will query when validating credentials. In our configuration example, we will create an identity sequence that queries the following identity stores in order:
Active Directory à Internal Hosts à Internal Users
Procedure 1 Create an Identity Sequence.
Step 1 Navigate to Administration à Identity Management à Identity Source Sequences. Step 2 There are two Identity Source Sequences by default.
Step 3 Click Add.
Step 4 Name the Identity Sequence “All_ID_Stores”. Add the identity stores in the order shown in the following screenshot:
Cisco ISE Configuration – Add Network Devices
Any switch or Wireless LAN Controller that may be sending RADIUS requests to Cisco ISE to authenticate and authorize network clients should be added to Cisco ISE. While Cisco ISE does provide a “Default Device” that may be configured to allow any network device to send RADIUS Requests, it is not a good security practice to use this feature.
In order to provide a thorough level of Policy creation, as well as detailed levels of reporting, it is recommended to add all devices individually to Cisco ISE, and to use Network Device Groups (NDGs) to organize those network devices appropriately.
Note: For Bulk import of Network Devices and assignment of those devices to their respective NDGs, Cisco ISE provides an Import / Export mechanism. See the Cisco ISE User Guide (http://www.cisco.com/en/US/docs/security/ise/1.0.4/user_guide/ise104_user_guide.html) for more detailed instructions.
Procedure 1 Configure Network Device Groups.
Network Device Groups (NDGs) are a very powerful tool, when used appropriately. Cisco ISE has the power to use any number of attributes when it makes policy decisions. Network Device Group (NDG) membership is one such attribute that can be used as a policy condition.
Best practice: Always use NDGs for Device Types and Location at a minimum.
An example could be the creation of an NDG for switches, another for VPN devices, and a third group for Wireless LAN Controllers (WLCs).
Step 1 Go to Administration à Network Resources à Network Device Groups.
By default there are two top-level NDG types: All Device Types and All Locations. These types are a good start for most deployments. Your deployment may need to create multiple location sub-groups. The possibilities are virtually limitless (see the sample hierarchy that follows).
The group structure is hierarchical. So with an example group structure of: All Locations à North America à US à SJC à Building 18 à 3rd Floor, you can use any level of the group hierarchy in your policy. In other
words, you can select “US” in your policy and get every device in every group underneath “US”. Step 2 Expand Group Types.
Note:
To create a Root NDG, click Group Types and click Add.
To create a child NDG, choose the root NDG add a child NDG, and click Add.
Step 3 Select All Device Types. Click Add
Step 4 Enter the name “Switch” in the Name Field.
Step 5 Click Submit.
Repeat the process to build out your desired NDG hierarchy. Here is an example hierarchy:
Procedure 2 Add Network Device.
Step 1 Go to Administration à Network Resources à Network Devices.
Step 2 Click Add.
Step 3 Fill out the Name, IP Address, Network Device Group, Authentication Settings, and SNMP Settings sections.
Section Purpose
General Settings
Name Use a name that is easy to distinguish later. The name will display in all the monitoring / dashboards / reporting later.
Description Optional
IP Address Must match the source interface chosen for RADIUS communication in the switch configuration section. Best practice is to use Loopback interfaces for management.
Section Purpose Network Device Group
Location Be as specific as possible. Device Type Be as specific as possible. Authentication Settings
Protocol Will be prepopulated as RADIUS.
Shared Secret Must match the RADIUS key configured on the switch. SNMP Settings (used for device profiling)
SNMP Version Select the version in use in your organization. SNMP RO
Community
SNMP is used only for device profiling purposes. Cisco ISE will probe the switch for contents of Cisco Discovery Protocol tables, LLDP tables, and more.
SNMP Username Used with SNMPv3 – must match the configuration on the switch. Security Level Used with SNMPv3 – must match the configuration on the switch. Auth Protocol Used with SNMPv3 – must match the configuration on the switch. Privacy Protocol Used with SNMPv3 – must match the configuration on the switch. Polling Interval It is not recommended to change the default polling interval: 3,600 sec Link Trap Query Configures Cisco ISE to accept linkup / linkdown SNMP traps from the
switch. Leave this check box selected.
MAC Trap Query Configures Cisco ISE to accept mac-address-table type traps from the switch. Leave this check box selected.
Security Group Access (SGA) – Not used at this stage of our deployment guide. This section will be revisited later, in the SGA section.
Step 4 Click Submit. Repeat for all network devices (aka: Policy Enforcement Points).
Note: For bulk administration, network devices may be imported via CSV file. See the Cisco ISE user guide for more information.
Universal Cisco ISE Configuration – Device Profiling
Profiling design requires a lot of thought and planning.
The Cisco ISE Profiler is the component of the ISE platform that is responsible for endpoint detection and classification. It does so by using an array of probes (Sensors) that collect attributes about an endpoint and a policy-based mechanism that evaluates the attributes to match the endpoint with a predefined profile.
The result of the collection and classification from the profiler are then used as conditions in the authentication and authorization policies. The classification result of profiling can be used to invoke a different authorization result.
The figure below is an example of a differentiated device policy based on profiling:
• Users, using the same SSID, can be associated to different wired VLAN interfaces after EAP authentication.
• Employees using corporate laptop with their AD user id assigned to VLAN 30 = Full network access
• Employees using personal iPads/iPhones with their AD user id assigned to VLAN 40 = Internet only
Figure 4: Example of Differentiated Device Policy
Cisco ISE Configuration – Enable Device Profiling Probes
At this stage we will enable Profiling Probes on the Cisco ISE device. In a distributed deployment, profiling probes would generally be enabled on all the Policy Service Nodes (sometimes referred to as Policy Decision Points or PDPs). The specific details of which probes to enable and where to enable them can be complex and should be addressed in the high-level design process.
Procedure 1 Enable the Profiling Probes.
Step 1 Navigate to Administration à System à Deployment. Step 2 Select the Policy Service Node.
This node may be a single Cisco ISE node as depicted here. Or, if your Cisco TrustSec deployment is distributed, then you should select one of the nodes configured for Policy Service. You will repeat these steps for each Policy Service node in the deployment.
CAPWAP CAPWAP Same-SSID 802.1Q Trunk VLAN 30 VLAN 40 EAP Authentication 1
Accept with VLAN 30
2
EAP Authentication 3
Step 3 Ensure that “Enable Profiling Service” is checked. Step 4 Click the Profiling Configuration Tab.
NetFlow: The NetFlow probe will not be enabled in this guide.
NetFlow is a very powerful tool, but its implementation must be thought out and implemented carefully. There are certain Cisco TrustSec implementations where NetFlow will be crucial. However, one of the important aspects of NetFlow is understanding what data to send from the infrastructure. This configuration is
considered out of the scope of this guide, but will be in either a specific follow-on guide or in a future version of a Cisco TrustSec implementation guide.
Step 5 Enable the check box for DHCP.
This is the DHCP IP Helper probe. It will listen to packets forwarded to it from the DHCP IP helper
configured on the switch or other Layer 3 device. The IP Helper probe will listen to traffic from the DHCP client to server only (DHCPDISCOVER and DHCPREQUEST).
Enable this probe on a particular interface, or on all interfaces.
Step 6 Enable the check box for DHCPSPAN.
The DHCP Span probe will listen to packets forwarded to it from the SPAN session configured on the switch. This probe will listen to all of the DHCP traffic.
When a switchport is configured to be a SPAN (switchport analyzer) destination, the port no longer functions in normal ways. The interface connected to the SPAN destination port is expected to be in “promiscuous mode”, meaning the interface is expected to be capturing all traffic that enters the port, and will not respond to directed communications.
With that understanding, it is recommended to dedicate one or more interfaces of the Cisco ISE server to be put into promiscuous mode for the DHCPSPAN and HTTP probes. For the purposes of this guide, we will dedicate the GigabitEthernet 1 interface to be a SPAN destination.
Note: When using an interface on the Cisco ISE other than GigabitEthernet 0, enter the CLI and type no shutdown at interface configuration mode to enable the interface.
Please see the “Add Network Device” procedure for the switch configuration.
To configure the SPAN (monitor session) on the switchport, please see the “Configure the SPAN session on the Switch” procedure.
Step 7 Enable the check box for HTTP.
Step 8 Enable the check box for RADIUS.
The RADIUS probe will help detect endpoints based on RADIUS information. Table 8 lists known attributes collected by the RADIUS probe.
Table 8 Attributes Collected by RADIUS Probe
User-Name Framed-IP-Address Acct-Session-Time NAS-IP Address Calling-Station-ID Acct-Terminate-Cause NAS-Port Acct-Session-ID
The RADIUS Probe may also trigger DNS and SNMP Query collection events (if enabled). Step 9 Enable the check box for DNS.
The DNS probe in your Cisco ISE deployment allows the profiler to look up an endpoint and gets the fully qualified domain name (FQDN) of that endpoint.
A reverse DNS lookup will be completed only when an endpoint detected by the DHCP, RADIUS, HTTP, and SNMP probes contains the following attributes, meaning that, for DNS lookup, at least one of the following probes needs to be enabled along with the DNS probe:
• DHCP IP Helper, DHCP Span – “dhcp-requested-address” • RADIUS Probe – “Framed-IP-Address”
• SNMP Probe – “cdpCacheAddress” • HTTP Probe – “Source IP”
Step 10 Enable the check box for SNMPQUERY.
The SNMPQuery probe queries the following MIBS: • system
• cdpCacheEntry
• cLApEntry (If device is WLC) • cldcClientEntry (If device is WLC)
LinkUp/MAC Notification/RADIUS Acct Start event queries: • interface data (ifIndex, ifDesc, etc.)
• Port and VLAN data
• Session Data (if interface type is Ethernet) • Cisco Discovery Protocol data (if device is Cisco)
For distributed deployments, NAD polling is distributed among enabled SNMP query probes.
Note: SNMP Trap-triggered queries are queued to same node for SNMP Query probe. If local SNMP Query probe is not enabled, then those queries are dropped.
Step 11 Enable the check box for SNMPTRAP.
Step 12 Ensure the Link Trap Query and MAC Trap Query options are enabled.
The SNMP Trap receives information from the configured NADs that support MAC notification, linkup,
linkdown, and informs. For SNMPTrap to be fully functional, you must also enable the SNMPQuery probe. The SNMPTrap probe receives information from the specific NADs when ports come up or go down and
endpoints disconnect or connect to your network. The In order to make this feature functional, you must configure the NAD to send SNMP traps. Information received from the SNMP traps will not create a new endpoint in Cisco ISE but it will potentially be used for profiling.
Note: SNMP informs are supported.
Step 13 Click Save.
Procedure 2 (Optional) Configure a Promiscuous VMware Network.
If Cisco ISE is deployed in a Virtual Environment, it is important to configure the VMware networking appropriately to allow a promiscuous interface to work properly. If Cisco ISE is deployed in a physical appliance form factor, then move ahead to the “Configure the SPAN session on the Switch” section.
This Procedure will configure and dedicate an interface on the VMware ESX Server as a promiscuous interface. If the physical interface on the ESX server cannot be dedicated for SPAN, follow Procedure 3 later in this document.
Step 1 Select the physical ESX server in VMware VSphere client. Select Configuration à Networking, and then choose “Add Networking”.
Step 2 The Add Network Wizard is launched. Choose a “Virtual Machine” connection Type, and click Next.
Step 3 Select the Physical Interface that will be connected to the SPAN port on the switch. Click Next.
Step 5 Select Finish.
Step 6 Enable Promiscuous traffic into the newly created vSwitch. Select properties on the new vSwitch. By default, any VMware network will reject Promiscuous traffic.
Step 7 Highlight the new vSwitch. Choose Edit. Step 8 Select the Security tab.
Step 9 Select “Accept” from the Promiscuous Mode drop-down menu. Click OK.
Step 12 Select the appropriate Network Adaptor for Cisco ISE (usually Network Adaptor 2, for GigabitEthernet1 in Cisco ISE).
Step 13 Ensure that it is Connected, and will Connect at power on.
Step 14 From the Network Connection drop-down menu, select the newly created “SPAN_Session” network.
Step 15 Click OK.
Step 16 Make note of the switch port that the promiscuous interface is connected to, for use in the next section.
Note: ESX has a user-friendly feature of displaying Cisco Discovery Protocol information for its connected interfaces. See the following screen shot to see this display.
Procedure 3 (Optional) Configure a Promiscuous VMware Port Group.
Step 1 Select the physical ESX server in VMware VSphere client.
Step 2 Select Configuration à Networking, and then choose your vSwitch and click “Properties”.
Step 3 In the vSwitch Properties window under the Ports Tab, click Add at the bottom left.
Step 4 The Add Network Wizard is launched. Choose a “Virtual Machine” connection Type, and click Next.
Step 5 Name the port group “SPAN_Session”, or any other logical name. Step 6 Set the VLAN to 4095 and click Next.
Step 7 Select Finish.
Step 8 Highlight the new port group. Step 9 Choose Edit.
Step 11 Select “Accept” from the Promiscuous Mode drop-down menu. Click OK.
Step 12 Close the vSwitch Properties window. Step 13 Edit the Cisco ISE Virtual Machine Settings.
Step 14 Select the appropriate Network Adaptor for Cisco ISE (usually Network Adaptor 2 for GigabitEthernet1 in Cisco ISE).
Step 15 Ensure that it is Connected and will Connect at power on.
Step 16 From the Network Connection drop-down menu, select the newly created “SPAN_Session” network.
Step 17 Click OK.
Procedure 4 Configure the SPAN session on the Switch.
Step 1 Enter Global Configuration.
Step 2 Configure the SPAN session source. An example follows: C4K-ToR(config)#monitor session 1 source vlan 100 both Step 3 Configure the SPAN session destination. An example follows:
C4K-ToR(config)#monitor session 1 destination interface g 1/47 Step 4 Verify the port is now in monitoring mode.
C4K-ToR(config)#do show int status | i 47
Procedure 5 Configure the ip-helper Statements.
To work along with the DHCP probe for Cisco ISE profiling, the Cisco ISE Policy Node(s) should be added to the ip helper-address statements on the Layer 3 interfaces in the network. This node addition will send a copy of all DHCP requests to Cisco ISE in addition to the production DHCP servers in the environment.
Step 1 Enter Global Configuration mode.
Step 2 Enter the Interface configuration mode for the Access VLAN Layer 3 interface and add Cisco ISE as another destination for ip helper-address. An example follows:
interface Vlan10
ip address 10.1.10.1 255.255.255.0
ip helper-address 10.1.100.100 ! – this is the DHCP Server
Universal Cisco ISE Configuration: Guest
Introduction
Cisco TrustSec security helps organizations secure guest access to corporate networks, helping ensure that guest and visitor traffic remains segregated from internal networks and assess incoming computers for threats that may affect network availability and security. Cisco ISE offers centralized guest access management and enforcement for wired and wireless users, and can integrate easily with wireless solutions, third-party guest access portals, and billing providers.
Cisco ISE Guest service allows guests, visitors, contractors, consultants, or customers to perform an HTTP or HTTPS login to access a network whether that network is a corporate intranet or the public Internet. The network is defined through a VLAN or a downloadable access control list (DACL) configuration in the network access device (NAD). Cisco ISE offers a simple, client-configurable Sponsor Portal for creating and managing Guest User accounts. Cisco ISE also supports default and customizable Guest Login Portals to handle Guest User login. Guest service provisions a guest account for the amount of time specified when the account is created. In this section we will review the overall workflow for configuring Cisco ISE Guest Services, including sponsor setup, guest setup, and configuration of authorization policies for guest access.
Guest Services exposes two web portals. The first is the Guest User portal for Guest User login, Acceptable Use Policy acknowledgment, changing of passwords, and self-registration. The second web portal is a Sponsor Portal for Sponsors to create, update, and manage Guest User accounts.
The main steps in configuring guest services are shown in Figure 5. Note that in some cases tasks may be applicable to both sponsor and guest configuration.
Universal Guest Configuration – Sponsor User Configuration
Procedure 1 Configure Sponsor System Settings.
Prior to configuration of sponsor or guest access policies, ensure that the guest service is enabled on Cisco ISE. Step 1 Navigate to Administration à Guest Management à Settings à General à Ports.
Step 2 Verify the HTTP and HTTPS ports used for portal access as required for the guest and sponsor portal. Step 3 The default ports are 8080 and 8443 for HTTP and HTTPS, respectively.
Procedure 2 Configure Sponsor Groups.
Guest sponsor groups contain the permissions and settings for the sponsor user. Step 1 Navigate to Administration à Guest Management à Sponsor Groups. Step 2 Click Add or Edit to create or edit a sponsor group.
Step 3 Under the General tab enter a name and description.
Step 4 Under the Authorization Levels tab set permissions as necessary.
Step 5 Choose appropriate choices for View/Edit Accounts, Suspend/Reinstate Accounts, Account Start Time, and Maximum Duration of Account settings.
Step 6 From the Guest Roles tab choose the guest roles that the sponsor group user would be allowed to assign to the guest user.
Note: These roles are used in the authorization policies to relate guest user accounts to identity groups.
Step 7 Under the Time Profiles tab choose time profiles that the sponsor group user would be able to assign to guest accounts.
Step 8 Click Submit to save the configuration.
Procedure 3 Configure Identity Source Sequences (optional).
Identity source sequences define the order in which Cisco ISE will look for user credentials in the different
Step 1 Navigate to Administration à Identity Management à Identity Source Sequences.
Step 2 Click Add to add an identity source sequence. You can check the check box or click Edit or Duplicate accordingly.
Step 3 In the Authentication Search List area, select the appropriate method if you want Cisco ISE to stop the search if the user is not found in the first identity store.
Note: Ensure that you have the identity sources in the Selected list in the order you want Cisco ISE to search the identity sources.
Procedure 4 Configure Authentication Sources.
To allow a sponsor to log into the sponsor portal, you have to choose an identity store sequence. This sequence is used with the login credentials of the sponsor to authenticate and authorize the sponsor for access to the sponsor portal.
Step 1 Navigate to Administration à Guest Management à Settings à Sponsor à Authentication Source. Step 2 From the Identity Store Sequence drop-down list, choose the sequence to be used for the sponsor authentication (ALL_ID_STORES).
Step 3 Click Save.
Note: When the primary node with Administration persona is down, Sponsor administrators cannot create new guest user accounts.
Procedure 5 Configure a New Sponsor User (optional).
For the majority of installs, Active Directory will be the identity source chosen to authenticate sponsors to.
Step 1 Navigate to Administration à Identity Management à Identities à Users.
Step 2 Click Add to create a new network access user. The Network access user page is displayed. Step 3 Enter values as appropriate to configure the sponsor user.
Step 4 Associate the sponsor of the appropriate sponsor user group.
Step 5 Click Submit to add the user to the Cisco ISE database.
Procedure 6 Configure Sponsor Group Policies.
Configure Sponsor Groups” procedure.
Step 1 Navigate to Administration à Guest Management à Sponsor Group Policy. Step 2 Click Actions to insert a new rule above the existing rules.
Step 3 Name the Rule ManagerSponsors.
Step 4 Leave the Identity Groups at the default of Any.
Step 5 Under conditions, choose Create a New Condition (Advanced Option). Step 6 Within expression, choose: AD1 à ExternalGroups à Sponsors_Full.
Note: Sponsors_Full is a group that we have preconfigured in Active Directory. Many organizations create a special group for Sponsors, and others will allow any member of “Domain Users” to create Guest Accounts.
Step 7 Under Other Conditions, you may configure any number of conditions and statements as per network requirements. These conditions will be used to match users as they authenticate to the Guest Service Sponsor portal.
Step 8 Configure Sponsor Groups” procedure.
Step 9 Click Save to save the configuration.
Procedure 7 Configure the Guest Details Policy.
The details policy determines the data that the sponsor needs to enter when creating a guest account. The Cisco ISE administrator must define the fields that should appear on the Sponsor Guest User create and edit pages and in the Guest User Self-Registration page.
Step 1 Navigate to Administration à Guest Management à Settings à Guest à Details Policy. Step 2 Enter fields such as First Name, Last Name, Company, Email, Phone, as required.
Step 3 Specify any of the three settings for each field: Mandatory, Optional, or Unused.
There are five additional fields that can be customized to require sponsors to fill out when creating guest accounts.
Step 4 Click Submit.
Procedure 8 Configure the Guest Username Policy.
The Guest Portal policy specifies how the usernames will be created for the guest accounts. It contains username requirements for guest services, such as allowed characters and the username format. Username policy
configuration can be done in two ways – General or Random.
Step 1 Navigate to Administration à Guest Management à Settings à Guest à Username Policy. Step 2 Choose one of the username policy options – from an email address or from first and last names.
Step 3 Enter minimum username length as required. Step 4 Click Submit .
Procedure 9 Configure the Password Policy.
The Guest Portal policy specifies the characters that may be used for password generation as well as the number of each type for all guest accounts.
Step 1 Navigate to Administration à Guest Management à Settings à Guest à Password Policy.
Step 2 Enter appropriate details according to your guest password policy requirements. Step 3 Click Submit.
Procedure 10 Configure the Guest Portal Policy.
The Guest Portal policy identifies functional items such as guest login attempts, password expiration, etc. Step 1 Navigate to Administration à Guest Management à Settings à Guest à Portal Policy.
• Device Registration Portal Limit • Guest Password Expiration
Step 3 Click Save to save configuration.
Universal Guest Configuration – Multi-Portal Guest User Configuration
A predefined DefaultGuestPortal is available under Multi-Portal Configurations. This portal has the default Cisco design and you cannot customize it. To create a customized portal, you must first begin by adding a new portal.
Procedure 1 Configure the Multi-Portal.
Note: This procedure is crucial to more than just Guest Access. It is critical that this portal be configured correctly for all Web Authentication needs.
Step 3 Make any changes to these settings as needed by your organization. Step 4 Click Authentication.
Step 5 Choose “Both” for the type of users who will be authenticated during the guest login. Step 6 Select the ALL_ID_STORES identity store.
Supplicant Configuration
Cisco AnyConnect Network Access Manager
Cisco AnyConnect Network Access Manager (NAM) is a module of the Cisco AnyConnect Client for Windows 3.0 and provides a fully configurable and very powerful supplicant option instead of the native supplicant of the Windows Operating System. NAM is licensed with no charge, and more information may be found here:
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps6120/data_sheet_c78-527494.html.
Cisco AnyConnect NAM Configuration Using the Standalone Profile Editor
Procedure 1 Configure NAM with the Standalone Profile Editor
Step 1 Select Networks, click Add, and enter “Wired-PEAP”.
Step 2 Follow the configuration settings in the screen shot that follows:
Step 3 Click Next.
Step 4 Select “Authenticating Network” and check “EAP fails” under the Port Authentication Exception Policy.
Step 5 Change the startperiod to 10 seconds.
Note: the startperiod is equivalent to tx-period on the switchport. Because it is best practice to set the tx-period to 10 seconds, the NAM startperiod value must also reflect the same value (refer to the section “Authentication Settings – Timers”).
Step 7 Select “Machine and User Connection”.
Step 9 On the upper right, select the “User Auth” tab. Set the EAP Methods to “PEAP”.
Step 10 On the upper right, select the “Credentials” tab. Note that Single Sign On is checked.
Step 12 Select Network Groups. Move the wired-peap connection to the top of the Network Order.
Note: By moving the “wired-peap” connection to the top, NAM will attempt this connection first.
Step 13 From the menu, click File and then Save As to save the configuration with the filename
configuration.xml (Note: This file name is required) in the “\ProgramData\Application Data\Cisco\Cisco AnyConnect Secure Mobility Client\Network Access Manager\newConfigFiles” directory.
Step 14 To apply this new configuration, go to the AnyConnect icon in the system tray. Step 15 Right click to view the options
Step 16 Select “Network Repair”. This step forces the Cisco AnyConnect NAM to restart its services. A service restart causes NAM to search the newConfigFiles directory for a “configuration.xml” file.
Configuration Apple Mac OS X 10.6
Note: For Apple Mac OS X 10.7, please follow this link. http://support.apple.com/kb/HT4772.
Step 1 Click "System Preferences” and select "Network" under “Internet and Network”.
Step 3 In the resulting window, select the “802.1X” tab.
Step 5 Select the appropriate profile.
“Login Window Profile”- Use this profile if multiple users use the machine. or
“System Profile” – Use this profile to authenticate to the network automatically. The computer will authenticate to the network even when no one is logged in, regardless of which user account logs in afterward.
Note: There can be only one system profile.
Step 6 In the resulting profile window, enter your credentials, uncheck TTLS, and click “OK”.
Notes:
Cisco ISE does not support TTLS.
When system profile is used, the user is not prompted for authentication. Instead the account that was saved (in step 7) is used. If the account entered is used to authenticate the system (not an actual user), then the account must be maintained as user in Active Directory or use a different database.
When you use Login Window Profile, you will not get prompted as long as you are logged into the system with account user credential.
To connect to a non-802.1X-enabled wired port, uncheck “System Profile” prior to plugging in.
Step 7 Click “OK” and then Apply. You will need to reboot the computer to have the settings take effect.
Note: For additional supplicant-specific information, please refer to:
Apple iOS 4.0 (iPad, iPhone, iPod) Configuration
Procedure 1 Configure the iOS supplicant.
Step 1 From the home screen, tap the “Settings” icon.
Step 2 Enable Wi-Fi. Use the slider to turn Wi-Fi on. Wait for the available networks to appear.
Step 3 Choose the network with which to connect. (cts-guest or cts-corp). Step 4 Enter your credentials when prompted
Step 6 You are now connected.
Android Honeycomb 3.1 Configuration
Step 1 From the Settings screen, select “Wireless and networks->Wi-Fi Settings”.
Step 3 A pop-up window should appear that requests credential and connection information. Scroll to the bottom of this window to enter credentials into the Identity and Password fields. (These are the only fields in which you need to enter information.)
Step 4 Click OK.
Step 5 You are now connected.
Step 6 To determine what the assigned IP address is, tap the “cts-guest” connection entry.
IP Phones
Within this deployment Guide, we will initially rely on endpoint profiling and MAB for Cisco IP Phones, and configure the phone supplicants in a later section. Endpoint profiling allows an organization to become more familiar with the operations of a network enabled with Cisco TrustSec security before having to fully understand the Certificate Authority Proxy Functions of an IP Phone.
Switches – Universal Global Configuration Commands
The following section describes the universal switch configuration. These recommended configurations are compiled as a best practice to be used for all deployments, and remain consistent through the different stages of deployment as well as the different deployment types chosen.
Best Practice: It is recommended to use Network Configuration Management solutions, such as CiscoWorks LAN Management Solution (LMS) to manage the configurations enterprisewide. However, it was not part of the Cisco TrustSec 2.0 test lab, and therefore cannot be part of this document. It will be part of a future version.
Switch Configuration – Global Settings
Within the Cisco TrustSec 2.0 system, the switch performs the URL redirection for web authentication as well as redirecting the discovery traffic from the posture agent (Cisco NAC Agent) to the Cisco ISE Server.
Performing URL redirection at the Layer 2 access (edge) device is a vast improvement over previous NAC solutions that require an appliance to capture web traffic and perform redirection to a web authentication page, simplifying the deployment for both web authentication and the posture agent discovery process.
Note: Prerequisite configuration: This guide assumes that the switches have the fundamental basics preconfigured on them. For example, correct date and time settings by using Network Time Protocol (NTP) are considered best practice, but will not be covered in any section. Best Practice: Always ensure that the Switch can communicate with the client subnets, to ensure that HTTP Redirection works properly. For
Security Best Practices, use an Access Class to limit what addresses may manage the switch. This topic is beyond the scope of this document.
Procedure 1 Configure the HTTP Server on the Switch.
Step 1 Set the DNS Domain Name on the switch.
Cisco IOS Software does not allow for certificates, or even self-generated keys to be created and installed without first defining a DNS domain name on the device.
C3750X(config)#ip domain-name domain_name Step 2 Generate Keys to be used for HTTPS.
C3750X(config)#crypto key generate rsa general-keys mod 2048
Note: It is recommended to use a certificate that is issued by your trusted Certificate Authority instead of a local certificate to avoid possible certificate mismatch errors during web redirection. An enterprise CA was not part of the test bed in Cisco TrustSec 2.0, and therefore is not part of this document.
Step 3 Enable the HTTP Servers on the switch.
The HTTP Server must be enabled on the switch to perform the HTTP / HTTPS capture and redirection. C3750X(config)#ip http server
C3750X(config)#ip http secure-server
Procedure 2 Configure the Global AAA Commands.
Step 1 Enable Authentication, Authorization and Accounting on the access switch(es).
By default, the AAA “subsystem” of the Cisco switch is disabled. Prior to enabling the AAA subsystem, none of the required commands will be available in the configuration.
C3750X(config)#aaa new-model
Step 2 Create an authentication method for 802.1X.
An authentication method is required to instruct the switch on which group of RADIUS servers to use for 802.1X authentication requests.
C3750X(config)#aaa authentication dot1x default group radius Step 3 Create an authorization method for 802.1X.
The method created in step 2 will enable the user/device Identity (username/password or certificate) to be validated by the RADIUS Server. However, simply having valid credentials is not enough. There must be an authorization as well. The authorization is what defines that the user or device is actually allowed to access the network, and what level of access is actually permitted.
C3750X(config)#aaa authorization network default group radius Step 4 Create an Accounting method for 802.1X.
RADIUS accounting packets are extremely useful, and in many cases are required. These types of packets will help ensure that the RADIUS server (Cisco ISE) knows the exact state of the switchport and endpoint. Without the accounting packets, Cisco ISE would have knowledge only of the authentication and
authorization communication. Accounting packets provide information on length of the authorized session, as well as local decisions made by the switch (such as AuthFail VLAN assignment, etc.)
C3750X(config)#aaa accounting dot1x default start-stop group radius
Procedure 3 Configure the Global RADIUS Commands.
We configure a proactive method to check the availability of the RADIUS server. With this practice, the switch will send periodic test authentication messages to the RADIUS server (Cisco ISE). It is looking for a RADIUS response from the server. A success message is not necessary – a failed authentication will suffice, because it shows that the server is alive.
Best Practice Tip: It is not possible to filter these authentications from the logging server in Cisco ISE 1.0(377). Filtering will skew the authentication success versus failures that display on the Cisco ISE dashboard, so it is recommended to use an account where authentication will succeed but authorization will deny access.
Step 1 Within global configuration mode, add a username and password for the RADIUS keepalive.
The username we are creating here will be added to the local user database in Cisco ISE at a later step. This account will be used in a later step where we define the RADIUS server.
C3750X(config)#username radius-test password password
Step 2 Add the Cisco ISE servers to the RADIUS group.
In this step we will add each Cisco ISE Policy Decision Point (PDP) to the switch configuration, using the test account we created previously. Repeat for each PDP.
C3750X(config)#radius-server host ise_ip_address auth-port 1812 acct-port 1813 test
username radius-test key shared_secret
Note: The server will proactively be checked for responses 1 time per hour, in addition to any authentications or authorizations occurring through normal processes.
Step 3 Set the dead criteria.
