The Cisco Catalyst 9300 configured in [Article 8: Basic 802.1X Port Configuration on Cisco IOS XE Switches] sends RADIUS Access-Requests to ISE 3.2 at 10.0.0.10. Without the corresponding ISE configuration, those requests are either rejected (wrong shared secret) or answered with an Access-Reject (no matching policy). This article builds the complete ISE-side configuration from scratch.
The ISE navigation paths in this article use ISE 3.2. Minor UI differences exist in ISE 3.3 but the underlying objects and logic are identical. For a conceptual overview of ISE's role in 802.1X, see [Article 6: Introduction to Cisco ISE: What It Is and Why It Matters for 802.1X].
Step 1: Define the Network Device (Authenticator)
ISE must recognize the switch as a valid RADIUS client before it will process any authentication request from it.
Navigation: Administration > Network Resources > Network Devices > Add
Network Device Configuration
Name: C9300-Core-01
Description: Cisco Catalyst 9300 - Access Layer Switch
IP Address: 10.0.99.1 / 32
Device Profile: Cisco
Location: All Locations > Building-A
Device Type: All Device Types > Switches > Cisco Catalyst
Under RADIUS Authentication Settings:
Shared Secret: ISEsecret123
CoA Port: 1700
Under SNMP Settings (optional, for profiling):
SNMP Version: 2c
SNMP RO Community: public
Key configuration notes:
IP Address /32 — use a host mask. If the switch sources RADIUS from Vlan99 (10.0.99.1), that exact IP must be entered. ISE matches incoming RADIUS packets against the IP address in the Network Device database. A mismatch causes silent drops. If the switch sources from a different interface, ISE rejects the request with no log entry other than a "could not locate Network Device" error in RADIUS Live Logs.
Shared Secret — must exactly match the key configured under radius server ISE on the switch. Case-sensitive. The shared secret is used to compute the Message-Authenticator attribute on every EAP RADIUS packet. A mismatch causes authentication to fail with no clear error on either side. For production, use a random 32+ character string.
CoA Port 1700 — ISE uses this port to send Change of Authorization requests back to the switch. The switch default CoA listener port is 1700. Required for posture, profiling-based policy changes, and manual endpoint remediation from ISE. See [Article 19: Change of Authorization (CoA) in 802.1X] for full CoA configuration.
Step 2: Configure the Identity Source Sequence
ISE evaluates authentication against identity sources in a defined sequence. For Active Directory (AD) joined endpoints authenticating with PEAP-MSCHAPv2, the identity source is the AD join point. For EAP-TLS certificate authentication, the identity source is a Certificate Authentication Profile.
Navigation: Administration > Identity Management > Identity Source Sequences > Add
Name: AD_Internal_Sequence
Description: Check AD first, fall back to Internal Endpoints
Search List:
1. AD1 (Active Directory join point)
2. Internal Endpoints
3. Internal Users
If selected identity store cannot be accessed: Treat as if user was not found and proceed to the next store
This sequence first tries Active Directory for username/password validation. If the user is not found in AD (or AD is unreachable), it tries the Internal Endpoints database (useful for MAB — the MAC address is checked against ISE's internal endpoint database). See [Article 12: MAC Authentication Bypass (MAB) Configuration on Cisco IOS XE and ISE] for how MAB uses this sequence.
Step 3: Configure Allowed Protocols
ISE evaluates which EAP methods it accepts in a policy called an Allowed Protocols service. A mismatch between what ISE allows and what the supplicant offers causes EAP negotiation failure.
Navigation: Policy > Policy Elements > Results > Authentication > Allowed Protocols > Add
Name: PEAP_EAP-TLS_Allowed
Description: Allowed protocols for wired 802.1X
Allow PAP/ASCII: No
Allow CHAP: No
Allow MS-CHAPv1: No
Allow MS-CHAPv2: No
Allow EAP-MD5: No
Allow EAP-TLS: Yes
- Accept client certificates: Yes
Allow PEAP: Yes
- Inner methods allowed:
- EAP-MSCHAPv2: Yes
- EAP-GTC: No
- EAP-TLS (inside PEAP): No
Allow EAP-FAST: No
Allow EAP-TTLS: No
Preferred EAP Protocol: PEAP
EAP-TLS L-bit: Yes
Disabling EAP-MD5 and CHAP in a wired 802.1X environment is a security baseline. These methods do not provide mutual authentication and should not be used in production. The Preferred EAP Protocol setting influences which method ISE proposes first during negotiation, but the supplicant's capabilities and configuration ultimately determine the method used.
Step 4: Create Authorization Profiles
Authorization Profiles define what access level ISE grants after a successful authentication. At minimum, create profiles for each VLAN that ISE will assign dynamically.
Navigation: Policy > Policy Elements > Results > Authorization > Authorization Profiles > Add
Data VLAN Profile
Name: VLAN10_Corp_Data
Description: Corporate endpoints - Data VLAN 10
Access Type: ACCESS_ACCEPT
VLAN section:
VLAN: 10
(This populates Tunnel-Type=VLAN, Tunnel-Medium-Type=802, Tunnel-Private-Group-ID=10)
Session Timeout: 36000 (10 hours)
Reauthentication: Default
Advanced Attributes Settings:
Cisco:cisco-av-pair = url-redirect-acl=ACL_PREAUTH (only if using web redirect for posture)
Guest VLAN Profile
Name: VLAN30_Guest
Description: Unauthenticated or guest endpoints - Guest VLAN 30
Access Type: ACCESS_ACCEPT
VLAN: 30
Session Timeout: 3600 (1 hour)
Voice VLAN Profile
Name: VLAN20_Voice
Description: Cisco IP Phone 8800 series - Voice VLAN 20
Access Type: ACCESS_ACCEPT
VLAN: 20
Session Timeout: 86400 (24 hours)
Advanced Attributes Settings:
Cisco:cisco-av-pair = device-traffic-class=voice
The device-traffic-class=voice AV-Pair signals to the switch that this session belongs to the voice domain in multi-domain authentication mode. Without it, the phone session is placed in the DATA domain, and the switch may reject simultaneous DATA and VOICE domain sessions on the same port. See [Article 17: 802.1X with IP Phones: Configuring Multi-Domain Authentication on Cisco IOS XE] for the full phone configuration.
Permit All Profile (Baseline)
Name: PERMIT_ALL
Description: Full access - no ACL, no VLAN override
Access Type: ACCESS_ACCEPT
(All other fields left at default)
Use this for trusted endpoints that have been fully verified. It results in a plain Access-Accept with no VLAN override — the port stays on its configured access VLAN.
Step 5: Configure the Policy Set
Policy Sets are ISE's top-level policy containers. Each Policy Set matches incoming RADIUS requests by NAS device type, location, or RADIUS attributes, then applies its own Authentication and Authorization rules.
For a basic deployment, use the Default Policy Set. For environments with multiple switch types, ISE deployment zones, or separate wired/wireless policies, create dedicated Policy Sets per device group.
Navigation: Policy > Policy Sets
Select the Default Policy Set and expand it.
Authentication Policy
The Authentication Policy determines which identity source to use for credential validation.
Rule Name: Dot1X_Wired
Conditions:
- Wired_802.1X (built-in ISE condition: RADIUS:NAS-Port-Type EQUALS Ethernet AND EAP:Authentication-Method NOT EQUALS PAP_ASCII)
Use: PEAP_EAP-TLS_Allowed (Allowed Protocols defined in Step 3)
Identity Source: AD_Internal_Sequence (Identity Source Sequence defined in Step 2)
Rule Name: MAB_Wired
Conditions:
- Wired_MAB (built-in ISE condition: RADIUS:NAS-Port-Type EQUALS Ethernet AND Radius:Service-Type EQUALS Call Check)
Use: MAB (ISE built-in Allowed Protocols for MAC-based authentication)
Identity Source: Internal Endpoints
Place the Dot1X_Wired rule above the MAB_Wired rule. ISE evaluates rules top to bottom and uses the first match.
Authorization Policy
The Authorization Policy determines what Authorization Profile to return after successful authentication. This is where VLAN assignment, dACLs, and session attributes are defined.
Navigation: Policy > Policy Sets > Default > Authorization Policy
Rule Name: Corp_Windows_Data
Priority: 1
Conditions:
- AD:ExternalGroups EQUALS corp.local/Groups/Domain_Computers
- AND: Network_Access:AuthenticationMethod EQUALS MSCHAPV2 OR x509_Certificate
Identity Group: Any
Authorization Profile: VLAN10_Corp_Data
Rule Name: Corp_Voice
Priority: 2
Conditions:
- Cisco:cisco-av-pair CONTAINS device-traffic-class=voice
- OR: EndpointProfile EQUALS Cisco-IP-Phone-8800
Identity Group: Any
Authorization Profile: VLAN20_Voice
Rule Name: MAB_Unknown_Endpoint
Priority: 3
Conditions:
- Network_Access:AuthenticationMethod EQUALS PAP_ASCII (indicates MAB)
- AND: Session:PostureStatus NOT EQUALS compliant (optional posture check)
Identity Group: Any
Authorization Profile: VLAN30_Guest
Rule Name: Default_Deny
Priority: Last
Conditions: (none - matches everything not matched above)
Authorization Profile: DenyAccess
Rule design notes:
The Corp_Windows_Data rule matches endpoints that are domain-joined computers authenticating with PEAP-MSCHAPv2 or EAP-TLS. The AD group check (Domain_Computers) ensures only managed corporate assets receive data VLAN access. Personal devices that authenticate with valid corporate credentials but are not in Domain_Computers fall through to a more restrictive rule.
The Corp_Voice rule matches Cisco IP Phones either by the AV-Pair returned during phone authentication or by ISE's profiling engine having identified the endpoint as a Cisco-IP-Phone-8800 profile. Using both conditions with OR ensures phones are correctly placed in Voice VLAN 20 regardless of whether profiling data is available.
The Default_Deny rule is a safety net. Any authentication that does not match a specific rule is denied. This is the correct default for a closed-mode 802.1X deployment — unknown endpoints get no access, not fallback access. For monitor mode deployments, replace DenyAccess with PERMIT_ALL temporarily during rollout. See [Article 26: Monitor Mode vs Low-Impact Mode vs Closed Mode] for deployment strategy guidance.
Step 6: Configure RADIUS Live Logs for Verification
Navigation: Operations > RADIUS > Live Logs
After configuring a port on the switch and connecting an endpoint, watch Live Logs in real time. Each authentication attempt shows:
Time: 2026-03-19 14:32:11
Status: Authentication Succeeded
Username: CORP\jsmith
MAC Address: A4:B1:E9:F0:3C:22
NAS-IP-Address: 10.0.99.1
NAS-Port: GigabitEthernet1/0/1
Authentication Policy: Default > Dot1X_Wired
Authorization Policy: Default > Corp_Windows_Data
Authorization Profile: VLAN10_Corp_Data
EAP Authentication: PEAP (EAP-MSCHAPv2)
Click the detail icon (magnifying glass) on any entry to expand the full attribute list, including every RADIUS request attribute, every identity store query result, and every VSA in the Access-Accept. This view is indispensable for troubleshooting policy mismatches.
For persistent troubleshooting scenarios, use Operations > Reports > Reports > Authentication Summary for historical data rather than Live Logs (which shows only the last 24 hours by default).
Step 7: ISE RADIUS Probe and Profiling (Optional but Recommended)
ISE's profiling engine uses RADIUS attributes — particularly Calling-Station-Id (MAC address) and NAS-Port-Type — to classify endpoints automatically. Enable the RADIUS probe under:
Navigation: Administration > System > Deployment > [ISE Node] > Profiling Configuration
Enable:
- RADIUS probe
- DHCP probe (requires DHCP span or IP helper pointing to ISE)
- HTTP probe (for web-authenticating endpoints)
Profiling allows the Corp_Voice authorization rule to match by EndpointProfile EQUALS Cisco-IP-Phone-8800 without requiring a separate MAB policy. ISE recognizes the phone's MAC OUI and DHCP characteristics, classifies it as a Cisco IP Phone, and returns the Voice VLAN Authorization Profile.
Verifying ISE is Receiving and Responding to RADIUS Requests
On the switch side:
C9300# debug radius
C9300# debug dot1x events
Look for:
*Mar 19 14:32:09.412: RADIUS(0x00000012): Send Access-Request to 10.0.0.10:1812 id 1845
*Mar 19 14:32:09.891: RADIUS: Received from id 1845 10.0.0.10:1812, Access-Challenge, len 120
*Mar 19 14:32:11.203: RADIUS: Received from id 1847 10.0.0.10:1812, Access-Accept, len 187
*Mar 19 14:32:11.204: RADIUS: Tunnel-Type [64] 6 VLAN [13]
*Mar 19 14:32:11.204: RADIUS: Tunnel-Medium-Type [65] 6 802 [6]
*Mar 19 14:32:11.204: RADIUS: Tunnel-Private-Group-Id [81] 4 "10"
The presence of Access-Accept with VLAN Tunnel attributes confirms ISE is responding correctly. The absence of any RADIUS response indicates a network reachability or shared secret problem, not a policy problem.
Troubleshooting
Symptom: ISE Live Logs show "Could not locate Network Device" for every authentication attempt from the switch.
Cause: The IP address in the ISE Network Device definition does not match the source IP of the RADIUS packets sent by the switch. The switch may be sourcing RADIUS from an interface other than Vlan99 (10.0.99.1).
Fix: On the switch, confirm ip radius source-interface Vlan99 is configured. The management IP 10.0.99.1 must match the IP entered in the ISE Network Device record. If the switch is sourcing from its default route interface instead, either add a source-interface command or update the ISE Network Device IP.
Symptom: ISE Live Logs show "Authentication failed - 22040 Wrong password or invalid shared secret."
Cause: The shared secret on ISE (Network Device record) does not match the key in the radius server ISE block on the switch.
Fix: Re-enter the shared secret on both sides simultaneously. On ISE: Administration > Network Resources > Network Devices > [Switch] > RADIUS Authentication Settings > Shared Secret. On the switch: radius server ISE / key ISEsecret123. There is no way to read back the configured key in plaintext on either side — if in doubt, reset both to a known value.
Symptom: Authentication succeeds (ISE shows Access-Accept) but the port is placed in VLAN 10 regardless of the Authorization Profile — ISE is sending VLAN 20 for phones but all sessions land on VLAN 10.
Cause: aaa authorization network default group RADIUS_GROUP is missing from the switch, or the Authorization Profile's VLAN field is empty (resulting in no VLAN attributes in the Access-Accept).
Fix: Check the Authorization Profile under Policy > Policy Elements > Results > Authorization > Authorization Profiles and verify the VLAN field is populated. Check the switch for the authorization AAA command. Use debug radius to confirm the Tunnel-Private-Group-ID attribute is present in the Access-Accept packet.
Symptom: ISE returns Access-Accept but the Authorization Policy match shows the Default_Deny rule, not the intended Corp_Windows_Data rule.
Cause: The AD group condition in the Corp_Windows_Data rule is failing — the user or computer object is not a member of Domain_Computers in the AD join point configured in ISE, or ISE cannot reach AD for group membership lookup.
Fix: Navigate to Operations > RADIUS > Live Logs, expand the failed authentication, and examine the "Other Attributes" section. Look for AD-User-Candidate-Identities and AD-Groups-Names. If AD groups are empty, ISE could not perform the AD lookup. Check Administration > Identity Management > External Identity Sources > Active Directory > [Join Point] > Test User to verify AD connectivity and group membership retrieval.
What's Next: [Article 10: Configuring PEAP Authentication with Cisco ISE and IOS XE] — deep configuration of PEAP with EAP-MSCHAPv2 against Active Directory, including ISE certificate requirements, supplicant configuration on Windows 10/11, and the inner/outer identity flow.
