on
01-21-2021
12:41 PM
- edited on
11-03-2023
08:20 PM
by
hslai
Authors: Hariprasad Holla (until June 2018), Mahesh Nagireddy (until Dec 2018)
For an offline or printed copy of this document, simply choose ⋮ Options > Printer Friendly Page. You may then Print, Print to PDF or copy and paste to any other document format you like. |
Figure1: Cisco Identity Services Engine
Cisco ISE is a leading, identity-based network access control and policy enforcement system. It is a common policy engine for controlling end-point access and network device administration for enterprises. ISE allows an administrator to centrally control access policies for wired, wireless, and VPN end points in a network.
ISE builds contexts about endpoints, including users and groups (Who), device type (What), access time (When), access location (Where), access type (Wired/Wireless/VPN) (How), threats, and vulnerabilities. By sharing vital contextual data with technology partner integrations and the implementation of the Cisco TrustSec® policy for software-defined segmentation, ISE transforms a network from a conduit for data into a security enforcer that accelerates the time-to-detection and time-to-resolution of network threats.
This document aims to provide guidance to Cisco ISE customers who want to protect their wired network access, which is being designed with the Cisco Catalyst switch platforms. For implementation with Cisco Meraki network devices, see How To: Integrate Meraki Networks with ISE.
The configuration examples listed in this document are working configurations that have been validated on a Cisco Catalyst 9300 Series switch running Cisco IOS XE Version 16.9.1 with Network Essential License and Cisco ISE Version 2.4.
Figure2: Endpoint onboarding Physical network topology
The following are the IOS XE features and deployment variations described in this document:
Although this deployment guide is about securing wired network access, Cisco Meraki access switches or third-party access switches are not covered in this document. For more information about these, see the ISE Design and Integration Guides page.This guide does not cover other wired access features, such as Wired Guest Access, Network Edge Authentication Topology (NEAT) and EasyConnect.
This guide is intended to provide technical guidance to design, deploy, and operate Cisco ISE for wired network access control. It focuses on the Cisco Catalyst access switch configurations to handle various endpoint onboarding scenarios. The document also provides best-practice configurations for a typical enterprise environment.
Figure3: ISE for Wired Implementation Flow
This document contains four major sections:
This section provides an high level overview of Wired access control solution, different authentication methods available during the endpoint onboarding process, problem areas to focus on and various authorization options.
A typical ISE-based network access control solution comprises four components, endpoints, network devices, Cisco ISE, and external services.
Figure4: ISE solution components
Endpoints need network access and the network devices provide network access to endpoints, based on instructions from ISE. ISE can optionally leverage external services to understand more about the corresponding endpoints for policy decisions. When it comes to rolling out an identity-based network, because these four parts of the network are involved, various teams and individuals need to be engaged. Various ISE use cases, such as Guest access, BYOD, Posture, and so on require endpoints communicating to ISE via network devices.
The core of IBNS is the idea of users and devices authenticating to ISE, and ISE applying the appropriate network access authorization, using protocols such as EAP and RADIUS. Network devices covey an endpoint’s session status to ISE via RADIUS accounting messages. ISE gains visibility into the details of all the assets connecting to the network and their location. An ISE administrator can permit or deny access to a specific user or device or a specific group of assets either on the fly or based on ISE policy configurations.
The 802.1x standard defines a client/server-based access control and authentication protocol that prevents unauthorized clients from connecting to a LAN through publicly accessible ports unless they are properly authenticated. The authentication server authenticates each client connected to a switch port before making available the services offered by the switch or the LAN. The supplicants on the endpoints use Extensible Authentication Protocol (EAP) to pass credentials, such as passwords or certificates, to ISE. EAP payloads are typically transported over 802.1X in Ethernet networks (EAP over LAN or simply EAPoL) and over RADIUS in IP networks. ISE evaluates an endpoint’s identity and instructs the corresponding network device about whether to open the port or not, the VLAN or ACL or both VLAN and ACL that are to be applied for that endpoint’s access session.
Figure6: MAB Authentication Workflow
MAB enables port-based access control using the MAC address of an endpoint. A MAB-enabled port on the switch can be dynamically enabled or disabled based on the MAC address of the device that connects to it. The MAC addresses of endpoints must be whitelisted in a database that is present in ISE or in an external location in order to grant network access to known endpoints. MAB is not truly an authentication method; it functions more as an authentication bypass when an endpoint is unable to perform 802.1X authentication. While MAB can protect networks from unauthorized access, it is not a secure alternative to 802.1X because MAC addresses can be spoofed easily.
Figure7: Web Authentication Workflow
Web authentications are typically used to onboard guest users for internet access. Cisco platforms provide a couple of options, Local Web Authentication (LWA) and Central Web Authentication (CWA). In the former, web pages are hosted in network devices such as a switch or a wireless LAN controller, and in the latter, all web portals are hosted centrally on ISE. CWA, which is the preferred method, is typically a MAB session with URL-redirect authorization on the switch port. Until the corresponding endpoint is authenticated successfully, web traffic from the endpoint is redirected to ISE via a login portal for end users to enter their credentials. Upon successful authentication, ISE initiates a Change-of-Authorization (CoA) to permit additional access.
Figure8: EasyConnect Authentication Workflow
The Cisco ISE EasyConnect feature enables enterprises to implement identity-based network access without the need for 802.1X. No supplicants or supplicant configurations are needed on endpoints. An EasyConnect session, which is similar to the CWA flow, starts with a MAC authentication bypass. ISE learns about an endpoint’s location, MAC address, and IP addresses via an initial MAB session. This initial MAB session is authorized with limited access from ISE to enable a Windows Active Directory-managed endpoint to perform a Windows domain login. Upon successful domain login, the user ID to IP address mapping from the Active Directory (AD) domain controller is retrieved to ISE and merged with the initial MAB session. After the user ID and its AD group membership is resolved, ISE changes the authorization to permit additional access.
Figure9: Complexity analysis of Authentication methods
Of the various authentication options discussed until now, IEEE 802.1X is the most secure and flexible authentication method. There are several EAP methods that allow a variety of credential types to be handled, depending on the endpoint and the environment type. Although the Web Authentication and EasyConnect options provide the necessary user ID context for visibility and access control, they are constrained to specific types of endpoints, for example, Web Authentication requires user interaction and a device with a compatible web browser and EasyConnect works only for Windows Active Directory-managed endpoints. Finally, MAB is less secure authentication method and fall back mechanism for IEEE 802.1X, but is the easiest option to configure basic level of controlled access.
An ISE authorization policy is composed of authorization rules defined for a specific users and group of users to permit, deny or provide limited access to network resources. Authorization profiles let you choose the attributes to be returned when a RADIUS request is accepted or rejected with RADIUS ACCESS-ACCEPT and ACCESS-REJECT access type commands. Limited access authorization may vary from environment to environment. The question to be asked is, what should be limited, and how?
Figure10: ISE Enforcement authorization attributes
One of the traditional means of limiting network access is by placing endpoints in different VLANs based on their role. Endpoints in specific VLANs can be access controlled by policies that are defined at Layer 3 boundaries, such as on routers or firewalls. ISE can authorize endpoints to specific VLANs using a VLAN name or a VLAN number. Also, in platforms such as Cisco Catalyst 2960X, 3650 Series, 3850 Series, and 9300 Series, VLANs can be applied on a per-MAC address basis.
Best Practice: When doing dynamic VLAN assignment, we recommend using VLAN names rather than numbers. This will make your ISE authorization easier to read, understand and maintain. When you have a large switch, it is better to let the switch locally determine the actual VLAN number assigned with a name.
ACLs can be used to control network access at the port level. They can either be downloaded to the network from ISE, or be configured locally on a switch and be referenced by ISE during authorization. Named ACL authorization can be carried out with a RADIUS-standard attribute called Filter-ID, using the ACL name. For ACL downloads, either a Per-User ACL or a Downloadable ACL (dACL) can be used. Both these ACL download options use Cisco custom RADIUS Attribute Value Pairs (AVPs). While Per-User ACLs have a 4000-character limit, dACLs do not. However, the practical recommendation for dACLs are 64 Access Control Entries (ACEs).
SGTs offer an efficient alternative to VLAN-based segmentation. Just like VLAN authorization, assigning an SGT alone to an endpoint does not control access. Instead, after SGT assignments, endpoints must be subject to egress enforcement policies based on SGTs. Note that although in most cases, identity-based access is necessary for SGT-based segmentation, this document does not cover tag-based segmentation in any detail.
An access switch can redirect endpoints to specific URLs that are authorized by ISE for redirection. Typically, URL redirection is towards the ISE nodes so that the endpoints can carry out web authentication with ISE. However, endpoints can be subject to custom URLs as part of RADIUS authorization from ISE. Custom AVPs are used for URL redirection in an identity-based network.
ISE along with Cisco Catalyst switches implement session-aware networking which offers consistent way to configure features across technologies, easy deployment and features customization along with robust policy control engine . Under this, a session identifier is attached to an endpoint’s network access session (wired or wireless), and session ID is used for all reporting purposes such as show commands, MIBs, and RADIUS messages and allows users to distinguish messages for one session to other sessions. This common session ID is used consistently across all authentication methods and features applied to a session.
Figure11: ISE Session-Aware Networking
When an endpoint connects to network, the network device generates a unique session identifier that is a combination of the network device IP address, the session count on the network device, and the timestamp of the corresponding endpoint’s initial connection.
ISE can invoke the network device to enforce specific policies for the endpoint using the Session ID. After the initial authorization, ISE issues a CoA by referencing the same Session ID. Distinct access policies for the endpoints on the same port are applied because of the separation maintained by the Session ID.
This section focuses on overall design considerations for a secure wired access solution.
There are a few important things to consider with regard to endpoints in an identity-based network. Firstly, how will these endpoints authenticate to the network, and are these using 802.1X, Web Authentication, or some other means? Secondly, do you require custom agents to perform specific functions that the native supplicants in the operating system cannot? And, finally, how should endpoints be configured for appropriate access, for example, manual, using centralized management tools, and so on?
For most of the secure wired access environment, an agent on an endpoint is unnecessary. However, there are a few scenarios that can be handled only by a Cisco AnyConnect end-point agent:
EAP Chaining–Many organizations want to grant network access to trusted users on trusted devices. While the Cisco ISE feature such as Machine Access Restriction (MAR) can handle such cases with native supplicants, it can do so only in various terms. With the presence of Cisco AnyConnect Network Access Manager (NAM) module on the endpoint and Cisco ISE, user and machine authentications can be combined in a common EAP session, making EAP Chaining a secure alternative to MAR.
MACsec–In addition to authenticated network access using IEEE 802.1X, IEEE 802.1AE(MACsec) encryption can be layered on top of IEEE 802.1X to encrypt packets on the link between the endpoint and the switch (point-to-point encryption) ... Cisco AnyConnect is the only supplicant that supports MACsec on endpoints.
Note: The Cisco AnyConnect NAM module is compatible only on Microsoft Windows operating systems. Therefore, both EAP Chaining and MACSec features can be enabled only on Windows-based endpoints currently. |
It is a known fact that implementing port access control with 802.1X means considerable changes to endpoints. Some of the changes pertain to supplicant configurations, certificate installation (optional), and agent installation and setup (optional). Rolling out these changes to thousands of endpoints requires a certain degree of automation. Some of the options to automate supplicant configuration are:
Endpoint Type | Supplicant Configuration By |
Microsoft Windows systems (Managed) | Active Directory – Group Policy Objects (GPO) |
Cisco IP phones | Cisco Unified Call Manager |
Apple devices | MacOS server |
BYOD (Android/Apple iDevices/Microsoft devices/ Google Chrome devices) | Cisco ISE Client Provisioning / Mobile Device Managers |
Table1: Endpoint Automation
Note: Always use a systems manager or device manager to configure endpoints at scale.
In the context of this document, “network device” or “Network Access Device (NAD)” indicates a Cisco Catalyst switch that runs on Cisco IOS software. There are three major configurations to perform on Catalyst switch for it to work with ISE.
Figure12: Network Device Configurations for ISE
ISE might authorize an endpoint with a VLAN, ACL, SGT configuration or URL redirection. Note that some authorization-related configurations have to be done locally on the switch.
Please see How To: Integrate Meraki Networks with ISE for Cisco Meraki Switching implementation.
When it comes to the switch configurations required for ISE deployment, one of the most important considerations is whether to go with IBNS 1.0 or IBNS 2.0 MQC-style commands. IBNS are the identity-based session management services on Cisco IOS, which are meant to handle access services for endpoints connecting to a network. The policy functions on a switch determine how to facilitate an endpoint’s network authentication with a centralized AAA server, how to treat the endpoint when there are authentication failures or how to handle AAA server unreachability. IBNS can be implemented in two ways, depending on the platform support and policy needs.
Figure13: Cisco IBNS 1.0 vs. IBNS 2.0
Apart from significant changes in the Cisco IOS components that handle identity-based services, from an administration and operations perspective, there are considerable differences between IBNS 1.0 and IBNS 2.0. As the figure above depicts, in case of IBNS 1.0, which is sometimes referred to as legacy mode in CLI, a switch’s local policy for handling an endpoint’s identity-based network access is all contained within interface configurations (a list of interface commands applied to a switch port). On the other hand, in case of IBNS 2.0, the configurations take the structure of a Cisco Modular Quality of Service CLI (MQC). One or more subscriber policies are used; these policies are defined by the policy-map command, which classifies various endpoint events into classes that are defined by the <class-map> command arguments. The various endpoint event classifications are subject to specific actions, some of which are local and some of which are enforced on instructions from ISE. The use of templates provides modularity, flexibility, and reusability of certain policy objects within the switch platform.
There are several benefits to using IBNS 2.0 over IBNS 1.0. The following table compares the two:
IBNS 1.0 | IBNS 2.0 | Description | ||
Policy Configuration | Interface commands | MQC Style | IBNS 2.0 is configured the same way as a router QoS policy, while IBNS 1.0 is configured with a list of interface subcommands. | |
Templates |
Interface templates | No | Yes | IBNS 2.0 configurations can be contained within an interface template, while IBNS 1.0 all configuration are interface specific commands. |
Service templates | No | Yes | IBNS 1.0 cannot use service templates. | |
Critical Authorization |
Critical VLAN | Yes | Yes | Both support assigning a fail-open VLAN for endpoints that cannot reach ISE during authentication. |
Critical ACL | No | Yes | Only IBNS 2.0 can apply a custom ACL to an endpoint session when ISE service is unavailable. | |
Critical SGT | No | Yes | Only IBNS 2.0 can assign a critical SGT when the AAA server is down. | |
Critical MAB | No | Yes | With IBNS 2.0, endpoints can be MAB authenticated against a local list of MAC addresses on the switch. | |
Differentiated Authentication | No | Yes | IBNS 2.0 facilitates the task of separating authentication and authorization transactions between two or more AAA servers, while IBNS 1.0 cannot do this. | |
Intelligent Aging | No | Yes | IBNS 2.0 has a better way of detecting the disconnects from indirectly connected hosts. |
Table2: Cisco IBNS 1.0 vs. IBNS 2.0
Enabling 802.1X on switch ports can be disruptive. The need for endpoints to prove their identity with some sort of authentication and then get network access, may not work well for all device types. With wireless, this is a norm because the endpoints do not plug to the network; rather, they have to be configured (for SSIDs) to connect to the network. The notion of configure and connect is built ground up in the wireless world, while the same is not the case with the wired side of networks. For decades, the expectation is that the endpoint must get IP address the moment they plug in to the wired Ethernet port.
We recommend a phased deployment model that has limited impact on network access while gradually introducing authentication and authorization on the wired network. The three deployment modes are:
Figure14: IBNS Deployment Modes
When it comes to wired network access, a carefully set up ISE service is critical. The following are some of the important considerations:
ISE can be deployed as a standalone service or a cluster of multiple ISE nodes. While the former is a good option for small-sized networks, the latter is the choice for medium and large environments. Both standalone and multi-node ISE deployments can be done on bare metal servers (Cisco Secure Network Server [SNS]) or on supported Hypervisors.
Choose the deployment type and install option depending on your requirements. See the ISE Performance & Scale page for more details about scale limitations and performance numbers for each ISE deployment method.
Access switches need to talk to ISE servers for AAA. Typically, two or more RADIUS servers are defined on the switches for AAA and CoA. For large networks involving multiple PSNs per site, we recommend that use of Load Balancers. When Load Balancers are used, the virtual IP addresses of these Load Balancers must be configured as RADIUS server IP addresses on the switches.
The following table summarizes the configuration practice that should be followed, depending upon the type of deployment and whether Load Balancers are used or not.
Switch-Side Configuration | 2-Node Standalone ISE | Multi-Node ISE | Multi-Node ISE with Load Balancers |
RADIUS Server configuration for AAA | IP address of the either ISE nodes | IP address of the PSNs | IP address of the Virtual IP address of the Load Balancers |
RADIUS Server configuration for CoA | IP addresses of the either ISE nodes |
IP addresses of the PSNs and PANs |
IP addresses of the Load Balancer VIP, PSNs, and PANs |
Table3: Deployment Configuration best practices
Cisco ISE licensing provides the ability to manage the application features and access, such as the number of concurrent endpoints that can use Cisco ISE network resources. ISE requires one or more of the following three license packages to service wired endpoints:
However, for most of the AAA and access control services, the Base licenses will suffice. For ISE to automatically detect the endpoint type using profiling service, and to control access to them, both Base and Plus licenses are required. For deeper visibility into applications and processes on endpoints and to control them, Apex licenses are also needed. Note that all these licenses are applied to the endpoint’s session that is active at a given point of time. Therefore, budgeting for adequate licenses must not be on the total number of endpoints, but for an estimated number of active endpoints at a probable peak duration. For more information about licenses, see the Cisco ISE Ordering Guide.
Certificates are used to identify ISE to an endpoint and also to secure the communication between that endpoint and the ISE node. Certificates are used for all HTTPS communication and Extensible Authentication Protocol (EAP) communication. The following is a summary of the certificates and their use in the context of endpoint authentication and access control:
Communication | Uses | Purpose |
HTTPS | · Administration Portal · Centralized Web Authentication Portal · Sponsor Portal · Client Provisioning Portal · My Devices Portal |
· Web authentication · ISE Portal access for administration and operations |
EAP | · EAP-TLS · PEAP · EAP-FAST |
· IEEE 802.1X authentication |
Table 4: Certificate Use Cases in context of Endpoint authentication
We recommend that you do not use ISE self-signed certificates for production. Instead, use a Certificate Authority-signed certificate on the ISE nodes for all purposes. When dealing with internal endpoints that are managed by an organization, an internal enterprise Public Key Infrastructure (PKI) can be used. For use cases such as guest internet access and BYOD registration, ISE node certificates signed by a public CA is recommended to avoid poor user experience due to certificate warnings on the endpoints. ISE has a built-in CA service, but this is largely limited to BYOD identity and authentication. For more information about certificates, see How To: Implement ISE Server-Side Certificates.
This section focuses on deployment guidelines with various best practices to greatly simplify secured wired implementations.
This section shows how to configure ISE and a switch for basic RADIUS connectivity. Cisco ISE supports the default device definition for RADIUS and TACACS authentications. You can define a default network device that Cisco ISE can use if it does not find a device definition for a particular IP address. For advanced flows (such as SNMP,CDP,LLDP) you must add separate device definition for each network device.
This section covers the minimum required configuration on ISE for it to accept AAA requests from a Cisco Catalyst switch.
Perform the following steps to configure a Cisco Catalyst Switch for basic RADIUS connectivity.
c9300-Sw(config)#interface Vlan254 c9300-Sw(config-if)#description ** Switch management interface ** c9300-Sw(config-if)#ip address 172.20.254.101 255.255.255.0 c9300-Sw(config-if)#end
Note: In the example above, the switch is a VTP client and has the necessary VLANs configured. Also, the uplink port connected to the data center is configured as a trunk port. The management IP address for the switch can be an SVI or a Loopback interface. Ensure that proper routing is set up between the access switch and the ISE nodes
c9300-Sw(config)#aaa new-model
c9300-Sw(config)#radius server ISE01 c9300-Sw(config-radius-server)#address ipv4 172.20.254.21 auth-port 1812 acct-port 1813 c9300-Sw(config-radius-server)#key ISEisC00L c9300-Sw(config-radius-server)#exit c9300-Sw(config)# c9300-Sw(config)#radius server ISE02 c9300-Sw(config-radius-server)#address ipv4 172.20.254.22 auth-port 1812 acct-port 1813 c9300-Sw(config-radius-server)#key ISEisC00L c9300-Sw(config-radius-server)#exit
Note: For networks with multi-vendor devices, Its recommended to use Ports 1812 for authentication and 1813 for accounting, however ISE can receive RADIUS authentication and accounting requests on either of the two port number combinations.
c9300-Sw(config)#aaa group server radius ISE c9300-Sw(config-sg-radius)#server name ISE01 c9300-Sw(config-sg-radius)#server name ISE02 c9300-Sw(config-sg-radius)#ip radius source-interface VLAN 254
c9300-Sw(config)#aaa authentication dot1x default group ISE
c9300-Sw(config)#aaa authorization network default group ISE
c9300-Sw(config)#aaa accounting identity default start-stop group ISE
c9300-Sw(config)#aaa accounting update newinfo periodic 2880
Note: After a network access session of an endpoint is logged to ISE, it stays there for 5-days without any additional accounting updates. In order to keep the session active on ISE, a periodic accounting update once every two days is a best practice.
Perform the following tasks to validate if the basic AAA and RADIUS configurations are working as expected:
c9300-Sw#show aaa servers RADIUS: id 1, priority 1, host 172.20.254.21, auth-port 1812, acct-port 1813 State: current UP, duration 38301s, previous duration 0s Dead: total time 0s, count 0 Platform State from SMD: current UP, duration 38301s, previous duration 0s SMD Platform Dead: total time 0s, count 0 Platform State from WNCD: current UP, duration 0s, previous duration 0s Platform Dead: total time 0s, count 0 Quarantined: No !<Output truncated> RADIUS: id 2, priority 2, host 172.20.254.22, auth-port 1812, acct-port 1813 State: current UP, duration 38295s, previous duration 0s Dead: total time 0s, count 0 Platform State from SMD: current UP, duration 38295s, previous duration 0s SMD Platform Dead: total time 0s, count 0 Platform State from WNCD: current UP, duration 0s, previous duration 0s Platform Dead: total time 0s, count 0 Quarantined: No !<Output truncated>
c9300-Sw#test aaa group radius test-user test-password new-code AAA/SG/TEST Platform: Testing Status AAA/SG/TEST: Authen Requests to Send : 1 AAA/SG/TEST: Authen Requests Processed : 1 AAA/SG/TEST: Authen Requests Sent : 1 AAA/SG/TEST: Authen Requests Replied : 1 AAA/SG/TEST: Authen Requests Successful : 0 AAA/SG/TEST: Authen Requests Failed : 1 AAA/SG/TEST: Authen Requests Error : 0 AAA/SG/TEST: Authen Response Received : 1 AAA/SG/TEST: Authen No Response Recevied: 0 AAA/SG/TEST Platform: Testing Status AAA/SG/TEST: Account Requests to Send : 0 AAA/SG/TEST: Account Requests Processed : 0 AAA/SG/TEST: Account Requests Sent : 0 AAA/SG/TEST: Account Requests Replied : 0 AAA/SG/TEST: Account Requests Successful : 0 AAA/SG/TEST: Account Requests Failed : 0 AAA/SG/TEST: Account Requests Error : 0 AAA/SG/TEST: Account Response Received : 0 AAA/SG/TEST: Account No Response Recevied: 0 User rejected
Note: The Authen Requests Replied: 1 message in the output indicates that a RADIUS server is responding to the switch’s requests. Such detailed output for test aaa command is available only from Cisco IOS Version 16.x
You must see one or two failed entries for test-user identity, which indicates that the switch and ISE are talking over RADIUS successfully.
When you click the Details icon corresponding to a test user, you will see the reason for failure: 22056 Subject not found in the applicable identity store(s), which means that the test user account cannot be found, which is obvious at this stage of the deployment.
Another important thing to note is that the switch is using its management IP address to communicate with ISE.
The following section covers the best practice global configuration for Cisco Catalyst switch.
RADIUS Server Failure Detection
c9300-Sw(config)#radius-server dead-criteria time 10 tries 3
The following example shows that the Dead time is set to 15 minutes:
c9300-Sw(config)#radius-server deadtime 15
c9300-Sw(config)#radius server ISE01 c9300-Sw(config-radius-server)#address ipv4 172.20.254.21 auth-port 1812 acct-port 1813 c9300-Sw(config-radius-server)#automate-tester username test-user ignore-acct-port probe-on c9300-Sw(config-radius-server)#key ISEisC00L c9300-Sw(config-radius-server)#exit c9300-Sw(config)# c9300-Sw(config)#radius server ISE02 c9300-Sw(config-radius-server)#address ipv4 172.20.254.22 auth-port 1812 acct-port 1813 c9300-Sw(config-radius-server)#automate-tester username test-user ignore-acct-port probe-on c9300-Sw(config-radius-server)#key ISEisC00L c9300-Sw(config-radius-server)#exit
Note: As mentioned earlier, test-user is a test user ID Username. The ignore-acct-port keyword indicates that the switch must not validate the accounting port number that the server will use. The probe-on keyword indicates that the switch must send test probes only when the server is marked as Dead.
c9300-Sw(config)#username test-user password 0 test-password
c9300-Sw(config)#dot1x critical eapol
c9300-Sw(config)#radius-server attribute 6 on-for-login-auth
c9300-Sw(config)#radius-server attribute 8 include-in-access-req
c9300-Sw(config)#radius-server attribute 25 access-request include
c9300-Sw(config)#radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 mac format {default | ietf | unformatted}
default-Example: 0000.4096.3e4a
ietf-Example: 00-00-40-96-3E-4A
unformatted-Example: 000040963e4a
c9300-Sw(config)#radius-server attribute 31 send nas-port-detail mac-only
c9300-Sw(config)#aaa server radius dynamic-author c9300-Sw(config-locsvr-da-radius)#client 172.20.254.21 server-key ISEisC00L c9300-Sw(config-locsvr-da-radius)#client 172.20.254.22 server-key ISEisC00L
Starting Cisco IOS XE Denali 16.1.1 version, the new Switch Integrated Security Features-based “IP Device Tracking” feature acts as a container policy that enables snooping and device-tracking features available with First Hop Security (FHS) in both IPv4 and IPv6, using IP agnostic CLI commands.
The device-tracking configuration is very critical to learn an endpoint’s IP address and map that to its network access session. The device-tracking configuration is also essential for many features, such as downloadable ACLs, device profiling, URL redirection, and more.Refer to the URL for More Information on the Switch Integrated Security Features based (SISF-based) Device Tracking.
Note: If upgraded a Cisco Catalyst 3850/3650 switch from Cisco IOS XE 3.x.x release to a Cisco IOS XE 16.x.x release and if the switch has IPDT configurations prior to the upgrade, the SISF commands might not be available and we should run the device-tracking upgrade-cli command to convert and use the new SISF commands.
c9300-Sw(config)#device-tracking policy IPDT_POLICY
c9300-Sw(config-device-tracking)#tracking enableNote: It is a best practice to disable the Device tracking for obtaining information about UDP protocols.
c9300-Sw(config-device-tracking)#no protocol udp
Note: The device-tracking policy is effective only when applying the policy to switchport using the following command:
interface GigabitEthernet x/y/z
device-tracking attach-policy POLICY_NAME
Device Sensor is a Cisco IOS and Cisco AireOS feature that simplifies device profiling on ISE. The switch gathers raw endpoint data from protocols such as CDP, LLDP & DHCP and it made available to ISE through RADIUS accounting messages. ISE collects these device attributes and profiles the endpoints into specific device groups.
c9300-Sw(config)#device-sensor accounting
Note: In newer IOS-XE releases, such as 16.3.x and above, replace device-sensor accounting with the following:
access-session attributes filter-list list Def_Acct_List
cdp
lldp
dhcp
http
access-session accounting attributes filter-spec include list Def_Acct_List
c9300-Sw(config)#device-sensor notify all-changes
The following is an example of a CDP device sensor filter and apply the protocol filter to the sensor output.
c9300-Sw(config)#cdp run
c9300-Sw(config)#device-sensor filter-list cdp list CDP-LIST c9300-Sw(config-sensor-cdplist)#tlv name device-name c9300-Sw(config-sensor-cdplist)#tlv name capabilities-type c9300-Sw(config-sensor-cdplist)#tlv name version-type c9300-Sw(config-sensor-cdplist)#tlv name platform-type c9300-Sw(config-sensor-cdplist)#tlv name address-type
c9300-Sw(config)#device-sensor filter-spec cdp include list CDP-LIST
The following is an example of an LLDP device sensor filter and apply the protocol filter to sensor output:
c9300-Sw(config)#lldp run c9300-Sw(config)#device-sensor filter-list lldp list LLDP-LIST c9300-Sw(config-sensor-lldplist)#tlv name system-name c9300-Sw(config-sensor-lldplist)#tlv name system-description c9300-Sw(config-sensor-lldplist)#tlv name system-capabilities c9300-Sw(config)#device-sensor filter-spec lldp include list LLDP-LIST
The following is an example of a DHCP device sensor filter and apply the protocol filter to sensor output:
c9300-Sw(config)#device-sensor filter-list dhcp list DHCP-LIST c9300-Sw(config-sensor-dhcplist)#option name host-name c9300-Sw(config-sensor-dhcplist)#option name parameter-request-list c9300-Sw(config-sensor-dhcplist)#option name class-identifier c9300-Sw(config-sensor-dhcplist)#option name client-identifier c9300-Sw(config-sensor-dhcplist)#option name requested-address c9300-Sw(config-sensor-dhcplist)#device-sensor filter-spec dhcp include list DHCP-LIST
Note: Device sensor configuration without a filter list will overload ISE with unnecessary attributes that does not help in the context of device profiling. The best practice attribute list provided in the example above works well for most environments. For more details on profiling, see the ISE Profiling Design Guide.
Web authentications are necessary for guest internet access. Even if wired guest access is not a requirement for your environment, it is a good idea to have the infrastructure set up for URL redirection because it facilitates notifications to end users in certain scenarios. For instance, when users are not able to authenticate successfully, they can be redirected to an internal portal such as the following, which will guide them about how to resolve the issue themselves.
Figure17: Web Authentication Internal portal support page
c9300-Sw(config)#ip http server
c9300-Sw(config)#ip http active-session-modules none c9300-Sw(config)#ip http secure-active-session-modules none
Note: HTTPS redirection is not recommended for production environments because of the following reasons:
|
c9300-Sw(config)#ip domain-name isedemo.lab
c9300-Sw(config)#crypto key generate rsa general-keys mod 2048
Note: Do not run the ip http secure-server command prior to generating the keys. If you run the commands out of order, the switch automatically generates a certificate with a smaller key size. This certificate can cause undesirable behavior when redirecting HTTPS traffic.
c9300-Sw(config)#ip http secure-server
c9300-Sw(config)#ip http max-connections 48
This ACL defines which traffic is redirected to ISE during the CWA, BYOD, and Posture scenarios. Any traffic that is permitted per ACL is redirected (192.168.1.10 in the example below). Implicit deny prevents other traffic types from being redirected. We recommend that you specify that only HTTP and HTTPS should be permitted since this traffic gets pushed to the switch CPU. If additional access control is needed in conjunction with the redirect ACL, we recommend that you use dACL in conjunction with the redirect ACL.
Note: ACL_WEBAUTH_REDIRECT or Pre-Auth-ACL are port-based ACL which are configured on the interface. However, the dACL or Per_User_ACL pushed from ISE takes precedence over the Port ACL that is applied to the Interface.Figure18: URL Redirection workflow
c9300-Sw(config)#ip access-list extended ACL_WEBAUTH_REDIRECT c9300-Sw(config-ext-nacl)#permit tcp any any eq www c9300-Sw(config-ext-nacl)#permit tcp any any eq 443
Note: The ACL name referenced above is identical to the default redirect ACL name used in fresh ISE 2.0 installation. If you want a different name, make sure that you update both the switch and the ISE Authorization Profile with a new redirect ACL name.
It is also a good idea to have a separate URL redirect ACL for blacklisted devices on ISE. The default rules can redirect all the web traffic. However, depending on your environment and policies, bypass redirection to specific services.
c9300-Sw(config)#ip access-list extended BLOCKHOLE c9300-Sw(config-ext-nacl)#permit tcp any any eq www c9300-Sw(config-ext-nacl)#permit tcp any any eq 443
c9300-Sw(config)#ip access-list extended IPV4_PRE_AUTH_ACL c9300-Sw(config-ext-nacl)#permit udp any eq bootpc any eq bootps c9300-Sw(config-ext-nacl)#permit udp any any eq domain c9300-Sw(config-ext-nacl)#deny ip any any
Note: Pre-Auth-ACL is meant to provide basic network access before successful port authentication in low-impact mode. Therefore, the rules in the ACL must permit only specific service access that is deemed necessary in a given environment. Typically, DHCP and DNS services are permitted so that time-sensitive assets can acquire dynamic IP address while their authentication request is processed by ISE.
Basic Global Configuration for End-Point Authentication
The subsequent sections describe details of the configurations required for performing 802.1X and MAB authentications. However, the following global configurations are essential for most of the deployment scenarios:
c9300-Sw(config)#dot1x system-auth-control
(Optional) Allow sessions without dACL to connect to ACL-enabled interfaces with full access, by running below access-session acl command.
c9300-Sw(config)#access-session acl default passthrough
Note: In older Cisco IOS versions, the epm access-control open command was used for hosts without an authorization policy to access ports configured with a static ACL.This feature is useful in an environment where there is a mixture of authorization profiles that use dACL and ones that do not. For example, user devices are enforced with dACL to limit access to the network, but no dACL is used on IP phones. When an IP phone is connected, the IP phone is authorized to voice resources by MAB/802.1X (without dACL). When a user's device is connected to the back of the IP phone, the switch enforces user-device dACL, which applies the ACL at the interface level. This denies IP access to the IP phone because the IP phone lacks dACL for authorization. However, when the above command is entered globally, the switch dynamically inserts the permit ip any any ACL for sessions without dACL, including the IP phone.
This is also true for multiple devices connected through an unmanaged hub. If multiple devices are already connected without dACL, when a new device with dACL AuthZ is authenticated to the same interface that the unmanaged hub is connected to, then above feature applies the ip permit any anyACL to the previously connected devices sessions.
c9300-Sw(config)#authentication mac-move permit
ip domain name isedemo.lab ! interface Vlan254 description ** Switch management interface ** ip address 172.20.254.101 255.255.255.0 ! aaa new-model aaa session-id common ! radius server ISE01 address ipv4 172.20.254.21 auth-port 1812 acct-port 1813 automate-tester username test-user ignore-acct-port probe-on key ISEisC00L ! radius server ISE02 address ipv4 172.20.254.22 auth-port 1812 acct-port 1813 automate-tester username test-user ignore-acct-port probe-on key ISEisC00L ! username test-user password 0 test-password ! radius-server attribute 6 on-for-login-auth radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include radius-server attribute 31 mac format ietf upper-case radius-server attribute 31 send nas-port-detail mac-only radius-server dead-criteria time 10 tries 3 radius-server deadtime 15 ! aaa group server radius ISE server name ISE01 server name ISE02 ip radius source-interface Vlan254 ! aaa authentication dot1x default group ISE aaa authorization network default group ISE aaa accounting update newinfo periodic 2880 aaa accounting dot1x default start-stop group ISE ! aaa server radius dynamic-author client 172.20.254.21 server-key ISEisC00L client 172.20.254.22 server-key ISEisC00L ! lldp run ! device-sensor filter-list dhcp list DHCP-LIST option name host-name option name requested-address option name parameter-request-list option name class-identifier option name client-identifier ! device-sensor filter-list lldp list LLDP-LIST tlv name system-name tlv name system-description tlv name system-capabilities ! device-sensor filter-list cdp list CDP-LIST tlv name device-name tlv name address-type tlv name capabilities-type tlv name version-type tlv name platform-type ! device-sensor filter-spec dhcp include list DHCP-LIST device-sensor filter-spec lldp include list LLDP-LIST device-sensor filter-spec cdp include list CDP-LIST ! device-sensor accounting device-sensor notify all-changes ! access-session acl default passthrough ! Authentication mac-move permit ! device-tracking policy IPDT_POLICY no protocol udp tracking enable ! crypto key generate rsa general-keys mod 2048 ! ip http server ip http authentication local ip http secure-server ip http secure-active-session-modules none ip http max-connections 48 ip http active-session-modules none ! ip access-list extended ACL_WEBAUTH_REDIRECT permit tcp any any eq www permit tcp any any eq 443 ! ip access-list extended BLOCKHOLE permit tcp any any eq www permit tcp any any eq 443 ! ip access-list extended IPV4_PRE_AUTH_ACL permit udp any eq bootpc any eq bootps permit udp any any eq domain deny ip any any
This section provides information about how to enable identity-based wired network access without causing any disruption to regular network connectivity.Figure19: Open Authentication Workflow
Assuming that most environments have a directory server, which is typically Microsoft Windows Active Directory (AD), the following section focuses on the integration between ISE and Microsoft Windows AD. If your environment uses a directory service other than Microsoft Windows AD, see the appropriate guide in the ISE Design & Integration Guides page.
For more details, see Active Directory Integration with Cisco ISE 2.x.
Note:The credentials used for the join or leave operation are not stored in Cisco ISE. Only the newly created Cisco ISE machine account credentials are stored.
Note: The assumption is that Active Directory domain users who are members of these whitelisted groups exist.
Let us now see how to validate ISE and Active Directory integration.
c9300-Sw#test aaa group radius harry ISEisC00L new-code User successfully authenticated USER ATTRIBUTES username 0 "harry" c9300-Sw# AAA/SG/TEST Platform: Testing Status AAA/SG/TEST: Authen Requests to Send : 1 AAA/SG/TEST: Authen Requests Processed : 1 <Output truncaked>
Let us now see how to whitelist the network device on ISE.
Note: Optionally, you can configure the other parameters in the Network Device configuration, such as Model Name, Software Version, Location, Device Type, and so on. The value defined for these attributes can be used in the ISE authentication and authorization polices to match specific criteria.
Note: ISE allows for bulk configuration of network devices.
One of the options is to upload a CSV file that contains network device details.
The other option is to use REST API calls to the ISE admin node to configure network devices. For more information, see the Cisco ISE API Reference Guide. |
c9300-Sw(config)#interface GigabitEthernet x/y/z c9300-Sw(config-if)#description ** Endpoints and Users **
Note: None of the authentication-related commands are accepted on the interface without this basic configuration.
c9300-Sw(config-if)#switchport mode access c9300-Sw(config-if)#switchport access vlan 100 c9300-Sw(config-if)#switchport voice vlan 101
c9300-Sw(config-if)#spanning-tree portfast
c9300-Sw(config-if)#device-tracking attach-policy IPDT_POLICY
c9300-Sw(config-if)#authentication open
c9300-Sw(config-if)#authentication host-mode multi-auth
c9300-Sw(config-if)#authentication port-control auto
c9300-Sw(config-if)#dot1x pae authenticator
c9300-Sw(config-if)#mab
c9300-Sw(config-if)#dot1x timeout tx-period 7 c9300-Sw(config-if)#dot1x max-reauth-req 3
c9300-Sw(config-if)#authentication periodic
c9300-Sw(config-if)#authentication timer reauthenticate server
c9300-Sw(config-if)#authentication timer inactivity server dynamic
interface GigabitEthernet1/0/1 description ** Endpoints and Users ** switchport access vlan 100 switchport mode access switchport voice vlan 101 device-tracking attach-policy IPDT_POLICY authentication host-mode multi-auth authentication open authentication port-control auto authentication periodic authentication timer reauthenticate server authentication timer inactivity server dynamic mab dot1x pae authenticator dot1x timeout tx-period 7 dot1x max-reauth-req 3 spanning-tree portfast
Note: We strongly recommend that you do not disable the server certificate validation option on the supplicant. This can subject endpoints to Man-in-the-middle and various other attacks. While disabling the server certificate validation in the supplicant can help in quickly testing an endpoint for 802.1X authentication, we strongly recommended that you do the exact opposite in a production environment.
The Windows endpoint is now ready for wired 802.1X authentication.
Note: Although the configuration explained in this section enables 802.1X on a Microsoft Windows endpoint and can be used to validate the end-to-end configuration in an ISE deployment, it is not a recommended configuration method for a large-scale production network. When it comes to a production setup, the following guidelines must be considered:
|
In a few seconds, an authentication window is displayed, asking you enter 802.1X username and password.
You should see the change in IP address and the domain name. Also, note that the 802.1X session timer starts after successful authentication.
Note: As with Microsoft Windows Active Directory and third-party systems managers for Windows endpoints, systems managers are available for Apple OS X devices. These managers can manage inventory, build and deploy applications, and enforce polices on all the managed OS X endpoints in a given environment. For an example of how a systems manager can be used to remotely manage 802.1X configurations on Apple Mac endpoints, see 802.1X Network Authentication for Mac. |
The dashboard displays the total number of endpoints that are connected to the network.
c9300-Sw#show authentication sessions Interface MAC Address Method Domain Status Fg Session ID -------------------------------------------------------------------------------------------- Gi1/0/1 0050.56a7.fa8a dot1x DATA Auth 65FE14AC0000001F1D04947E Gi1/0/1 0064.40b5.794e mab DATA Auth 65FE14AC000000201D049D86 Gi1/0/5 406C.8F39.17AE dot1x DATA Auth 65FE14AC0000000E1845E2D2 <Output trunckated>
c9300-Sw#show authentication session interface Gi 1/0/1 details Interface: GigabitEthernet1/0/1 IIF-ID: 0x119631A2 MAC Address: 0050.56a7.fa8a IPv6 Address: fe80::e55d:20e1:8f:d008 IPv4 Address: 172.20.100.10 User-Name: harry Status: Authorized Domain: DATA Oper host mode: multi-auth Oper control dir: both Session timeout: N/A Common Session ID: 65FE14AC0000001F1D04947E Acct Session ID: 0x00000015 Handle: 0x3f000015 Current Policy: POLICY_Gi1/0/1 Server Policies: Security Policy: None Security Status: Link Unsecured Method status list: Method State dot1x Authc Success ---------------------------------------- Interface: GigabitEthernet1/0/1 IIF-ID: 0x14A4B799 MAC Address: 0064.40b5.794e IPv6 Address: Unknown IPv4 Address: 172.20.101.3 User-Name: 00-64-40-B5-79-4E Status: Authorized Domain: DATA Oper host mode: multi-auth Oper control dir: both Session timeout: N/A Common Session ID: 65FE14AC000000201D049D86 Acct Session ID: 0x00000016 Handle: 0xb5000016 Current Policy: POLICY_Gi1/0/1 Server Policies: Method status list: Method State dot1x Stopped mab Authc Success
One of the simplest ways to configure IBNS 2.0 is to convert an existing IBNS 1.0 configuration on the switch. However,using a composite configuration in IBNS 1.0 style is recommended for the system to generate the best possible policy configuration in the new style. Note that when you convert the configurations, a policy map, a set of class maps, and service templates that will be configured for every single port that has the identity-related configuration. Therefore, the recommendation is to covert a single-port IBNS 1.0 configuration to IBNS 2.0 in a lab, and once a level of comfort is reached in this setting, deploy it in production.
c9300-Sw#authentication display new-style Please note that while you can revert to legacy style configuration at any time unless you have explicitly entered new-style configuration, the following caveats should be carefully read and understood. (1) If you save the config in this mode, it will be written to NVRAM in NEW-style config, and if you subsequently reload the router without reverting to legacy config and saving that, you will no longer be able to revert. (2) In this and legacy mode, Webauth is not IPv6-capable. It will only become IPv6-capable once you have entered new- style config manually, or have reloaded with config saved in 'authentication display new' mode. (3) 'Default' and 'rollback' commands should not be used in this display mode. Either remain in legacy display mode or switch to new-style configuration mode before use.
You will notice that the identity configurations have changed on the interface and new control policy added
c9300-Sw#show running-config interface Gi 1/0/1 Building configuration... Current configuration : 523 bytes ! interface GigabitEthernet1/0/1 description ** Endpoints and Users ** switchport access vlan 100 switchport mode access switchport voice vlan 101 device-tracking attach-policy IPDT_POLICY authentication periodic authentication timer reauthenticate server access-session port-control auto mab dot1x pae authenticator dot1x timeout tx-period 7 dot1x max-reauth-req 3 spanning-tree portfast service-policy type control subscriber POLICY_Gi1/0/1 end
Note: The authentication display new-style command converts an existing IBNS 1.0 configuration to IBNS 2.0. The new style configurations can be reverted to the old style with the authentication display legacy privileged EXEC mode command. However, note that in the new style, if any changes are made to the policy map or any IBNS 2.0-specific commands, or if the system is reloaded with new style configurations written to the startup configuration, you will not be able to revert back to the IBNS 1.0 style configurations from IBNS 2.0. |
c9300-Sw#configure terminal Enter configuration commands, one per line. End with CNTL/Z. c9300-Sw(config)# c9300-Sw(config)#authentication convert-to new-style This operation will permanently convert all relevant authentication commands to their CPL control-policy equivalents. As this conversion is irreversible and will disable the conversion CLI 'authentication display [legacy|new-style]', you are strongly advised to back up your current configuration before proceeding. Do you wish to continue? [yes]: yes
Table5: IBNS 2.0 Class-Map Configurations
Table6: IBNS 2.0 Policy-Map Configurations
c9300-Sw(config)#template PORT-AUTH-TEMPLATE c9300-Sw(config-template)#description ** Endpoints and Users ** c9300-Sw(config-template)#switchport access vlan 100 c9300-Sw(config-template)#switchport mode access c9300-Sw(config-template)#switchport voice vlan 101 c9300-Sw(config-template)#authentication periodic c9300-Sw(config-template)#authentication timer reauthenticate server c9300-Sw(config-template)#access-session port-control auto c9300-Sw(config-template)#mab c9300-Sw(config-template)#dot1x pae authenticator c9300-Sw(config-template)#spanning-tree portfast c9300-Sw(config-template)#service-policy type control subscriber POLICY_Gi1/0/1 c9300-Sw(config-template)#end
Note: Certain interface commands are not supported within interface templates currently. They need to be explicitly configured on the port. The following are the caveats:
|
Note: Notice that the access-session closed command (as on Step 3) is part of the conversion and is being omitted in the interface template configuration. This is because the section focuses on low-impact mode, which is a minor variation of the open mode; in IBNS 2.0, the default port mode is open mode. To move the port to closed mode, configure the access-session closed interface command explicitly either within the interface template or on the physical port
c9300-Sw(config)#default interface GigabitEthernet1/0/1 Interface GigabitEthernet1/0/1 set to default configuration c9300-Sw(config)# c9300-Sw(config)#interface GigabitEthernet1/0/1 c9300-Sw(config-if)#source template PORT-AUTH-TEMPLATE c9300-Sw(config-if)#spanning-tree portfast c9300-Sw(config-if)#device-tracking attach-policy IPDT_POLICY c9300-Sw(config-if)#end c9300-Sw#
c9300-Sw#show running-config interface GigabitEthernet 1/0/1 Building configuration... Current configuration : 192 bytes ! interface GigabitEthernet1/0/1 device-tracking attach-policy IPDT_POLICY source template PORT-AUTH-TEMPLATE spanning-tree portfast end
c9300-Sw#show derived-config interface GigabitEthernet 1/0/1 Building configuration... Derived configuration : 525 bytes ! interface GigabitEthernet1/0/1 description ** Endpoints and Users ** switchport access vlan 100 switchport mode access switchport voice vlan 101 device-tracking attach-policy IPDT_POLICY authentication periodic authentication timer reauthenticate server access-session port-control auto mab dot1x pae authenticator dot1x timeout tx-period 7 dot1x max-reauth-req 3 spanning-tree portfast service-policy type control subscriber POLICY_Gi1/0/1 end
You will also notice some minor changes to the global configuration:
c9300-Sw#show running-config aaa | include accounting aaa accounting Identity default start-stop group ISE aaa accounting update newinfo periodic 2880
Note:
Global AAA and RADIUS server configurations for IBNS 1.0 and IBNS 2.0 are very alike, barring a few minor differences:
|
Switch Global Configuration for AAA, RADIUS in IBNS 2.0
Below is Switch Global AAA,Radius & device sensor configurations
ip domain name isedemo.lab ! interface Vlan254 description ** Switch management interface ** ip address 172.20.254.101 255.255.255.0 ! aaa new-model aaa session-id common ! radius server ISE01 address ipv4 172.20.254.21 auth-port 1812 acct-port 1813 automate-tester username test-user ignore-acct-port probe-on key ISEisC00L ! radius server ISE02 address ipv4 172.20.254.22 auth-port 1812 acct-port 1813 automate-tester username test-user ignore-acct-port probe-on key ISEisC00L ! dot1x system-auth-control dot1x critical eapol ! username test-user password 0 test-password ! radius-server attribute 6 on-for-login-auth radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include radius-server attribute 31 mac format ietf upper-case radius-server attribute 31 send nas-port-detail mac-only radius-server dead-criteria time 10 tries 3 radius-server deadtime 15 ! aaa group server radius ISE server name ISE01 server name ISE02 ip radius source-interface Vlan254 ! aaa authentication dot1x default group ISE aaa authorization network default group ISE aaa accounting Identity default start-stop group ISE aaa accounting update newinfo periodic 2880 ! aaa server radius dynamic-author client 172.20.254.21 server-key ISEisC00L client 172.20.254.22 server-key ISEisC00L ! lldp run ! device-sensor filter-list dhcp list DHCP-LIST option name host-name option name requested-address option name parameter-request-list option name class-identifier option name client-identifier ! device-sensor filter-list lldp list LLDP-LIST tlv name system-name tlv name system-description tlv name system-capabilities ! device-sensor filter-list cdp list CDP-LIST tlv name device-name tlv name address-type tlv name capabilities-type tlv name version-type tlv name platform-type ! device-sensor filter-spec dhcp include list DHCP-LIST device-sensor filter-spec lldp include list LLDP-LIST device-sensor filter-spec cdp include list CDP-LIST ! device-sensor notify all-changes ! access-session attributes filter-list list Def_Acct_List cdp lldp dhcp http access-session accounting attributes filter-spec include list Def_Acct_List ! access-session acl default passthrough ! device-tracking policy IPDT_POLICY no protocol udp tracking enable ! crypto key generate rsa general-keys mod 2048 ! ip http server ip http authentication local ip http secure-server ip http secure-active-session-modules none ip http max-connections 48 ip http active-session-modules none ! ip access-list extended ACL_WEBAUTH_REDIRECT permit tcp any any eq www permit tcp any any eq 443 ! ip access-list extended BLOCKHOLE permit tcp any any eq www permit tcp any any eq 443 ! ip access-list extended IPV4_CRITICAL_ACL permit ip any any ! ip access-list extended IPV4_PRE_AUTH_ACL permit udp any eq bootpc any eq bootps permit udp any any eq domain deny ip any any !
In Monitor Mode, authentication occurs but network access is not restricted based on the authentication result. A combination of Cisco Identity Services Engine (ISE) policies and switchport commands is used to give all devices full access to the network. In Monitor Mode, network administrators can determine which users or devices would have failed authentication and why.
Cisco Recommends deploying 802.1x in a staged approach. The stages begin with Monitor Mode as the initial stage and end state will be either Low-Impact Mode or Closed Mode. The deployment modes beyond Monitor-Mode gradually builds access controls into the design through Port-based ACLs, dACLS and /or VLAN authorizations.
After gaining enough visibility in the monitor mode, the next step is to enforce restricted access. Low-Impact mode incrementally increases the security level of the network by configuring an ingress port ACL on top of Monitor-Mode interface configurations. This provides basic connectivity for hosts while selectively limiting access and introducing a higher level of security. Pre-authentication access control is be done via port access control lists which are locally defined on the switchport, post-authentication access control can be done via downloadable or named access control lists. Such level of access is required for PXE boot environments where network access must be granted prior to authentication.
Note: Dynamic VLAN assignment is not a recommended authorization option for low-impact mode. Since endpoints acquire IP address before network authentication in the default VLAN, a change in the VLAN assignment forces the endpoints to renew their IP addresses, which might not happen automatically, thereby locking them out of the network in spite of an authorized access as per ISE policy.
Some endpoint types have the intelligence to detect network changes. The Windows workstation for instance, attempts to ping the default gateway (thrice within seconds) with TTL=1, upon receiving an EAP-Success message from the switch, endpoint assumes that there is no change in the VLAN and retains its IP address. If the switch doesn’t respondendpoint releases the IP address . This feature was introduced in Windows XP SP2 with the following KB:
KB822596: DHCP does not obtain a new address when EAP reauthenticates across access points with IP subnets that differ.
The behavior with Apple macOS X is similar. However, when the system receives an EAP success message, the endpoint tries to reach the DHCP server to renew its IP address, thrice with a minute wait time between the attempts. |
c9300-Sw#show ip access-list IPV4_PRE_AUTH_ACL Extended IP access list IPV4_PRE_AUTH_ACL 10 permit udp any eq bootpc any eq bootps 20 permit udp any any eq domain 30 deny ip any any
c9300-Sw(config)#interface gigabitEthernet 1/0/1 c9300-Sw(config-if)#ip access-group IPV4_PRE_AUTH_ACL in
c9300-Sw#show derived-config interface GigabitEthernet 1/0/1 Building configuration... Derived configuration : 525 bytes ! interface GigabitEthernet1/0/1 description ** Endpoints and Users ** switchport access vlan 100 switchport mode access switchport voice vlan 101 device-tracking attach-policy IPDT_POLICY ip access-group IPV4_PRE_AUTH_ACL in authentication periodic authentication timer reauthenticate server access-session control-direction in access-session port-control auto mab dot1x pae authenticator dot1x timeout tx-period 7 dot1x max-reauth-req 3 spanning-tree portfast service-policy type control subscriber POLICY_Gi1/0/1 end
Note: In this example, Employees are denied access to a specific subnet PCI network and are given access to everything else. IP phones have access to the subnet where the Call Manager, DHCP, DNS servers and other peers in the default and voice VLANs reside,
and the rest of the network access is denied.
In terms of the Access Control Entries (ACEs) for the downloadable ACLs, the recommendation is to keep it small so that it is easy to download the policy to the network device. In addition, small ACLs can optimize the Ternary Content Addressable Memory (TCAM) memory consumption on the access switch. The best practice limit for dACLs is 64 ACEs (64 lines). |
You will see that both the Employee PC and the IP phones have dACL authorization.
In the Result dialog box, you will see individual dACL rules that are downloaded to the switch.
Note: In IBNS 2.0, most of the authentication commands are converted to access-session commands. So, show authentication sessions is show access-session in IBNS 2.0.
c9300-Sw#show access-session interface Gi 1/0/1 details Interface: GigabitEthernet1/0/1 IIF-ID: 0x1639E95C MAC Address: 0064.40b5.794e IPv6 Address: Unknown IPv4 Address: 172.20.101.3 User-Name: 00-64-40-B5-79-4E Status: Authorized Domain: VOICE Oper host mode: multi-auth Oper control dir: in Session timeout: N/A Common Session ID: 65FE14AC0000003532D7D09C Acct Session ID: 0x0000002b Handle: 0x6800002b Current Policy: POLICY_Gi1/0/1 Local Policies: Idle timeout: 65536 sec Server Policies: ACS ACL: xACSACLx-IP-VoiceACL-5aee9aa7 Method status list: Method State dot1x Stopped mab Authc Success ---------------------------------------- Interface: GigabitEthernet1/0/1 IIF-ID: 0x1645C323 MAC Address: 0050.56a7.fa8a IPv6 Address: fe80::e55d:20e1:8f:d008 IPv4 Address: 172.20.100.10 User-Name: harry Status: Authorized Domain: DATA Oper host mode: multi-auth Oper control dir: in Session timeout: N/A Common Session ID: 65FE14AC0000003432D7C631 Acct Session ID: 0x0000002a Handle: 0x7d00002a Current Policy: POLICY_Gi1/0/1 Local Policies: Idle timeout: 65536 sec Server Policies: Security Policy: None Security Status: Link Unsecured SGT Value: 4 ACS ACL: xACSACLx-IP-EmployeeAccessACL-5aee9a60 Method status list: Method State dot1x Authc Success
Note: The dACL names are appended with session timestamps when downloaded from ISE.
c9300-Sw#show ip access-lists | section xACSACLx-IP- Extended IP access list xACSACLx-IP-EmployeeAccessACL-5aee9a60 1 deny ip any 172.20.199.0 0.0.0.255 2 permit ip any any Extended IP access list xACSACLx-IP-VoiceACL-5aee9aa7 1 permit ip any 172.20.254.0 0.0.0.255 2 permit ip any 172.20.100.0 0.0.0.255 3 permit ip any 172.20.101.0 0.0.0.255 4 deny ip any any
c9300-Sw#show platform software fed switch 1 acl interface | begin 1/0/1 INTERFACE: GigabitEthernet1/0/1 MAC 0000.0000.0000 ######################################################## intfinfo: 0x7fa8fc02cba8 Interface handle: 0xaa000027 Interface Type: Port IIF ID: 0x8 Input IPv6: Policy Handle: 0x990000b6 Policy Name: sisf v6acl 0001DF9F CG ID: 16 CGM Feature: [0] acl Bind Order: 0 Input IPv4: Policy Handle: 0xef00007a Policy Name: IPV4_PRE_AUTH_ACL CG ID: 19 CGM Feature: [0] acl Bind Order: 0 INTERFACE: Client MAC 0064.40b5.794e MAC 0064.40b5.794e ######################################################## intfinfo: 0x7fa8fc036638 Interface handle: 0xc2000085 Interface Type: Group IIF ID: 0x1c314c66 Input IPv4: Policy Handle: 0x6a0000ba Policy Name: IPV4_PRE_AUTH_ACL:xACSACLx-IP-VoiceACL-5aee9aa7: CG ID: 4880 CGM Feature: [35] acl-grp Bind Order: 0 INTERFACE: Client MAC 0050.56a7.fa8a MAC 0050.56a7.fa8a ######################################################## intfinfo: 0x7fa8fc058078 Interface handle: 0xf9000084 Interface Type: Group IIF ID: 0x1debb70b Input IPv4: Policy Handle: 0x640000b7 Policy Name: IPV4_PRE_AUTH_ACL:xACSACLx-IP-EmployeeAccessACL-5aee9a60: CG ID: 4624 CGM Feature: [35] acl-grp Bind Order: 0
Note: Similar ACL programming information can be obtained on the Catalyst 3650 and 3850 switch platforms by running the show platform acl le privileged EXEC mode command.
In the other platforms, running the show ip access-list interface <interface-id> command will provide the cumulative list of ACEs that are applied on a specific port.
One of the many advantages of using IBNS 2.0 is that it can handle failure scenarios efficiently. With a few additional tweaks to the previously configured IBNS 2.0 configuration, endpoints that have been authorized previously by ISE can be given the same level of network access even when the server is not reachable the next time. The idea is to grant role-based access during critical conditions, instead of applying a common critical authorization.
Figure20: Critical Authorization in Low-Impact Mode
In the following procedure, a user role ‘Employees’ is created which is the same name as Security Group Tag on ISE. When Employee users authenticate the first time, the user role is downloaded from ISE. Later, when the same users re-connect to the network when ISE is unreachable, the same network access authorization is applied locally by the switch.
Note that the ACL rules are the same as the downloadable ACLs configured on ISE for the Employee user group.
c9300-Sw(config)#ip access-list extended IPV4_EMPLOYEE_CRITICAL_ACL c9300-Sw(config-ext-nacl)#deny ip any 172.20.199.0 0.0.0.255 c9300-Sw(config-ext-nacl)#permit ip any any
c9300-Sw(config)#service-template EMPLOYEE_CRITICAL_AUTH_ACCESS c9300-Sw(config-service-template)#description ** Policy For Employees during IAB ** c9300-Sw(config-service-template)#access-group IPV4_EMPLOYEE_CRITICAL_ACL c9300-Sw(config-service-template)#sgt 4
Current ISE policy for the Employee user group
c9300-Sw(config)#class-map type control subscriber match-all AAA_DOWN_UNAUTHD_EMPLOYEE c9300-Sw(config-filter-control-classmap)#match result-type aaa-timeout c9300-Sw(config-filter-control-classmap)#match authorization-status unauthorized c9300-Sw(config-filter-control-classmap)#match user-role Employees
c9300-Sw(config)# class-map type control subscriber match-any IN_CRITICAL_AUTH c9300-Sw(config-filter-control-classmap)#match activated-service-temp CRITICAL_AUTH_ACCESS c9300-Sw(config-filter-control-classmap)#match activated-service-temp DEFAULT_CRITICAL_VOICE_TEMPLATE c9300-Sw(config-filter-control-classmap)#match activated-service-temp EMPLOYEE_CRITICAL_AUTH_ACCESS c9300-Sw(config-filter-control-classmap)#exit c9300-Sw(config)#class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH c9300-Sw(config-filter-control-classmap)#match activated-service-temp CRITICAL_AUTH_ACCESS c9300-Sw(config-filter-control-classmap)#match activated-service-temp DEFAULT_CRITICAL_VOICE_TEMPLATE c9300-Sw(config-filter-control-classmap)#match activated-service-templ EMPLOYEE_CRITICAL_AUTH_ACCESS c9300-Sw(config-filter-control-classmap)#exit
policy-map type control subscriber PORT-AUTH-POLICY event session-started match-all 10 class always do-until-failure 10 authenticate using dot1x priority 10 event authentication-failure match-first 5 class DOT1X_FAILED do-until-failure 10 terminate dot1x 20 authenticate using mab priority 20 15 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure 10 clear-authenticated-data-hosts-on-port 20 activate service-template EMPLOYEE_CRITICAL_AUTH_ACCESS 30 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE 40 authorize 50 pause reauthentication 20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure 10 pause reauthentication 20 authorize 30 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 authenticate using mab priority 20 40 class MAB_FAILED do-until-failure 10 terminate mab 20 authentication-restart 60 60 class always do-until-failure 10 terminate dot1x 20 terminate mab 30 authentication-restart 60 event agent-found match-all 10 class always do-until-failure 10 terminate mab 20 authenticate using dot1x priority 10 event aaa-available match-all 10 class IN_CRITICAL_AUTH do-until-failure 10 clear-session 20 class NOT_IN_CRITICAL_AUTH do-until-failure 10 resume reauthentication event inactivity-timeout match-all 10 class always do-until-failure 10 clear-session event authentication-success match-all event violation match-all 10 class always do-until-failure 10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE
c9300-Sw(config)#template PORT-AUTH-TEMPLATE c9300-Sw(config-template)#description ** Endpoints and Users ** c9300-Sw(config-template)#switchport access vlan 100 c9300-Sw(config-template)#switchport mode access c9300-Sw(config-template)#switchport voice vlan 101 c9300-Sw(config-template)#authentication periodic c9300-Sw(config-template)#authentication timer reauthenticate server c9300-Sw(config-template)#access-session control-direction in c9300-Sw(config-template)#access-session port-control auto c9300-Sw(config-template)#mab c9300-Sw(config-template)#dot1x pae authenticator c9300-Sw(config-template)#spanning-tree portfast c9300-Sw(config-template)#no service-policy type control subscriber PORT-AUTH-POLICY c9300-Sw(config-template)#service-policy type control subscriber PORT-AUTH-POLICY c9300-Sw(config-template)#end
c9300-Sw#show access-session interface gigabitEthernet 1/0/1 details Interface: GigabitEthernet1/0/1 IIF-ID: 0x1E27B669 MAC Address: 0050.56a7.fa8a IPv6 Address: Unknown IPv4 Address: 172.20.100.10 User-Name: harry User-Role: Employees Status: Authorized Domain: DATA Oper host mode: multi-auth Oper control dir: in Session timeout: N/A Common Session ID: 65FE14AC0000005A3912107F Acct Session ID: 0x00000050 Handle: 0xbb000050 Current Policy: PORT-AUTH-POLICY Local Policies: Idle timeout: 65536 sec Server Policies: Security Policy: None Security Status: Link Unsecured SGT Value: 4 ACS ACL: xACSACLx-IP-EmployeeAccessACL-5aee9a60 Method status list: Method State dot1x Authc Succes
The user role is cached on the switch.
Note: In case of empty cache, make sure “device classifier” is enabled.
c9300-Sw#show access-session cache Access session cache details ---------------------------------------- MAC Address: 0050.56a7.fa8a Device-type: User-role: Employees Protocol-map: 00000000 ---------------------------------------- <Output truncated>
The IP ACL is applied to the Employee’s session.
c9300-Sw#show ip access-lists xACSACLx-IP-EmployeeAccessACL-5aee9a60 Extended IP access list xACSACLx-IP-EmployeeAccessACL-5aee9a60 1 deny ip any 172.20.199.0 0.0.0.255 2 permit ip any any
c9300-Sw#show aaa servers | include id|State RADIUS: id 1, priority 1, host 172.20.254.21, auth-port 1812, acct-port 1813 State: current DEAD, duration 107s, previous duration 555708s Platform State from SMD: current DEAD, duration 106s, previous duration 556543s Platform State from WNCD: current UP, duration 0s, previous duration 0s RADIUS: id 2, priority 2, host 172.20.254.22, auth-port 1812, acct-port 1813 State: current DEAD, duration 92s, previous duration 555723s Platform State from SMD: current DEAD, duration 91s, previous duration 556558s Platform State from WNCD: current UP, duration 0s, previous duration 0s
You will notice that the switch has applied the same policies that ISE would apply, but locally, based on the cached user role
c9300-Sw#show access-session interface gigabitEthernet 1/0/1 details Interface: GigabitEthernet1/0/1 IIF-ID: 0x1413C541 MAC Address: 0050.56a7.fa8a IPv6 Address: fe80::e55d:20e1:8f:d008 IPv4 Address: 172.20.100.10 User-Role: Employees Status: Authorized Domain: UNKNOWN Oper host mode: multi-auth Oper control dir: in Session timeout: N/A Common Session ID: 65FE14AC0000005C392B1226 Acct Session ID: 0x00000052 Handle: 0x43000052 Current Policy: PORT-AUTH-POLICY Local Policies: Idle timeout: 65536 sec Service Template: EMPLOYEE_CRITICAL_AUTH_ACCESS (priority 150) Filter-ID: IPV4_EMPLOYEE_CRITICAL_ACL SGT Value: 4 Method status list: Method State dot1x Authc Failed
Note: Similar local policies can be configured for other users or device types.
The access-session cache is cleared either when the switch reloads or the endpoint logoff (EAPOL-Logoff), which typically occurs in most of the operating systems. |
There are scenarios where AAA transactions must be carried out from the same network device, with distinct groups of RADIUS servers. This is typical in wireless networks, where configurations can be done on a per SSID basis. However, on the switch side, such differentiated authentication was not possible until the introduction of IBNS 2.0. The following are a couple of use cases for differentiated authentication:
Figure21: Differentiated Authentication with IBNS 2.0
Example below briefs you how to modify the switch configuration to perform differentiated authentication so that specific sets of interfaces on the switch talk to specific ISE servers.
Global AAA and RADIUS Server Definition
radius server ISE01 address ipv4 172.20.254.21 auth-port 1812 acct-port 1813 automate-tester username test-user ignore-acct-port probe-on key ISEisC00L ! radius server ISE02 address ipv4 172.20.254.22 auth-port 1812 acct-port 1813 automate-tester username test-user ignore-acct-port probe-on key ISEisC00L !
aaa group server radius ISE-CUBE-1 server name ISE01 ip radius source-interface Vlan254 ! aaa group server radius ISE-CUBE-2 server name ISE02 ip radius source-interface Vlan254 ! aaa authentication dot1x default group radius aaa authentication dot1x AAA_LIST1 group ISE-CUBE-1 aaa authentication dot1x AAA_LIST2 group ISE-CUBE-2 ! aaa authorization network default group radius aaa authorization network AAA_LIST1 group ISE-CUBE-1 aaa authorization network AAA_LIST2 group ISE-CUBE-2 ! aaa accounting Identity AAA_LIST2 start-stop group ISE-CUBE-2 aaa accounting Identity AAA_LIST1 start-stop group ISE-CUBE-1 ! aaa accounting network AAA_LIST1 start-stop group ISE-CUBE-1 aaa accounting network AAA_LIST2 start-stop group ISE-CUBE-2 !
aaa accounting Identity default start-stop broadcast group ISE-CUBE-1 group ISE-CUBE-2 aaa accounting network default start-stop broadcast group ISE-CUBE-1 group ISE-CUBE-2 aaa accounting system default start-stop broadcast group ISE-CUBE-1 group ISE-CUBE-2
aaa server radius dynamic-author client 172.20.254.21 server-key ISEisC00L client 172.20.254.22 server-key ISEisC00L auth-type any
policy-map type control subscriber PORT-AUTH-POLICY-CUBE1 event session-started match-all 10 class always do-until-failure 10 authenticate using dot1x aaa authc-list ISE-CUBE-1 authz-list ISE-CUBE-1 priority 10 ... event authentication-failure match-first ... 30 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 authenticate using mab aaa authc-list ISE-CUBE-1 authz-list ISE-CUBE-1 priority 20 ...
policy-map type control subscriber PORT-AUTH-POLICY-CUBE2 event session-started match-all 10 class always do-until-failure 10 authenticate using dot1x aaa authc-list ISE-CUBE-2 authz-list ISE-CUBE-2 priority 10 ... event authentication-failure match-first ... 30 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 authenticate using mab aaa authc-list ISE-CUBE-2 authz-list ISE-CUBE-2 priority 20 ...
template PORT-AUTH-TEMPLATE-CUBE1 description ** Endpoints and Users on Cube-1 ISE ** spanning-tree portfast dot1x pae authenticator switchport access vlan 100 switchport mode access switchport voice vlan 101 mab access-session control-direction in access-session closed access-session port-control auto authentication periodic authentication timer reauthenticate server service-policy type control subscriber PORT-AUTH-POLICY-CUBE1 ! template PORT-AUTH-TEMPLATE-CUBE2 description ** Endpoints and Users on Cube-2 ISE ** spanning-tree portfast dot1x pae authenticator switchport access vlan 100 switchport mode access switchport voice vlan 101 mab access-session control-direction in access-session closed access-session port-control auto authentication periodic authentication timer reauthenticate server service-policy type control subscriber PORT-AUTH-POLICY-CUBE2
c9300-Sw(config)#interface range GigabitEthernet 1/0/1 - 11 c9300-Sw(config-if-range)#source template PORT-AUTH-POLICY-CUBE1 c9300-Sw(config-if-range)#exit c9300-Sw(config)# c9300-Sw(config)#interface range GigabitEthernet 1/0/12 - 22 c9300-Sw(config-if-range)#source template PORT-AUTH-POLICY-CUBE2 c9300-Sw(config-if-range)#exit
Differentiated Authentication for Authentication Methods
policy-map type control subscriber PORT-AUTH-POLICY-DIFF-AUTH event session-started match-all 10 class always do-until-failure 10 authenticate using dot1x aaa authc-list ISE-CUBE-1 authz-list ISE-CUBE-1 priority 10 ... event authentication-failure match-first ... 30 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 authenticate using mab aaa authc-list ISE-CUBE-2 authz-list ISE-CUBE-2 priority 20 ...
When two or more ISE deployments are managed in an environment and differentiated authentication is used, certain authorizations from ISE may not work well because they require communication with specific ISE servers for additional attributes. For example, when an endpoint is authorized for a downloadable ACL from ISE-Cube-2, the switch only gets the ACL name in the initial flow. In the second flow, it needs to download the ACL rules, but because it is not a standard session-start, the switch will query ISE-Cube-1 for ACEs. If the dACL configurations are not consistent across the ISE deployments, the authorization fails. The fix is to use an additional Cisco AV pair in the authorization to inform the switch about which server group to reach out for additional attributes. The following ISE authorization profile shows the downloadable ACL and the special AVP.
Note: The Method-List AVP (AAA_LIST1 in the example above) on ISE must match the AAA method list on the switch and not the AAA server group:
! aaa authorization network AAA_LIST1 group ISE-CUBE-1 aaa authorization network AAA_LIST2 group ISE-CUBE-2 ! |
IPv6 is an inevitable future and most of the ISE deployments that are on IPv4 should be migrated to IPv6 in the future. When it comes to dealing with an ISE-based solution for a Cisco Catalyst switch in IPv6 networks, the following table compares the possibilities in contrast to IPv4 networks:
Feature | IPV4 Network | IPV6 Network |
ISE and Switch Addressing | Yes | Yes |
IPV4/IPV6 device tracking on switch | Yes | Yes |
Network device configuration on ISE | Yes | Yes (Starting ISE 2.4) |
Open Mode(No Authorization) | Yes | Yes |
Closed Mode(With VLAN assignments) | Yes | Yes |
Low-Impact Mode(With ACL authorizations) | Yes | Partial(Limited platform support, no dACL*) |
Downloadable ACLs | Yes | No |
URL Redirection | Yes | No |
Security Group Tags | Yes | Yes |
Table7: IBNS 2.0 v4/v6 Feature parity
* Only Filter ID and Per-User ACLs are supported on Catalyst 3650, 3850, and 9300 platforms.
ise01/admin# configure terminal Enter configuration commands, one per line. End with CNTL/Z. ise01/admin(config)# interface GigabitEthernet 0 ise01/admin(config-GigabitEthernet)# ipv6 enable ise01/admin(config-GigabitEthernet)# ipv6 address 2001:20:254::21/64 Changing the IPV6 address may result in undesired side effects on any installed application(s). Are you sure you want to proceed? Y/N [N]: Y Stopping ISE Monitoring & Troubleshooting Log Collector... Stopping ISE Monitoring & Troubleshooting Log Processor... PassiveID WMI Service is disabled <Output truncaked>
Note: In a distributed ISE deployment, each Policy Administration Node (PAN) and Policy Services Node (PSN) must be configured with an IPv6 address.
All the ISE services on a node restart after a new IPv6 address is configured. |
c9300-Sw(config)#ipv6 unicast-routing
c9300-Sw#show running-config interface vlan 254 Building configuration... Current configuration : 160 bytes ! interface Vlan254 description ** Switch management interface ** ip address 172.20.254.101 255.255.255.0 ipv6 address 2001:20:254::101/64 ipv6 enable end
Note: Ensure that end-to-end IPv6 routing is configured so that the access switch can talk to ISE nodes over IPv6.
c9300-Sw#ping ipv6 2001:20:254::21 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:20:254::21, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
c9300-Sw#show running-config | begin device-tracking device-tracking policy IPDT_POLICY no protocol udp tracking enable ! interface GigabitEthernet1/0/1 device-tracking attach-policy IPDT_POLICY
Note: On C3650 and C3850 switch platforms running Cisco IOS version earlier than 16.1, configure the following commands for IPv6 device tracking:
ipv6 neighbor tracking ipv6 neighbor binding ! vlan configuration 100-101 ipv6 nd suppress ipv6 snooping ! ipv6 snooping policy SNOOP-V6 trusted-port ! interface GigabitEthernet1/0/24 description ** Uplink Port to Distribution Switch ** ipv6 snooping attach-policy SNOOP-v6 ip dhcp snooping trust ! |
This section provides information about how the global configuration described in the Switch Global Configuration Dump for AAA, RADIUS and More in IBNS 2.0 section is modified for IPv6.
c9300-Sw(config)#radius server ISE01 c9300-Sw(config-radius-server)#address ipv6 2001:20:254::21 auth-port 1812 acct-port 1813 c9300-Sw(config-radius-server)#no address ipv4 172.20.254.21 auth-port 1812 acct-port 1813 c9300-Sw(config-radius-server)#automate-tester username test-user ignore-acct-port probe-on c9300-Sw(config-radius-server)#key ISEisC00L c9300-Sw(config-radius-server)#exit c9300-Sw(config)# c9300-Sw(config)#radius server ISE02 c9300-Sw(config-radius-server)#address ipv6 2001:20:254::22 auth-port 1812 acct-port 1813 c9300-Sw(config-radius-server)#no address ipv4 172.20.254.22 auth-port 1812 acct-port 1813 c9300-Sw(config-radius-server)#automate-tester username test-user ignore-acct-port probe-on c9300-Sw(config-radius-server)#key ISEisC00L c9300-Sw(config-radius-server)#exit
c9300-Sw(config)#aaa server radius dynamic-author c9300-Sw(config-locsvr-da-radius)#client 2001:20:254::21 server-key ISEisC00L c9300-Sw(config-locsvr-da-radius)#client 2001:20:254::22 server-key ISEisC00L c9300-Sw(config-locsvr-da-radius)#no client 172.20.254.21 server-key ISEisC00L c9300-Sw(config-locsvr-da-radius)#no client 172.20.254.22 server-key ISEisC00L c9300-Sw(config-locsvr-da-radius)#end
c9300-Sw#show aaa servers | include RADIUS|State RADIUS: id 1, priority 1, host 2001:20:254::21, auth-port 1812, acct-port 1813 State: current UP, duration 19s, previous duration 199s Platform State from SMD: current UP, duration 19s, previous duration 2885s Platform State from WNCD: current UP, duration 0s, previous duration 0s RADIUS: id 2, priority 2, host 2001:20:254::22, auth-port 1812, acct-port 1813 State: current UP, duration 17s, previous duration 0s Platform State from SMD: current UP, duration 17s, previous duration 0s Platform State from WNCD: current UP, duration 0s, previous duration 0s
c9300-Sw(config)#ipv6 access-list IPV6_PRE_AUTH_ACL c9300-Sw(config-ipv6-acl)#permit udp any any eq bootpc c9300-Sw(config-ipv6-acl)#permit udp any any eq domain c9300-Sw(config-ipv6-acl)#deny ipv6 any any
IPv6 Pre-authentication ACL is very similar to the IPv4 Pre-Authentication ACL configuration
c9300-Sw#show ip access-lists IPV4_PRE_AUTH_ACL Extended IP access list IPV4_PRE_AUTH_ACL 10 permit udp any eq bootpc any eq bootps 20 permit udp any any eq domain 30 deny ip any any c9300-Sw#show ipv6 access-list IPV6_PRE_AUTH_ACL IPv6 access list IPV6_PRE_AUTH_ACL permit udp any eq bootpc any eq bootps sequence 10 permit udp any any eq domain sequence 20 deny ipv6 any any sequence 30
c9300-Sw(config)#ipv6 access-list IPV6_CRITICAL_ACL c9300-Sw(config-ipv6-acl)#permit ipv6 any any
IPv6 Critical ACL is very similar to IPv4 Critical ACL configured earlier
c9300-Sw#show ip access-lists IPV4_CRITICAL_ACL Extended IP access list IPV4_CRITICAL_ACL 10 permit ip any any
c9300-Sw(config)#service-template CRITICAL_AUTH_ACCESS c9300-Sw(config-service-template)#access-group IPV6_CRITICAL_ACL c9300-Sw(config-service-template)#end c9300-Sw#show running-config | begin service-template ... service-template CRITICAL_AUTH_ACCESS description ** Access Policy For IAB ** access-group IPV4_CRITICAL_ACL access-group IPV6_CRITICAL_ACL !
c9300-Sw(config)#interface gigabitEthernet 1/0/1 c9300-Sw(config-if)#ipv6 traffic-filter IPV6_PRE_AUTH_ACL in c9300-Sw(config-if)#end c9300-Sw#show running-config interface GigabitEthernet 1/0/1 Building configuration... Current configuration : 272 bytes ! interface GigabitEthernet1/0/1 device-tracking attach-policy IPDT_POLICY ip access-group IPV4_PRE_AUTH_ACL in ipv6 traffic-filter IPV6_PRE_AUTH_ACL in source template PORT-AUTH-TEMPLATE spanning-tree portfast end
Note: Current Cisco IOS & ISE software implementation doesn’t support native IPv6 dACL’s over RADIUS. Its currently implementation of IPv6 on RADIUS uses Cisco Vendor Specific Attributes(VSA).
The two rules configured in this sample procedure are:
Note: Apart from Per-User ACL, the other two ACL authorization options for IPv6 currently are Filter ID and Service Template.
|
c9300-Sw#show access-session interface gigabitEthernet 1/0/1 details Interface: GigabitEthernet1/0/1 IIF-ID: 0x1DD98B5E MAC Address: 0050.56a7.fa8a IPv6 Address: 2001:20:100:0:4d0d:2a03:cd86:7241 2001:20:100:0:e55d:20e1:8f:d008 fe80::e55d:20e1:8f:d008 IPv4 Address: 172.20.100.13 User-Name: harry User-Role: Employees Status: Authorized Domain: DATA Oper host mode: multi-auth Oper control dir: in Session timeout: N/A Common Session ID: 000000000000001142C99F70 Acct Session ID: 0x00000007 Handle: 0x03000007 Current Policy: PORT-AUTH-POLICY Server Policies: Security Policy: None Security Status: Link Unsecured SGT Value: 4 ACS ACL: xACSACLx-IP-EmployeeAccessACL-5af1634e Per-User ACL: Gi1/0/1#v6#1dd98b5e : deny ipv6 any 2001:20:199::/64 : permit ipv6 any any Method status list: Method State dot1x Authc Success
Closed Mode is a more traditional deployment model of 802.1X. In a properly prepared network, Closed Mode provides total control over switch-level (Layer 2) network access. This type of deployment is recommended only for environments that are experienced with 802.1X deployments and have considered all the nuances that go along with it. Think of this mode as a “deploy with caution” mode.
In Closed Mode, the switchport does not allow traffic except EAP over LAN(EAPoL) until a successful authentication takes place. No pre-authentication access to DHCP, DNS, HTTP and PXE boot servers are allowed while authentication is in progress. Closed Mode is ideal for Vlan-based enforcement since the client does not get an IP address until successfully authenticated.
Deploying Closed Mode with Vlan Assignment can have a significant impact on network architecture. Understanding these potential impacts is essentials for successful deployment of this mode.
Vlan Considerations: Dynamic VLAN assignment requires that every dynamic VLAN be supported on every access switch to which a user might connect and authenticate. Hence a good campus design dictate a fewer VLANs which helps in more manageable and scalable solution.
Granting Limited Access if primary authentication fails: If some level of access is needed for devices that fail 802.1X authentication, it is possible to configure switch port to open the port into a special VLAN (the Auth-fail VLAN) or be fall back to MAB and download a dACL to permit some basic access.
Before transitioning to Closed Mode, you should ensure that all endpoints can authenticate. All identity store database should be up to date and online.
Building on top of the configurations done in Monitor Mode, a few changes can be made in the network for restricted network access. The idea is that after you have understood how endpoints behave in the monitor mode and how to fix failures, you are ready to move on to understanding controlled network access.
Figure22: Closed Authentication Workflow
c9300-Sw(config)#template PORT-AUTH-TEMPLATE c9300-Sw(config-if)#access-session closed
In closed mode, the endpoints do not have network access unless they authenticate successfully or are given fail open access because of ISE authorization policy. What if the ISE server itself is unreachable? The best practice recommendation is therefore, to configure the fail open access locally on the switch.
Use the Inaccessible Authentication Bypass (IAB) feature, also referred to as critical authentication or the AAA fail policy, when the switch cannot reach the configured RADIUS servers and new hosts cannot be authenticated. When a new host tries to connect to the critical port, that host is moved to a user-specified access VLAN, the critical VLAN. The critical VLAN can be the same as the default VLAN on the port. The administrator gives limited authentication to the hosts.
Enable the critical voice VLAN feature to allow access to IP phones when the ISE server is unreachable for its authentication. When traffic coming from the host is tagged with the voice VLAN, the connected device (the phone) is put in the configured voice VLAN for the port. The IP phones learn the voice VLAN identification through CDP (Cisco devices) or through LLDP or DHCP.
c9300-Sw(config)#service-template CRITICAL_AUTH_ACCESS c9300-Sw(config-service-template)#vlan 100 c9300-Sw(config)#service-template DEFAULT_CRITICAL_VOICE_TEMPLATE c9300-Sw(config-service-template)#voice vlan
Note: To support inaccessible bypass on multiple-authentication (multi-auth) ports, use the authentication event server dead action reinitialize vlan VLAN ID. When a new host tries to connect to the critical port, that port is reinitialized and all the connected hosts are moved to the user-specified access VLAN. The authentication event server dead action reinitialize vlan <vlan-id> interface configuration command is supported on all host modes |
To reinitialize a session when a previously unreachable ISE server becomes available, use the below configuration
c9300-Sw(config)#class-map type control subscriber match-any IN_CRITICAL_AUTH c9300-Sw(config-filter-control-classmap)#match activated-service-template CRITICAL_AUTH_ACCESS c9300-Sw(config-filter-control-classmap)#match activated-service-temp DEFAULT_CRITICAL_VOICE_TEMPLATE c9300-Sw(config-filter-control-classmap)#exit c9300-Sw(config)# c9300-Sw(config)#class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH c9300-Sw(config-filter-control-classmap)#match activated-service-template CRITICAL_AUTH_ACCESS c9300-Sw(config-filter-control-classmap)#match activated-service-temp DEFAULT_CRITICAL_VOICE_TEMPLATE c9300-Sw(config-filter-control-classmap)#exit
class-map type control subscriber match-all AAA_SVR_DOWN_AUTHD_HOST match result-type aaa-timeout match authorization-status authorized ! class-map type control subscriber match-all AAA_SVR_DOWN_UNAUTHD_HOST match result-type aaa-timeout match authorization-status unauthorized ! class-map type control subscriber match-all DOT1X match method dot1x ! class-map type control subscriber match-all DOT1X_FAILED match method dot1x match result-type method dot1x authoritative ! class-map type control subscriber match-all DOT1X_MEDIUM_PRIO match authorizing-method-priority gt 20 ! class-map type control subscriber match-all DOT1X_NO_RESP match method dot1x match result-type method dot1x agent-not-found ! class-map type control subscriber match-all DOT1X_TIMEOUT match method dot1x match result-type method dot1x method-timeout ! class-map type control subscriber match-any IN_CRITICAL_AUTH match activated-service-template CRITICAL_AUTH_ACCESS match activated-service-template DEFAULT_CRITICAL_VOICE_TEMPLATE ! class-map type control subscriber match-all MAB match method mab ! class-map type control subscriber match-all MAB_FAILED match method mab match result-type method mab authoritative ! class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH match activated-service-template CRITICAL_AUTH_ACCESS match activated-service-template DEFAULT_CRITICAL_VOICE_TEMPLATE !
policy-map type control subscriber PORT-AUTH-POLICY-I event session-started match-all 10 class always do-until-failure 10 authenticate using dot1x priority 10 event authentication-failure match-first 5 class DOT1X_FAILED do-until-failure 10 terminate dot1x 20 authenticate using mab priority 20 10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure 10 clear-authenticated-data-hosts-on-port 20 activate service-template CRITICAL_AUTH_ACCESS 30 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE 40 authorize 50 pause reauthentication 20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure 10 pause reauthentication 20 authorize 30 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 authenticate using mab priority 20 40 class MAB_FAILED do-until-failure 10 terminate mab 20 authentication-restart 60 60 class always do-until-failure 10 terminate dot1x 20 terminate mab 30 authentication-restart 60 event agent-found match-all 10 class always do-until-failure 10 terminate mab 20 authenticate using dot1x priority 10 event aaa-available match-all 10 class IN_CRITICAL_AUTH do-until-failure 10 clear-session 20 class NOT_IN_CRITICAL_AUTH do-until-failure 10 resume reauthentication event inactivity-timeout match-all 10 class always do-until-failure 10 clear-session event authentication-success match-all 10 class always do-until-failure 10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE
The IEEE 802.1x standard is implemented to block traffic between the unauthenticated clients and network resources. This means that unauthenticated clients cannot communicate with any device on the network except the authenticator. The reverse is true, except for one circumstance, when the port is configured as a unidirectional controlled port.
Unidirectional State
The IEEE 802.1x standard states that a unidirectional controlled port enables a device on the network to wake up a client so that the client continues to be reauthenticated. When you use the authentication control-direction in command to configure the port as unidirectional, the port changes to the spanning-tree forwarding state, thus allowing a device on the network to wake the client and force it to reauthenticate.
Bidirectional State
When you use the authentication control-direction both command to configure a port as bidirectional, access to the port is controlled in both directions. In this state, the port does not receive or send packets.
(Optional) Allows broadcast traffic from the network to the unauthenticated port. This assists with the Wake-on-LAN (WoL)) process so that the network management server can wake up clients on demand. It also assists in the MAB process for certain types of devices that do not generate much traffic on their own without network request from another host.
c9300-Sw(config)#template PORT-AUTH-TEMPLATE c9300-Sw(config-if)#access-session control-direction in
Limiting the number of MAC addresses on an 802.1X-enabled port is not a straightforward process. However, there are a couple of options to achieve MAC limits to a certain extent:
Host Mode | Number of Endpoints | Interface Command |
Single Host (default in IBNS 1.0) |
1 Voice/Data device | access-session host-mode single-host |
Multi-Domain Authentication (MDA) | 1 Voice and 1 Data device | access-session host-mode multi-domain |
Multi-Host Mode | 1 Voice and Unlimited Data
(At least one MAC address must authenticate successfully) |
access-session host-mode multi-host |
Multi-Auth Mode | 1 Voice and Unlimited Data
(Each MAC address must authenticate) |
access-session host-mode multi-auth |
Table8: Multiple Endpoints per Port
When you opt for restrictive host modes such as single-host mode or multi-domain authentication host mode, and an authentication violation occurs, for example, more MAC addresses appearing on the same port, the port will be error disabled. This might require the immediate attention of the administrator to remediate the shutdown port state. We, therefore, recommended that you have a restrictive, yet non-disruptive option to handle authentication violations using below IBNS 2.0 CLI.
policy-map type control subscriber PORT-AUTH-POLICY-I event session-started match-all 10 class always do-until-failure 10 authenticate using dot1x priority 10 event authentication-failure match-first 5 class DOT1X_FAILED do-until-failure 10 terminate dot1x 20 authenticate using mab priority 20 10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure 10 clear-authenticated-data-hosts-on-port 20 activate service-template CRITICAL_AUTH_ACCESS 30 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE 40 authorize 50 pause reauthentication 20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure 10 pause reauthentication 20 authorize 30 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 authenticate using mab priority 20 40 class MAB_FAILED do-until-failure 10 terminate mab 20 authentication-restart 60 60 class always do-until-failure 10 terminate dot1x 20 terminate mab 30 authentication-restart 60 event agent-found match-all 10 class always do-until-failure 10 terminate mab 20 authenticate using dot1x priority 10 event aaa-available match-all 10 class IN_CRITICAL_AUTH do-until-failure 10 clear-session 20 class NOT_IN_CRITICAL_AUTH do-until-failure 10 resume reauthentication event inactivity-timeout match-all 10 class always do-until-failure 10 clear-session event authentication-success match-all 10 class always do-until-failure 10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE event violation match-all 10 class always do-until-failure 10 restrict
c9300-Sw(config)#device-tracking policy IPDT_POLICY c9300-Sw(config-device-tracking)#no protocol udp c9300-Sw(config-device-tracking)#tracking enable c9300-Sw(config-device-tracking)#limit address-count 10 c9300-Sw(config-device-tracking)#exit ! c9300-Sw(config)#interface gigabitEthernet 1/0/1 c9300-Sw(config-if)#device-tracking attach-policy IPDT_POLICY
Note: Even though the port-security interface command enforces MAC address limit, it is not compatible with the authentication/dot1x configurations on the switch port. In general, we recommend that you do not enable port security when IEEE 802.1x is enabled. |
c9300-Sw(config)#template PORT-AUTH-TEMPLATE c9300-Sw(config-template)#no service-policy type control subscriber PORT-AUTH-POLICY c9300-Sw(config-template)#service-policy type control subscriber PORT-AUTH-POLICY-I
c9300-Sw#show derived-config interface GigabitEthernet 1/0/1 Building configuration... Derived configuration : 525 bytes ! interface GigabitEthernet1/0/1 description ** Endpoints and Users ** switchport access vlan 100 switchport mode access switchport voice vlan 101 device-tracking attach-policy IPDT_POLICY authentication periodic authentication timer reauthenticate server access-session control-direction in access-session closed access-session port-control auto mab dot1x pae authenticator dot1x timeout tx-period 7 dot1x max-reauth-req 3 spanning-tree portfast service-policy type control subscriber PORT-AUTH-POLICY-I end
It is always important to have policy goals in mind before configuring ISE access policies. Figure21 highlights 802.1X authentication workflow, resulting in either basic access or access to an employee segment depending on a user’s Active Directory group membership. IP phones are authorized for voice VLAN and the unknown endpoints are subject to the guest portal. When the ISE servers are unreachable, the switch authorizes newly connecting endpoints to the critical VLAN, which can be the same as the default VLAN. The following is a flow chart of the 802.1x authentication policy, most part of the decision tree and critical authorization is already configured on the switch, the right-hand side part in terms of 802.1X and MAB authorization policies must be configured on ISE:
Figure23: 802.1x Authentication flowchart
Note: The VLAN name or number that you specify in the Authorization Profile must match the VLAN name or number configured on the access switch exactly. In this example, a VLAN exists on the switch name Employees:
c9300-Sw#show vlan brief | inc Employee 150 Employees active |
Note: If you click Save (Conditions Studio > Editor) after you configure a condition, you can save this condition with an arbitrary name and reuse the condition with that name later for other authorization policies.
|
Note that for IP phones, a policy rule exists by default. This rule authorizes profiled IP phones with voice VLAN authorization. Pre-requisites being the IP Phone MAC address are manually added to the endpoint identity group.
Note: Both Cisco_IP_Phones and Non_Cisco_IP_Phones authorization profiles contain a PERMIT_ALL_TRAFFIC (permit ip any any) downloadable ACL and cisco-av-pair=device-traffic-class=voice authorization. The latter Attribute Value Pair (AVP) is necessary to tag the IP phone into voice VLAN on the switch.
|
1. Log in to a Catalyst switch and test AAA authentication using “Test aaa group radius” CLI .
2. Ensure that the corresponding Active Directory user (a member of the Employee group) is returned with VLAN authorization.
c9300-Sw#test aaa group radius harry ISEisC00L new-code User successfully authenticated USER ATTRIBUTES username 0 "harry" tunnel-type 1 13 [vlan] tunnel-medium-type 1 6 [ALL_802] tunnel-private-group 1 "Employees" security-group-tag 0 "0004-0"
3. If you bounce the access port in which the corresponding IP phone and employee are connected, the new authorization results should be displayed as below.
c9300-Sw#show access-sesison sessions interface Gi 1/0/1 details Interface: GigabitEthernet1/0/1 IIF-ID: 0x19E63EED MAC Address: 0050.56a7.fa8a IPv6 Address: Unknown IPv4 Address: 172.20.150.2 User-Name: harry Status: Authorized Domain: DATA Oper host mode: multi-auth Oper control dir: in Session timeout: N/A Common Session ID: 65FE14AC0000002D27DEB90F Acct Session ID: 0x00000023 Handle: 0xd0000023 Current Policy: PORT-AUTH-POLICY-I Local Policies: Idle timeout: 65536 sec Server Policies: Vlan Group: Vlan: 150 Security Policy: None Security Status: Link Unsecured SGT Value: 4 Method status list: Method State dot1x Authc Success ---------------------------------------- Interface: GigabitEthernet1/0/1 IIF-ID: 0x1AABEBEF MAC Address: 0064.40b5.794e IPv6 Address: Unknown IPv4 Address: 172.20.101.3 User-Name: 00-64-40-B5-79-4E Status: Authorized Domain: VOICE Oper host mode: multi-auth Oper control dir: in Session timeout: N/A Common Session ID: 65FE14AC0000002E27DEBD9D Acct Session ID: 0x00000024 Handle: 0xf7000024 Current Policy: PORT-AUTH-POLICY-I Local Policies: Idle timeout: 65536 sec Server Policies: ACS ACL: xACSACLx-IP-PERMIT_ALL_TRAFFIC-57f6b0d3 Method status list: Method State dot1x Stopped mab Authc Success
4. Log in to ISE and navigate to Operations > RADIUS: Live Logs.
You will notice two endpoints being authenticated and authorized.
5. Click the Details icon to view details about the entry.
The Overview dialog box shown below highlights the authorization policy rule matched and what the end result .
6. If you scroll down to the end of the page, you will see the Result details with License consumed.
With Multi-Domain Authentication enabled, both the phone and device behind the phone can authenticate using dot1x. Phones use similar protocols and authenticate using the same type of credentials as other users and devices that perform 802.1X. However, there are some specific requirements for preparing the voice network for authentication of IP phones. These phones must present a password or X.509 digital certificate to authenticate successfully. IP phones use EAP-MD5 for password authentication. This is considered weak when compared to other password- based EAP methods such as Protected EAP (PEAP) or EAP Flexible Authentication via Secure Tunneling (EAP-FAST). Most Cisco IP phones support authentication via X.509 certificates using the EAP-Transport Layer Security (EAP-TLS) or EAP-FAST methods.
Cisco IP phones support two types of X.509 certificates: the Manufacturing Installed Certificates (MICs) and the Locally Significant Certificates (LSCs).
As the name indicates, MICs are the certificates that are preinstalled on IP phones and cannot be deleted or modified by administrators. The certification pre-installed on the phones are signed by one of the Cisco Manufacturing Certificate Authorities. When an IP phone authenticates using MIC, it proves that it is a valid Cisco IP phone; however, it does not validate if the phone is a company-owned asset. Anyone can connect a personal device that has a Cisco Manufacturing CA-signed certificate on it and gain network access.
LSCs on the other hand are administrator installed certificates that are signed by the Cisco Unified Call Manager. These certificates serve the same purpose as MICs in terms of authentication, but provide greater security because of their local significance to a given environment.
The following section covers Cisco IP phone authentication using digital certificates
Click Find,the CUCM server loads.
For information about the procedure, see the Configuring Windows 2000 DHCP Server for Cisco CallManager document.
Note: The phone’s status must show Registered with CUCM for the administrator to manage the phone from the Call Manager. If the status is something else, try Hard Reset the phone to Registered back to CUCM. |
After the IP phone is registered with the Call Manager, necessary changes can be performed in the system to enable 802.1X authentication. For MIC based 802.1X authentication, the relevant manufacturer CA certificates must be trusted in ISE and the IP phones must be configured via CUCM to perform 802.1X authentication using MICs.
This section provides information about how to configure the voice network for MIC authentication and the changes that are required in ISE to support it.
1. Log in to the Cisco Unified OS Administration window using with admin credentials.
2. Navigate to Security > Certificate Management.
3. Click each of the CA certificates listed as CallManager-trust and export them to your local disk in PEM format. Note that the last three certificates need not be exported because they are installed by default in Cisco ISE’s trusted CA store. However, make sure that those certificates exist on ISE.
4. Log in to ISE and Navigate to Administration > System > Certificates.
5. In the left pane, click Trusted Certificates. You will see a list of Root CA public certificates that are installed on ISE. Notice the three Cisco Manufacturer certificates you could see in CUCM as in Step 3.
6. Select the disabled ones and click Edit to change the Status to Enabled and Click Save
7. Enable the other Disabled CA certificates .
8. To import the other root CA certificates that are exported from CUCM, click Import in the Trusted Certificates area.
9. Upload the CA certificate, give it a name and description, and save it with default settings.
10. If the certificate has weaker key strength or an outdated algorithm, a warning message is shown. If it is permissible in the given environment to use such certificates, click Yes and proceed.
11. Repeat the certificate import procedure for all the exported certificates.
12. Navigate to the corresponding ISE authorization policy and create a new authorization rule for IP phones with certificates.
13. Click the + button for conditions and in the condition Editor window, click the field that states Click to add an attribute and Click the user icon and Select CERTIFICATE Subject – Common Name.
14. Define a condition to match such that CERTIFICATE Subject – Common Name contains SEP.
15. Click the New button to add another condition to match CERTIFICATE Issuer – Organization
16. Define the second condition to match such that CERTIFICATE Issuer – Organization contains Cisco
17. Click Use When the conditions matches the snapshot provide below.
18. Add the voice permission that has Voice Domain Permission(Select the Results Profiles with dACL_Voice in this procedure) and save the configurations.
19. Log in to CUCM and navigate to Device > Phone
20. Use the Find field to locate a specific registered phone and click a name from the list that is displayed under Device Name (Line)
21. Use the Find field to locate a specific registered phone and click a name from the list that is displayed under Device Name (Line)
22. Scroll down the Product Specific Configuration Layout until you see 802.1x Authentication. Enable it,
click Save, and then click Apply Config at the top of the window
23. The IP phone in the network should now authenticate 802.1x. If you log in to the switch, you can see the session information.
c9300-Sw#show access-session Interface MAC Address Method Domain Status Fg Session ID -------------------------------------------------------------------------------------------- Gi1/0/1 0064.40b5.794e dot1x VOICE Auth 000000000000005A4656E5C5 Gi1/0/1 0050.56a7.fa8a dot1x DATA Auth 00000000000000594656E2C5 <Output trunckated>
24. The session details display additional information about the phone’s network access session:
c9300-Sw#show access-session mac 0064.40b5.794e details Interface: GigabitEthernet1/0/1 IIF-ID: 0x15656B9D MAC Address: 0064.40b5.794e IPv6 Address: Unknown IPv4 Address: 172.20.101.3 User-Name: CP-9971-SEP006440b5794e Status: Authorized Domain: VOICE Oper host mode: multi-auth Oper control dir: in Session timeout: N/A Common Session ID: 000000000000005A4656E5C5 Acct Session ID: 0x00000050 Handle: 0x41000050 Current Policy: PORT-AUTH-POLICY-I Server Policies: ACS ACL: xACSACLx-IP-VoiceACL-5af16326 Security Policy: None Security Status: Link Unsecured Method status list: Method State dot1x Authc Success mab Stopped
25. To view the new session status on ISE, Navigate to Operations > RADIUS > Live Logs
26. Click on the Details Icon to see that the IP phone is 802.1X authenticated and is authorized with a dACL
27. Scroll further down the page to view the certificate details.
Note: To enable 802.1X across all the IP phones, specific models or locations, use the Bulk Administration option in CUCM.
|
You do not require MIC to be configured in the voice network, IP Phones can be authenticated with LSC. However, since MIC is quick and is an easy option to enable authenticated network access to phones, most enterprises tend to start with MIC and move to LSC. This section explains how to build on the previous configurations to install LSC on IP phones and authenticate them.
Certificate Authority Proxy Function (CAPF) Service Enablement
28. Log in to the Cisco Unified Serviceability tool with admin credentials.
29. Navigate to Tools > Service Activation.
30. Activate the Cisco Certificate Authority Proxy Function service.
31. After the CAPF service is enabled, restart the TFTP service so that the IP phones can download the LSCs. To restart, navigate to Tools > Control Center Feature Services.
32. Click the Cisco Tftp service radio button.
33. Click Restart to reinitialize the TFTP service.
34. Log in to the Cisco Unified OS Administration tool with admin credentials
35. After log in, navigate to Security > Certificate Management.
36. Export the CAPF Root CA certificate to your local system. (The certificate title has only CAPF in it.)
37. Log in to ISE and Navigate to Administration > System > Certificates > Trusted Certificates.
38. In the left pane, navigate to Certificate Management > Trusted Certificates, and click Import.
39. Import the CAPF Root CA certificate with default settings.
40. After the certificate is installed, select it by checking the corresponding check box, and click View.
41. The certificate is locally signed by the CUCM and the organization name with your specific company name. Make a note of the organization name and close the certificate view window.
42. Modify the ISE authorization policy to authenticate IP phones on an LSC instead of an MIC.
43. Log in to the CUCM Administration window with admin credentials
44. Navigate to Device > Phone.
45. Use the Find field to locate a specific phone or click the corresponding phone name under Device Name (Line)
46. In the CAPF Information section, from the Certificate Operation drop-down list, choose Install/Upgrade.
From the Authentication Mode drop-down list, choose one of the following options depending on the settings in your environment. In this procedure, the By Null String option is used.
Option |
Description |
By Authentication String |
Installs LSC with a passcode that needs to be keyed in locally in the IP phone. |
By Null String |
Installs LSC without authentication. |
By Existing Certificate (precedence to LSC) |
Useful when a new LSC needs to be installed on an IP phone that already has preinstalled LSCs. |
By Existing Certificate (precedence to MIC) |
Authenticates the IP phone with MIC to install an LSC. |
47. Click Save and then Apply Config for the changes to take effect.
48. Navigate to Device > Phone, locate the IP phones, and then click the + button.
49. Define a new condition to list phone on LSC issued By option from the newly created search filter and then click Find. If the LSC installation is in progress, you will see that the LSC Status is Operation Pending.
50. Upon upgrade completion, LSC Status changes from Operation Pending to Upgrade Success .
Note: To deploy LSC at scale, use the Bulk Administration option in CUCM. |
Most of the enterprise customers are using 802.1x based admission control for securing the network. Majority of these deployments were focused on implementing user-based admission control to authenticate the users before they gain network access where a PC or IP-phone acts as a supplicant and the switch acts an authenticator. However, there is also a need to implement device-based admission control for tighter security because there are deployment scenarios where a switch acting as 802.1X authenticator is placed in an unsecured location. For example, compact switch placed outside wiring closet can potentially be swapped with hacker devices to gain access to the network, compromising network security. This creates a requirement whereby an edge switch (Supplicant) is required to authenticate itself against upstream switch (Authenticator).
Network Edge Authentication Topology (NEAT) offers secure extension of the Layer 2 network beyond the wiring closet. It ensures that a supplicant switch (compact switch outside the wiring closet) is allowed access to the network only if it authenticates successfully. For more information on the NEAT click here. This document covers the NEAT configurations with IOS Interface-templates.
Figure24: NEAT Network Topology
NEAT feature enables extended secure access in areas outside the wiring closet (such as conference rooms). 802.1x supplicant switch acts as a supplicant to another switch by using the 802.1X supplicant feature for secure connectivity. Once the supplicant switch authenticates successfully, RADIUS servers sends down Cisco AV Pair attributes along with ACCESS-ACCEPT to the Authenticator switch.
The following scenario with the Topology above depicts an overview of typical solution: -
As explained before, when a Supplicant Switch successfully authenticates, the RADIUS Server sends down Cisco AV Pair “device-traffic-along with ACCESSACCEPT to the Authenticator switch. The authenticator switch then changes the port configuration from access to “trunk-mode” with the help of a built-in macro.
The current macro based NEAT solution has two limitations:
The solution to this problem is to use the interface-templates instead of macros for port configuration related changes.
Interface template is a port configuration container that can be applied to a specific interface or a user’s network access session. Almost all the interface specific commands can be configured under the “template” and then either manually applied on the port (with “source template” interface command) or can be applied dynamically on the port, based on either device discovery (AutoConf, similar to AutoSmartPorts) or via RADIUS authorization. One of the major advantages of interface templates is that the running-configuration will have a fixed configuration, where the interface specific (active) configuration will be placed under a separate runtime memory. The configuration that is currently applied on a physical interface can be seen with the “show derived-config interface <interface>” exec command. Interface templates are supported from Cisco IOS 15.2(2)E / XE 03.06.00E.
Particulars | NEAT with Macros | NEAT with Interface Template |
Supplicant EAP Methods | All methods (MD5, PEAP, EAP-TLS) | All methods (MD5, PEAP, EAP-TLS) |
CISP for MAC notification | Yes | Yes |
Cisco AVP | device-traffic-class=switch | interface-template-name=<name> |
Supplicant switch authorization modifies running-config on ASw | Yes | No |
Modifying post-authc interface configuration | With additional ASP Macro | Modify the original authorization template referenced by ISE |
Table9: Macro Neat and Neat with Interface Template Comparison
1. Log in to Authenticator and Supplicant switch and execute/verify the below basic authentication, authorization and accounting (AAA) configurations.
aaa new-model aaa session-id common ! radius server ISE01 address ipv4 172.20.254.21 auth-port 1812 acct-port 1813 automate-tester username test-user ignore-acct-port probe-on key ISEisC00L ! radius server ISE02 address ipv4 172.20.254.22 auth-port 1812 acct-port 1813 automate-tester username test-user ignore-acct-port probe-on key ISEisC00L ! dot1x system-auth-control dot1x critical eapol ! radius-server attribute 6 on-for-login-auth radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include radius-server attribute 31 mac format ietf upper-case radius-server attribute 31 send nas-port-detail mac-only radius-server dead-criteria time 10 tries 3 radius-server deadtime 15 ! aaa group server radius ISE server name ISE01 server name ISE02 ip radius source-interface Vlan254 ! aaa authentication dot1x default group ISE aaa authorization network default group ISE aaa accounting Identity default start-stop group ISE aaa accounting update newinfo periodic 2880 ! aaa server radius dynamic-author client 172.20.254.21 server-key ISEisC00L client 172.20.254.22 server-key ISEisC00L! ! crypto key generate rsa general-keys mod 2048
2. Enable CISP Framework.
c9300-Sw(config)#cisp enable
The Client Information Signaling Protocol (CISP) is a layer 2 control plane protocol used to transport the MAC addresses of the hosts (both authenticated MAC and MAC learnt by normal learning) from a Supplicant Switch to an Authenticator Switch. CISP uses CDP address (Cisco Reserved Multicast Address) as a destination MAC Address and frames are generated only by Supplicant Switch to which Authenticator switches acts as a responder to the received frames.
3. Configure downlink port as access port with dot1x authentication
interface GigabitEthernet1/0/1 description ** Downlink to supplicant switch ** switchport mode access switchport access vlan 254 device-tracking attach-policy IPDT_POLICY access-session port-control auto dot1x pae authenticator spanning-tree portfast trunk spanning-tree bpduguard disable service-policy type control subscriber PORT-AUTH-POLICY-I
4. Configure interface-template which can be referenced later by ISE as part of the authorization policy.
template neat-authz switchport trunk native vlan 254 switchport mode trunk
The subsequent sections describe details of the configurations required for performing NEAT on Supplicant Switch.
5. Enable 802.1X globally on the switch to authenticate device connected, use the dot1x system-auth-control command in global configuration mode.
c9300-Sw(config)#dot1x system-auth-control
6. Configure switch to force sending only multicast EAPOL packets when it receives either unicast or multicast packets, which allows NEAT to work on the supplicant switch in all host modes & enable CISP framework globally.
c9300-Sw(config)#dot1x supplicant force-multicast c9300-Sw(config)#cisp enable
7. Configure EAP mode & credentials used by supplicant switch to authenticate itself to authenticator switch.
Note: In this configuration example EAP-MD5 is used as the EAP method between the supplicant switch and ISE. However NEAT supplicants support many other EAP methods. “show eap registrations” EXEC command tells the EAP support on the supplicant switch
c3560CX-Sw(config)#eap profile eap-md5 c3560CX-Sw(config-eap-profile)# description PEAP-MD5 Supplicant c3560CX-Sw(config-eap-profile)# method md5 c3560CX-Sw(config)#dot1x credentials eap-md5-cred c3560CX-Sw(config-dot1x-creden)# username ssw01 c3560CX-Sw(config-dot1x-creden)# password 0 cisco@123 c3560CX-Sw(config-dot1x-creden)# anonymous-id ssw01
8. The connection of the supplicant to the authenticator is already configured to be a trunk port (in contrast to access port configuration on the authenticator). At this stage, this is expected; configuration on the authenticator will dynamically change when the ISE returns the correct attribute
c3560CX-Sw(config)#interface TenGigabitEthernet1/0/8 c3560CX-Sw(config-if) description ** Upstream Authenticator switch ** c3560CX-Sw(config-if) switchport trunk native vlan 254 c3560CX-Sw(config-if) switchport mode trunk c3560CX-Sw(config-if) dot1x pae supplicant c3560CX-Sw(config-if) dot1x credentials eap-md5-cred c3560CX-Sw(config-if) dot1x supplicant eap profile eap-md5 c3560CX-Sw(config-if) spanning-tree portfast edge | configure the downlink port that connects to the endpoints.. c3560CX-Sw(config)#interface GigabitEthernet1/0/1 c3560CX-Sw(config-if) switchport access vlan 100 c3560CX-Sw(config-if) switchport mode access c3560CX-Sw(config-if) switchport voice vlan 101 c3560CX-Sw(config-if) authentication periodic c3560CX-Sw(config-if) authentication timer reauthenticate server c3560CX-Sw(config-if) access-session host-mode single-host c3560CX-Sw(config-if) access-session port-control auto c3560CX-Sw(config-if) mab c3560CX-Sw(config-if) dot1x pae authenticator c3560CX-Sw(config-if) dot1x timeout tx-period 7 c3560CX-Sw(config-if) dot1x max-reauth-req 3 c3560CX-Sw(config-if) spanning-tree portfast edge c3560CX-Sw(config-if) service-policy type control subscriber POLICY_Gi1/0/1
ISE needs to be configured with the user identity and policies to authenticate and authorize the NEAT supplicant. Follow these steps:
9. Add Supplicant Switch to the appropriate group. Navigate to Administration > Network Resources > Network Devices, and click Add.
10. Create NEAT Switch User Account and add the user to NeatSupplicants group. Navigate to Administration > Identity Management > identities, and click Add.
11. Enable the required authentication protocols. Navigate to Policy > Results > Authentication > Allowed protocols, select the protocol service list used by wired dot1x, and ensure the protocols in this step are enabled.
12. Create a new Authorization Profile and reference the interface-template. Navigate to Policy > Policy Elements > Results > Authorization Profiles and click Add
Note: On ISE, one major difference between traditional NEAT and “NEAT with Interface-template” configuration, is that the authorization profile for the former is Cisco AVP “device-traffic-whereas for the later it is “interface-template-name=<name>”.
13. Navigate to the Policy > Policy Sets >Authorization Policy page and add new policies as showing below and save the configuration.
Use this section to confirm that your configuration works properly. This section describes two behaviors:
Once authentication and authorization succeed, the CISP exchange occurs. Each exchange has a REQUEST, which is sent by the supplicant, and a RESPONSE, which serves as a reply and acknowledgment from the authenticator.
Two distinct exchanges are performed: REGISTRATION and ADD_CLIENT. During the REGISTRATION exchange, the supplicant informs the authenticator that it is CISP-capable, and the authenticator then acknowledges this message. The ADD_CLIENT exchange is used to inform the authenticator about devices connected to the supplicant's local port. As with REGISTRATION, ADD-CLIENT is initiated on the supplicant and acknowledged by the authenticator.
In this example, the supplicant authenticates to the authenticator. The steps in the process are
Communication from the supplicant 2018/12/01 01:09:26.873 {smd_R0-0}{1}: [epm-tunnel] [22503]: UUID: 0, ra: 0, TID: 0 (ERR): Linksec failure but policy is not must-secure. So return SUCCESS 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS/DECODE: parse unknown cisco vsa "profile-name=Unknown" - IGNORE 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius-authen] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS(00000000): Received from id 1812/184 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS:rad_code 2, suppress reject flag 0 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Cisco AVpair [1] 22 "profile-name=Unknown" 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Vendor, Cisco [26] 28 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Cisco AVpair [1] 36 "interface-template-name=neat-authz" 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Vendor, Cisco [26] 42 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Message-Authenticator[80] 18 RADIUS: 00 46 b6 01 a1 60 74 8a 1f 9c 12 f7 35 65 ed 09 [ F`t5e] 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Message-Authenticator[80] 18 ... 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: EAP-Message [79] 6 RADIUS: 03 52 00 04 [ R] 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: EAP-Message [79] 6 ... 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: 37 33 39 [ 739] 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: 65 2d 31 2f 33 32 39 32 34 30 31 38 32 2f 38 34 [e-1/329240182/84] 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: 30 30 31 33 31 36 37 34 46 42 37 36 38 3a 69 73 [00131674FB768:is] 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Class [25] 53 RADIUS: 43 41 43 53 3a 30 35 30 32 41 38 43 30 30 30 30 [CACS:0502A8C0000] 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Class [25] 53 ... 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: 34 46 42 37 36 38 [ 4FB768] 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: 30 32 41 38 43 30 30 30 30 30 30 31 33 31 36 37 [02A8C00000013167] 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: State [24] 40 RADIUS: 52 65 61 75 74 68 53 65 73 73 69 6f 6e 3a 30 35 [ReauthSession:05] 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: State [24] 40 ... 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: User-Name [1] 7 "ssw01" 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: authenticator b7 67 04 03 56 f9 d9 fa - 0b 03 b5 cf 1b ff 97 43 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Received from id 1812/184 10.1.100.21:0, Access-Accept, len 214 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Started a sec timeout 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS(00000000): Sending a IPv4 Radius Packet 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Calling-Station-Id [31] 19 "2C-AB-EB-A8-4F-88" 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: 31 38 32 2f 38 34 37 33 39 3b [ 182/84739;] 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: 6e 49 44 3d 69 73 65 2d 31 2f 33 32 39 32 34 30 [nID=ise-1/329240^@] 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: 37 34 46 42 37 36 38 3b 33 31 53 65 73 73 69 6f [74FB768;31Sessio^@] 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: 35 30 32 41 38 43 30 30 30 30 30 30 31 33 31 36 [502A8C0000001316^@] 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: State [24] 76 RADIUS: 33 37 43 50 4d 53 65 73 73 69 6f 6e 49 44 3d 30 [37CPMSessionID=0^@] 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: State [24] 76 ... 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: NAS-Port [5] 6 50101 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: NAS-Port-Type [61] 6 Ethernet [15] 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: NAS-Port-Id [87] 25 "TenGigabitEthernet1/0/1" 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: NAS-IP-Address [4] 6 172.16.1.2 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Cisco AVpair [1] 25 "client-iif-id=355993491" 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Vendor, Cisco [26] 31 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Cisco AVpair [1] 14 "method=dot1x" 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Vendor, Cisco [26] 20 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Cisco AVpair [1] 43 "audit-session-id=0502A8C000000131674FB768" 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Vendor, Cisco [26] 49 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: EAP-Key-Name [102] 2 * 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: EAP-Key-Name [102] 2 * 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Message-Authenticator[80] 18 RADIUS: 99 57 5f 79 e9 0a 25 a6 89 fc 5a ad 9b d9 7c 1d [ W_y?Z|] 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Message-Authenticator[80] 18 ... 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: EAP-Message [79] 24 RADIUS: 02 52 00 16 04 10 d1 fa e0 c1 cc b9 67 4b ba 88 bd a1 08 72 a4 db [ RgKr] 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: EAP-Message [79] 24 ... 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Framed-MTU [12] 6 1472 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Cisco AVpair [1] 21 "service-type=Framed" 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Vendor, Cisco [26] 27 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debug): RADIUS: Service-Type [6] 6 Framed [2] 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: User-Name [1] 7 "ssw01" 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: authenticator 9e f3 b4 12 9c 7b a9 b1 - d3 6f b0 4e da 45 bf 43 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info): RADIUS: Send Access-Request to 10.1.100.21:1812 id 1812/184, len 348
In order to verify behavior on the authenticator, enter the below show cisp command:
c9300-Sw#show cisp summary CISP is running on the following interface(s): ---------------------------------------------- Te1/0/1 (Authenticator) c9300-Sw#show cisp interface te1/0/1 CISP Status for interface Te1/0/1 ------------------------------------- Version: 1 Mode: Authenticator Peer Mode: Supplicant Auth State: Idle c9300-Sw#show cisp clients Authenticator Client Table: ------------------------ MAC Address VLAN Interface --------------------------------- 2cab.eba8.4fc2 200 Te1/0/1
In the example above, the role of authenticator is correctly assigned to the correct interface (Te1/0/1) and Vlan 200 MAC address is registered.
Verification of dot1x authentication session indicate Te1/0/1 port already authenticated. This is the dot1x exchange that is triggered where supplicant switch is plugged in.
c9300-Sw#show dot1x interface tenGigabitEthernet 1/0/1 det Dot1x Info for TenGigabitEthernet1/0/1 -------------------------------------------- PAE = AUTHENTICATOR QuietPeriod = 60 ServerTimeout = 0 SuppTimeout = 30 ReAuthMax = 2 MaxReq = 2 TxPeriod = 30 Dot1x Authenticator Client List ------------------------------- EAP Method = MD5 Supplicant = 2cab.eba8.4f88 Session ID = 0502A8C000000133675DCDD3 Auth SM State = AUTHENTICATED Auth BEND SM State = IDLE c9300-Sw#show authentication sessions int te1/0/1 det Interface: TenGigabitEthernet1/0/1 IIF-ID: 0x1AE7F215 MAC Address: 2cab.eba8.4f88 IPv6 Address: Unknown IPv4 Address: Unknown User-Name: ssw01 Device-type: Cisco-Switch Status: Authorized Domain: DATA Oper host mode: multi-auth Oper control dir: both Session timeout: N/A Common Session ID: 0502A8C000000133675DCDD3 Acct Session ID: 0x00000011 Handle: 0xc40000dd Current Policy: PORT-AUTH-POLICY-I Local Policies: Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150) Security Policy: Should Secure Idle timeout: 65536 sec Server Policies: Interface Template: neat-authz c3560CX-Sw#sh int te1/0/8 TenGigabitEthernet1/0/8 is up, line protocol is up (connected) Hardware is Ten Gigabit Ethernet, address is 2cab.eba8.4f88 (bia 2cab.eba8.4f88)
The interface on the authenticator is configured as access port prior to authentication and derived interface configs after supplicant authentication.
c9300-Sw#sh running-config int te1/0/1 Building configuration... Current configuration : 311 bytes ! interface TenGigabitEthernet1/0/1 switchport access vlan 200 switchport mode access device-tracking attach-policy IPDT_POLICY access-session port-control auto dot1x pae authenticator spanning-tree portfast spanning-tree bpduguard disable service-policy type control subscriber PORT-AUTH-POLICY-I end c9300-Sw#sh derived-config int tenGigabitEthernet 1/0/1 Building configuration... Derived configuration : 344 bytes ! interface TenGigabitEthernet1/0/1 switchport access vlan 200 switchport trunk native vlan 200 switchport mode trunk device-tracking attach-policy IPDT_POLICY access-session port-control auto dot1x pae authenticator spanning-tree portfast spanning-tree bpduguard disable service-policy type control subscriber PORT-AUTH-POLICY-I end
In this example, the Windows PC authenticates to the supplicant. The steps in the process are:
Dec 3 21:32:28.187: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/1: Power granted Dec 3 21:32:32.273: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Dec 3 21:32:33.276: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up Dec 3 21:32:33.276: CISP-EVENT (Gi1/0/1): Received action Link UpDown Dec 3 21:32:33.276: CISP-EVENT (Gi1/0/1): Authenticator received event Link UP in state Not Running (no-op) Dec 3 21:32:35.754: CISP-EVENT (Gi1/0/1): Received action Add Client Dec 3 21:32:35.754: CISP-EVENT (Gi1/0/1): Adding client 0050.56a3.9670 (vlan: 100) to supplicant list Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): Supplicant received event Add Client in state Idle Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): Adding client 0050.56a3.9670 (vlan: 100) to the ADD list Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): Adding client 0050.56a3.9670 (vlan: 100) to ADD CLIENT req Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): ADD CLIENT req full Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): Transmitting a CISP Packet Dec 3 21:32:35.754: CISP-TXPAK (Te1/0/8): Code:REQUEST ID:0x60 Length:0x0029 Type:ADD_CLIENT Dec 3 21:32:35.754: Payload: 010011020009005056A396700300050 ... Dec 3 21:32:35.758: CISP-EVENT (Te1/0/8): Started 'retransmit' timer (30s) Dec 3 21:32:35.758: CISP-EVENT: Started CISP tick timer Dec 3 21:32:35.758: CISP-EVENT (Te1/0/8): Supplicant state changed to Request Dec 3 21:32:35.988: CISP-RXPAK (Te1/0/8): Code:RESPONSE ID:0x60 Length:0x0018 Type:ADD_CLIENT Dec 3 21:32:35.988: CISP-EVENT (Te1/0/8): Supplicant received event Receive Packet in state Request Dec 3 21:32:35.988: CISP-EVENT (Te1/0/8): Stopped 'retransmit' timer Dec 3 21:32:35.988: CISP-EVENT (Te1/0/8): All Clients implicitly ACKed Dec 3 21:32:35.988: CISP-EVENT (Te1/0/8): Supplicant state changed to Idle Dec 3 21:32:36.436: CISP-EVENT (Gi1/0/1): Received action Add Client Dec 3 21:32:36.436: CISP-EVENT (Gi1/0/1): Adding client 000e.d72e.460b (vlan: 101) to supplicant list Dec 3 21:32:36.436: CISP-EVENT (Te1/0/8): Supplicant received event Add Client in state Idle Dec 3 21:32:36.436: CISP-EVENT (Te1/0/8): Adding client 000e.d72e.460b (vlan: 101) to the ADD list Dec 3 21:32:36.436: CISP-EVENT (Te1/0/8): Adding client 000e.d72e.460b (vlan: 101) to ADD CLIENT req Dec 3 21:32:36.436: CISP-EVENT (Te1/0/8): ADD CLIENT req full Dec 3 21:32:36.439: CISP-EVENT (Te1/0/8): Transmitting a CISP Packet Dec 3 21:32:36.439: CISP-TXPAK (Te1/0/8): Code:REQUEST ID:0x61 Length:0x0029 Type:ADD_CLIENT Dec 3 21:32:36.439: Payload: 010011020009000ED72E460B0300050 ... Dec 3 21:32:36.439: CISP-EVENT (Te1/0/8): Started 'retransmit' timer (30s) Dec 3 21:32:36.439: CISP-EVENT: Started CISP tick timer Dec 3 21:32:36.439: CISP-EVENT (Te1/0/8): Supplicant state changed to Request Dec 3 21:32:36.988: CISP-RXPAK (Te1/0/8): Code:RESPONSE ID:0x61 Length:0x0018 Type:ADD_CLIENT Dec 3 21:32:36.988: CISP-EVENT (Te1/0/8): Supplicant received event Receive Packet in state Request Dec 3 21:32:36.988: CISP-EVENT (Te1/0/8): Stopped 'retransmit' timer Dec 3 21:32:36.988: CISP-EVENT (Te1/0/8): All Clients implicitly ACKed Dec 3 21:32:36.988: CISP-EVENT (Te1/0/8): Supplicant state changed to Idle
An ADD_CLIENT exchange occurs, but no REGISTRATION exchange is needed. In order to verify behavior on the supplicant, enter the show cisp registrations command:
c3560CX-Sw#show cisp registrations Interface(s) with CISP registered user(s): ------------------------------------------ Gi1/0/1 Auth Mgr (Authenticator) Te1/0/8 802.1x Sup (Supplicant) c9300-Sw#show cisp clients Authenticator Client Table: ------------------------ MAC Address VLAN Interface --------------------------------- 2cab.eba8.4fc2 200 Te1/0/1 000e.d72e.460b 101 Te1/0/1 0050.56a3.9670 100 Te1/0/1 c3560CX-Sw#show access-session int g1/0/1 Interface MAC Address Method Domain Status Fg Session ID ---------------------------------------------------------------------- Gi1/0/1 0050.56a3.9670 dot1x DATA Auth AC11010200000072161463FF c3560CX-Sw#show access-session int g1/0/1 details Interface: GigabitEthernet1/0/1 MAC Address: 0050.56a3.9670 IPv6 Address: Unknown IPv4 Address: 10.100.100.8 User-Name: Bob Device-type: VMWare-Device Status: Authorized Domain: DATA Oper host mode: single-host Oper control dir: both Session timeout: N/A Restart timeout: N/A Periodic Acct timeout: 172800s (local), Remaining: 172226s Common Session ID: AC11010200000072161463FF Acct Session ID: 0x00000043 Handle: 0xDB00004A Current Policy: POLICY_Gi1/0/1 Local Policies: Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150) Security Policy: Should Secure Security Status: Link Unsecure Server Policies: Vlan Group: Vlan: 100 SGT Value: 4 Method status list: Method State dot1x Authc Success mab Stopped
Log in to ISE web User Interface (UI) and navigate to Operations > RADIUS > Live Logs.
The Operate section provides a comprehensive identity solution for all Cisco ISE run-time services. The Monitoring component provides a real-time presentation of meaningful data representing the state of access activities on a network. The Troubleshooting component provides contextual guidance for resolving access issues on networks.
The monitoring component on ISE describes how to use the RADIUS Live Log to view all the RADIUS authentication logs and how to get details about a specific entry in the log table. This section covers some important operations that can be performed under RADIUS live sessions.
1. Log in to ISE.
2. Navigate to Operations > RADIUS > Live Sessions.
All the active sessions on the network which are controlled by ISE are displayed.
3. Click the Target icon next to Show CoA Actions to view a list of CoA actions that can be performed on a specific endpoint. For information about the list of CoA actions ,refer to Change Authorization for Radius Sessions
4. Click Gear icon to understand the license information of a live session.
5. Check the License Type and License Details check boxes, and click Go.
License information about the sessions are displayed when you scroll to the right-hand side of the Live Sessions window.
Note: Live sessions cannot be deleted from the ISE user interface. CoA Session Termination will release the current active session, however, the entry still persists in the session table. In order to clear the entry from the cached session table, perform the below REST API call to ISE:
DELETE: https://<ISE_PAN_IP_Address>/admin/API/mnt/Session/Delete/All Alternatively, perform a get function to gather the calling station IDs for all the active sessions and selectively delete them one by one using the following session API:
GET: https://<ISE_PAN_IP_Address>/admin/API/mnt/Session/AuthList/null/ DELETE: https://<ISE_PAN_IP_Address>/admin/API/mnt/Session/Delete/MACAddress/<calling_station_id> |
Use the ISE operational reports to track endpoint and ISE deployment-related activities over time.
1. Log in to ISE.
2. Navigate to Operations > Reports.
3. In the left pane, navigate to Reports > Endpoints and Users > Authentication Summary.
4. By default, report for current data is generated and displayed. To change the report period, click the Today drop-down list.
On the same Authentication Summary window, statistics about the ISE deployment’s performance is displayed.
Note: The other AAA-related reports include:
|
The Top N Authentication by Failure Reason provides information about the top authentication failures in the network.
The Top N Authentication by Network Device report provides information about which network devices have what percent of failure rates.
The following sections addresses several troubleshooting information that are related to identifying and resolving problems that you may experience when you use Cisco ISE & Cisco Catalyst Switches.
Some of the Cisco IOS show and debug commands that help you understand and troubleshoot ISE operations are:
The high-level functional sequence in Figure 25 shows how the components and protocols of 802.1x work together.
Figure25: High-level 802.1x Sequence
Starting 16.x IOS XE, tracing functionality logs internal events where trace files are automatically created and saved to the trace logs subdirectory.
The Contents of trace files are useful for troubleshooting & Debugging operations. To modify the trace level to increase or decrease the amount of trace messages output (Default set to NOTICE) you can set a new trace level using the set platform software trace command.
To view the trace levels for respective module under a specific process (Session Manager process/smd), use the show platform software trace level command
To view the most recent trace information, use the show platform software trace message command
Refer to attachment below for the sample trace captures for dot1x success and Failed sessions and major events are highlighted in bold..
See the following links for details on ISE troubleshooting:
How To: Troubleshoot ISE Failed Authentications & Authorizations
Troubleshoot and Enable Debugs on ISE
Troubleshooting Cisco's ISE without TAC
Hi;
@hariholla The link for the following reference does not work:
Troubleshooting Cisco's ISE without TAC
Thanks
Troubleshooting Cisco ISE without TAC broken link:
New link: Troubleshooting Cisco’s ISE without TAC | Network World
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: