8.1 External Identity Systems, 802.1X Architecture & EAP Protocols

8.1 External Identity Systems, 802.1X Architecture & EAP Protocols

Core Blueprint Focus: Domain 5.0 (Client Connectivity Configuration) represents 20% of the Cisco WLCOR 350-101 examination. Designing, configuring, and troubleshooting enterprise wireless security requires mastering the IEEE 802.1X framework, EAP encapsulation, mutual PKI validation, MAB fallback workflows, and RFC 5176 RADIUS Change of Authorization (CoA) dynamic policy enforcement on the Cisco Catalyst 9800 Series Wireless LAN Controller paired with Cisco Identity Services Engine (ISE).

---

1. IEEE 802.1X Port-Based Network Access Control Architecture

Enterprise-grade wireless security departs fundamentally from consumer pre-shared keys by decoupling authentication credentials from the shared physical medium. The foundation of this model is IEEE 802.1X, an open standard defining port-based network access control that establishes an authenticated, encrypted boundary between a network endpoint and the enterprise infrastructure.

The Three-Entity 802.1X Triad

In an enterprise Cisco wireless topology, the 802.1X model divides operational responsibilities among three distinct entities:

+---------------------------------------------------------------------------------------------------+
|                                 IEEE 802.1X ARCHITECTURAL TRIAD                                   |
|                                                                                                   |
|    [ SUPPLICANT ]                   [ AUTHENTICATOR ]                  [ AUTHENTICATION SERVER ]  |
|     Client Device                  Catalyst 9800 WLC                           Cisco ISE          |
|   (macOS / Win / iOS)                + AP (Bridge)                           (RADIUS / AAA)       |
|            |                               |                                        |             |
|            | <==== EAPoL (EtherType 0x888E)===> |                                        |             |
|            |       802.11 Wireless Link    | <======= RADIUS UDP 1812 (EAP-Message) =====>|             |
|            |                               |          Encapsulated IP Datagrams     |             |
+---------------------------------------------------------------------------------------------------+

1. The Supplicant (Client Agent):
   • A software agent resident in the client operating system (such as Windows Native 802.1X Supplicant, Apple macOS/iOS Network Extension, or Linux wpa_supplicant).
   • Initiates network admission requests, responds to cryptographic challenges from the authentication server, and manages local cryptographic key stores and digital certificates.
2. The Authenticator (Cisco Catalyst 9800 WLC & Lightweight AP):
   • Serves as the gatekeeper controlling admission to enterprise network services.
   • In Cisco Centralized (Local Mode) wireless architectures, the Access Point acts as a physical RF transceiver bridging 802.11 frames into CAPWAP tunnels, while the Catalyst 9800 Wireless LAN Controller acts as the logical 802.1X Authenticator.
   • The Authenticator maintains two logical port states for each connecting client:
     • Uncontrolled Port: Permits strictly non-data traffic required for the authentication handshake—specifically Extensible Authentication Protocol over LAN (EAPoL) frames (EtherType 0x888E). All IPv4, IPv6, ARP, and general data payload traffic is discarded.
     • Controlled Port: Remains blocked (in the unauthorized state) until the Authentication Server returns a successful authentication result. Once authorized, the port opens to admit user data frames, subject to applied VLAN, QoS, and Access Control List (ACL) policies.
   • Critical Architectural Boundary: The Authenticator does not decrypt, terminate, or interpret the inner authentication credentials carried within EAP payloads. It functions strictly as an encapsulation bridge: stripping the 802.11/802.3 EAPoL header and re-encapsulating the raw EAP message into RADIUS protocol datagrams sent across the IP network.
3. The Authentication Server (Cisco Identity Services Engine [ISE]):
   • An enterprise Remote Authentication Dial-In User Service (RADIUS) and policy server.
   • Validates client credentials against identity stores (Microsoft Active Directory, LDAP, internal database, or PKI certificate authority revocation lists), evaluates posture and authorization policies, and instructs the Authenticator to open the controlled port via RADIUS Access-Accept payloads containing session keys.

---

2. EAP Encapsulation & Dual-Layer Transport Mechanics

The Extensible Authentication Protocol (RFC 3748) provides an arbitrary authentication framework rather than a specific authentication mechanism. EAP packets traverse two distinct physical and logical encapsulation formats across the enterprise infrastructure:

• EAP over LAN (EAPoL): Between the Supplicant and the Authenticator, EAP messages are encapsulated directly within Layer 2 frames defined by IEEE 802.1X-2004/2010. EAPoL packets are identified by EtherType 0x888E and include types such as EAPoL-Start, EAPoL-Packet (carrying EAP request/response payloads), EAPoL-Key (carrying 4-Way Handshake key exchanges), and EAPoL-Logoff.
• RADIUS Encapsulation: Between the Catalyst 9800 WLC and Cisco ISE, EAP messages are encapsulated into Layer 4 UDP packets on destination port 1812. The raw EAP message is segmented across one or more instances of RADIUS Attribute 79 (EAP-Message). To guarantee message integrity and authenticity against tampering by intermediate network devices, the controller computes and inserts RADIUS Attribute 80 (Message-Authenticator), an HMAC-MD5 hash across the entire RADIUS packet using the configured RADIUS shared secret.

+---------------------------------------------------------------------------------------------------+
|                                 DUAL ENCAPSULATION MECHANICS                                      |
|                                                                                                   |
|  CLIENT TO AP/WLC (EAPoL):                                                                        |
|  +-------------------+--------------------+------------------------+-------------+             |
|  | 802.11 MAC Header | EAPoL Type (0x888E)| EAP Code/ID/Length/Type| EAP Payload |             |
|  +-------------------+--------------------+------------------------+-------------+             |
|                                                                                                   |
|  WLC TO CISCO ISE (RADIUS):                                                                       |
|  +-----------+------------+---------------+-----------------------+-------------------------+    |
|  | IP Header | UDP (1812) | RADIUS Header | Attr 79 (EAP-Message) | Attr 80 (Msg-Auth HMAC) |    |
|  +-----------+------------+---------------+-----------------------+-------------------------+    |
+---------------------------------------------------------------------------------------------------+

---

3. Enterprise EAP Protocol Mechanics & Cryptographic Comparison

Enterprise networks select specific EAP methods based on organizational security policies, user directory architectures, Public Key Infrastructure (PKI) maturity, and device management capabilities.

EAP-TLS (RFC 5216): Mutual Certificate-Based Authentication

EAP-Transport Layer Security (EAP-TLS) represents the gold standard for enterprise wireless security. Standardized in RFC 5216, EAP-TLS mandates mutual certificate authentication:

• Cryptographic Mechanics: The RADIUS server (Cisco ISE) presents its X.509 server certificate to the client, and the Supplicant presents an X.509 client certificate to ISE. Both parties validate the opposing digital certificate against their trusted Root and Intermediate Certificate Authority (CA) bundles, verify revocation status via Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs), and execute an asymmetric TLS handshake.
• Zero Password Exposure: Because authentication relies entirely on asymmetric public/private key cryptography, no user password or hash ever traverses the air interface or the wired network. EAP-TLS is inherently immune to offline dictionary attacks, credential harvesting, and rogue RADIUS spoofing.
• Master Session Key (MSK) Generation: Upon successful TLS handshake completion, both the Supplicant and Cisco ISE independently derive identical 64-byte (512-bit) Master Session Keys (MSK). Cisco ISE transmits the MSK to the Catalyst 9800 WLC inside the encrypted Microsoft Point-to-Point Encryption (MS-MPPE) Vendor-Specific Attributes (Attributes 16 and 17: MS-MPPE-Recv-Key and MS-MPPE-Send-Key) appended to the RADIUS Access-Accept message. The first 32 bytes of the MSK form the Pairwise Master Key (PMK), which the WLC and client use to initiate the 802.11 4-Way Handshake.
• Enterprise Certificate Enrollment: Scaling EAP-TLS across thousands of managed mobile and desktop endpoints requires automated certificate provisioning protocols:
  • Simple Certificate Enrollment Protocol (SCEP, RFC 8894): Widely utilized by Mobile Device Management (MDM) platforms such as Microsoft Intune, VMware Workspace ONE, and Jamf Pro to enroll corporate endpoints with user and machine certificates.
  • Enrollment over Secure Transport (EST, RFC 7030): A modern, TLS-secured alternative to SCEP utilizing HTTPS for cryptographic enrollment, certificate renewal, and elliptic-curve key management.

PEAP-MSCHAPv2 (Protected EAP)

Protected EAP (PEAP) was designed to deliver secure authentication without requiring individual client certificates on every managed and unmanaged endpoint. Developed collaboratively by Microsoft, Cisco, and RSA Security, PEAP executes in two distinct phases:

• Phase 1 (Outer Tunnel): The client initiates an unauthenticated TLS handshake with the RADIUS server. Cisco ISE presents its server certificate. The client validates the server certificate chain against its local trusted root CA store. Once validated, an encrypted outer TLS tunnel is established between the Supplicant and ISE.
• Phase 2 (Inner Authentication): Inside the encrypted outer TLS tunnel, the client authenticates using a legacy inner authentication protocol—most commonly Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2). The user transmits their Active Directory username and responds to an NTLMv2 challenge-response cryptographic exchange.

Critical Vulnerabilities & Threat Vectors of PEAP-MSCHAPv2

While widely deployed, PEAP-MSCHAPv2 contains severe structural vulnerabilities:

1. Unvalidated Server Certificates & Evil Twin / Rogue RADIUS Attacks: If an enterprise network does not enforce strict supplicant configuration (via Group Policy Objects [GPOs] or MDM configuration profiles), client devices exhibit Trust on First Use (TOFU) behavior or prompt end-users to accept unrecognized certificates. An attacker deploying a rogue Access Point broadcasting the corporate SSID paired with a rogue RADIUS server (e.g., using hostapd-wpe or FreeRADIUS-WPE) can present a self-signed certificate. If a user clicks "Accept" or "Trust," the client establishes an outer TLS tunnel with the attacker.
2. MS-CHAPv2 Cryptographic Weakness & Offline Hash Cracking: Inside the rogue tunnel, the rogue RADIUS server challenges the client and captures the MS-CHAPv2 challenge/response hash. Because MS-CHAPv2 relies on single-DES and MD4 hashing algorithms, captured challenge/response pairs can be cracked offline using tools like asleap or GPU clusters running Hashcat at billions of candidate passwords per second. If the user's password is under 12 characters, it can be compromised in minutes.

EAP-FAST (Flexible Authentication via Secure Tunneling, RFC 4851)

Cisco developed EAP-FAST to eliminate the deployment complexity of client PKI certificates while avoiding the server certificate trust vulnerabilities of PEAP. Standardized in RFC 4851, EAP-FAST establishes its outer secure tunnel using a Protected Access Credential (PAC)—a dynamic shared secret generated by Cisco ISE for each unique client.

+---------------------------------------------------------------------------------------------------+
|                                   EAP-FAST THREE-PHASE ARCHITECTURE                               |
|                                                                                                   |
|  [ Phase 0: PAC Provisioning ]                                                                    |
|  - In-Band (Phase 0 via Anonymous Diffie-Hellman) OR Out-of-Band (MDM/File Injection)             |
|  - Client receives: PAC-Key (Secret), PAC-Opaque (Encrypted Token), PAC-Info (Identity)          |
|                                                                                                   |
|  [ Phase 1: TLS Tunnel Establishment ]                                                            |
|  - Client presents PAC-Opaque to ISE                                                              |
|  - ISE decrypts PAC-Opaque with its master key to recover PAC-Key                                 |
|  - Mutual authenticated TLS tunnel formed using PAC-Key WITHOUT digital certificates              |
|                                                                                                   |
|  [ Phase 2: Inner Authentication ]                                                                |
|  - User/machine credentials exchanged inside tunnel via MS-CHAPv2 or EAP-GTC                      |
+---------------------------------------------------------------------------------------------------+

• PAC Structure: A PAC comprises three elements: (1) PAC-Key (a 32-byte secret key shared between client and ISE), (2) PAC-Opaque (an encrypted blob containing the client identity and key expiration, decryptable only by ISE's master key), and (3) PAC-Info (metadata including ISE server authority identity).
• In-Band vs. Out-of-Band Provisioning: In-band provisioning (Phase 0) uses unauthenticated anonymous Diffie-Hellman (ADH) key exchange to deliver the initial PAC over the air. Critical Security Caveat: In-band automatic PAC provisioning is vulnerable to man-in-the-middle (MITM) interception during the initial Phase 0 exchange. High-security environments strictly enforce out-of-band PAC provisioning via pre-staged MDM configuration files.

EAP-TTLS (Tunneled Transport Layer Security, RFC 5281)

EAP-Tunneled Transport Layer Security (EAP-TTLS), standardized in RFC 5281, was co-developed by Funk Software and Certicom as an open IETF alternative to PEAP:

• Asymmetric Certificate Requirement: Like PEAP, EAP-TTLS requires a digital certificate only on the RADIUS server. Endpoints authenticate the server certificate chain against their local root CA store; client-side certificates are not required.
• Flexible Inner Authentication Options: Unlike PEAP (which primarily encapsulates EAP-based inner methods such as EAP-MSCHAPv2), EAP-TTLS can encapsulate both EAP and non-EAP legacy authentication protocols within the encrypted TLS tunnel. Inside the tunnel, endpoints can transmit legacy PAP (Password Authentication Protocol), CHAP, MS-CHAP, or MS-CHAPv2 attributes formatted as Diameter/RADIUS Attribute-Value Pairs (AVPs).
• Directory Integration Advantage: Because EAP-TTLS can transport plaintext credentials (PAP) safely inside the encrypted TLS tunnel, the RADIUS server can validate user passwords directly against directory stores that do not store NT password hashes or reversible encryption (such as open-source OpenLDAP, Novell eDirectory, or Unix shadow password databases). In contrast, MS-CHAPv2 requires access to the user's NTLM hash, restricting PEAP deployments largely to Microsoft Active Directory environments.

TEAP (Tunnel Extensible Authentication Protocol, RFC 7170)

Tunnel Extensible Authentication Protocol (TEAP) is an open IETF standard (RFC 7170) engineered to resolve the enterprise "machine versus user" authentication dilemma.

• The Active Directory Problem: In enterprise Windows domains, computers must join the domain and apply Group Policy Objects (GPOs) prior to user logon (requiring Machine Authentication), while corporate network policies dictate that network permissions, VLANs, and firewall rules depend on who is logged in (requiring User Authentication). Under PEAP or EAP-TLS, clients execute either machine authentication or user authentication, forcing the network into complex "machine-then-user" roaming transitions that frequently break background GPO processing and drive mapping.
• TEAP Chained Authentication: TEAP establishes a single outer TLS tunnel (using server certificates or mutual certificates) and executes chained authentication: transporting both the machine credentials (machine certificate or TPM-backed identity) and the user credentials (Active Directory username/password or user certificate) within sequential Type-Length-Value (TLV) payloads inside the same EAP transaction.
• Cryptographic Binding: TEAP cryptographically binds the machine and user authentications into a composite Compound MAC (CMAC). Cisco ISE evaluates both identities simultaneously: if a legitimate user logs in from an unapproved personal device, ISE detects a user-only match with no valid machine chain and restricts access to a guest VLAN.

EAP Methods Enterprise Comparison Matrix

The following matrix summarizes the architectural, cryptographic, and operational characteristics of enterprise EAP methods tested on the Cisco WLCOR 350-101 examination:

---

4. MAC Authentication Bypass (MAB) Mechanics & Threat Modeling

Not all enterprise endpoints possess the cryptographic or computational capability to execute 802.1X supplicant stacks. Devices such as IP security cameras, networked printers, medical infusion pumps, building automation controllers, and barcode scanners are headless IoT devices that require network admission without 802.1X.

Operational Sequence of MAB

MAC Authentication Bypass (MAB) is an admission control mechanism that utilizes the client's Layer 2 Media Access Control (MAC) address as both its identity and credential:

+---------------------------------------------------------------------------------------------------+
|                                 MAB OPERATIONAL FALLBACK FLOW                                     |
|                                                                                                   |
|    [ Headless Device ]               [ Catalyst 9800 WLC ]                     [ Cisco ISE ]      |
|             |                                  |                                     |            |
|             | ----- 1. 802.11 Association ---> |                                     |            |
|             | <---- 2. EAP-Request/Identity -- | (WLC starts EAPoL timeout timer)    |            |
|             |       (Silence / No Response)    |                                     |            |
|             | <---- 3. EAP-Request (Retry 3) - |                                     |            |
|             |       (Silence / EAP Timeout)    | (Fallback to MAB initiated)         |            |
|             |                                  | --- 4. RADIUS Access-Request -----> |            |
|             |                                  |    User-Name: <Client_MAC>          |            |
|             |                                  |    User-Password: <Client_MAC>      |            |
|             |                                  |    Service-Type: Call Check (10)    |            |
|             |                                  |                                     |            |
|             |                                  | <--- 5. RADIUS Access-Accept ------ |            |
|             |                                  |    VLAN ID / dACL / SGT Assigned    |            |
|             | <==== 6. Port Authorized ======= |                                     |            |
+---------------------------------------------------------------------------------------------------+

1. The headless device completes 802.11 open authentication and association with an Access Point mapped to an 802.1X-enabled WLAN.
2. The Catalyst 9800 WLC opens the uncontrolled port and transmits an EAP-Request/Identity frame. It initializes an EAPoL timeout timer (typically 30 seconds with 3 retries).
3. Because the headless device lacks an 802.1X supplicant, it completely ignores the EAPoL frames. Upon expiration of the retry counter, the Catalyst 9800 recognizes the client as non-802.1X-capable and initiates the MAB fallback routine.
4. The WLC synthesizes a RADIUS Access-Request datagram containing the client MAC address formatted according to the configured delimiter policy (e.g., lowercase hexadecimal without separators aabbccddeeff, colon-delimited aa:bb:cc:dd:ee:ff, or hyphen-delimited aabb-ccdd-eeff):
   • Attribute 1 (User-Name): Contains the client MAC address.
   • Attribute 2 (User-Password): Contains the identical client MAC address (hashed with the RADIUS shared secret).
   • Attribute 6 (Service-Type): Set to Call Check (value 10), signaling to Cisco ISE that this transaction represents an automated Layer 2 admission check rather than an interactive user login.
5. Cisco ISE queries its internal endpoint identity database or external CMDB. If the MAC address is registered, ISE returns a RADIUS Access-Accept containing authorization attributes (VLAN assignment, downloadable ACLs, or TrustSec Security Group Tags).

Vulnerabilities & Defensive Engineering for MAB

• The MAC Spoofing Threat Vector: MAC addresses are transmitted in completely unencrypted, plaintext Layer 2 headers across all 802.11 transmissions. An attacker operating an inexpensive Wi-Fi packet analyzer (e.g., Wireshark or airodump-ng) can observe valid MAC addresses of active network printers or cameras, spoof their wireless network interface card to match an authorized MAC address, and achieve unauthorized network admission.
• Defense in Depth via ISE Endpoint Profiling: MAB should never be deployed as a standalone security boundary. Enterprise networks mitigate spoofing by enforcing Cisco ISE Device Profiling:
  • DHCP Snooping & Profiling: Inspecting DHCP Option 55 (Parameter Request List) and Option 60 (Vendor Class Identifier [VCI]). A rogue laptop spoofing a printer's MAC address will transmit Windows/Linux DHCP options that immediately trigger a profiling violation.
  • HTTP User-Agent Parsing: Inspecting browser headers during initial HTTP requests.
  • CDP/LLDP Snooping: Verifying switchport and neighbor discovery protocol TLVs forwarded via RADIUS accounting or sensor probes.
  • Micro-Segmentation via Cisco TrustSec: Dynamically assigning restrictive Security Group Tags (SGTs) and Downloadable ACLs (dACLs) that constrain the endpoint to communicating strictly with designated printer servers or medical imaging storage systems, preventing lateral movement across the enterprise.

---

5. RADIUS Protocol Architecture, RFC Attributes & Dynamic Authorization (CoA)

Remote Authentication Dial-In User Service (RADIUS) provides centralized Authentication, Authorization, and Accounting (AAA) management between the Catalyst 9800 WLC and Cisco ISE.

Transport Mechanics, Standard Ports & Shared Secret Security

• IETF RFC Standard Ports: Standardized in RFC 2865 (Authentication/Authorization) and RFC 2866 (Accounting):
  • UDP Port 1812: RADIUS Authentication and Authorization.
  • UDP Port 1813: RADIUS Accounting.
  • Legacy Ports: Early implementations used non-standard UDP ports 1645 (Authentication) and 1646 (Accounting). Cisco IOS-XE defaults to RFC-compliant ports 1812/1813.
• Packet Header & Shared Secret Hashing: Every RADIUS packet includes a 20-byte header comprising: Code (1 byte: 1=Access-Request, 2=Access-Accept, 3=Access-Reject, 4=Accounting-Request, 5=Accounting-Response, 11=Access-Challenge), Identifier (1 byte matching requests to replies), Length (2 bytes), and an Authenticator (16 bytes). In Access-Request packets, the Authenticator is a 16-byte cryptographically random number. The shared secret configured between the Catalyst 9800 and ISE is never transmitted over the wire; it is used as a symmetric key in an MD5 hashing algorithm to protect the User-Password attribute and compute the Message-Authenticator (Attribute 80).

Dynamic Authorization Attributes: Dynamic VLANs and ACL Frameworks

Upon successful client authentication, Cisco ISE injects authorization attributes into the RADIUS Access-Accept datagram, which the Catalyst 9800 applies to the client's session state:

RFC 5176 Change of Authorization (CoA)

Traditional RADIUS is strictly client/server-initiated: the Network Access Server (Catalyst 9800 WLC) sends requests, and the AAA server (Cisco ISE) returns responses. In modern networks, the AAA server must dynamically alter an active client's authorization state in response to asynchronous network events—such as an endpoint failing a scheduled posture assessment, an administrator revoking network privileges, or a guest user completing self-registration on a web portal.

To achieve this, RFC 5176 defines Dynamic Authorization, commonly known as Change of Authorization (CoA):

• Port Architecture: CoA operates over UDP. Cisco devices default to listening on UDP Port 1700, while RFC 5176 specifies standard UDP Port 3799. The Catalyst 9800 must have aaa server radius dynamic-author configured to process inbound CoA datagrams from ISE.
• Core CoA Message Types:
  1. CoA-Disconnect (Disconnect-Request / Packet Code 40):
     • Instructs the Catalyst 9800 to immediately terminate the client's active session.
     • The WLC clears the client state machine, deletes the PMK encryption context, sends an 802.11 Deauthentication frame to the client station, and returns a Disconnect-ACK (Code 41) to ISE. If the session cannot be found, it returns Disconnect-NAK (Code 42).
     • Use Case: Immediate quarantine of a compromised host, administrative session termination, or guest session time expiration.
  2. CoA-Reauth (CoA-Request / Packet Code 43 with Re-authenticate Action):
     • Instructs the Catalyst 9800 to dynamically re-evaluate the client's authorization policy without severing the physical Layer 2 RF association.
     • The controller initiates a background re-authentication or re-authorization handshake with ISE, receives updated authorization attributes (such as removing a quarantine redirect ACL and applying a full-access employee dACL), and updates the client's session state machine hitlessly.
     • Use Case: Central Web Authentication (CWA) guest login transitions and Cisco AnyConnect / Secure Client ISE Posture compliance transitions.

---

6. Cisco Catalyst 9800 IOS-XE AAA Configuration Blueprint

The following configuration illustrates production-grade AAA, RADIUS, and dynamic authorization commands on a Cisco Catalyst 9800 Series Wireless LAN Controller running Cisco IOS-XE:

! =========================================================================
! 1. GLOBAL AAA INITIALIZATION & SERVER DEFINITION
! =========================================================================
aaa new-model

! Define Primary and Secondary Cisco ISE RADIUS Servers
radius server ISE-PRIMARY
 address ipv4 10.10.20.50 auth-port 1812 acct-port 1813
 key 7 0822455D0A16
 pacs-key 7 110A1016141D

radius server ISE-SECONDARY
 address ipv4 10.10.20.51 auth-port 1812 acct-port 1813
 key 7 0822455D0A16
 pacs-key 7 110A1016141D

! Group Servers into AAA Server Group
aaa group server radius RADIUS-ISE-GROUP
 server name ISE-PRIMARY
 server name ISE-SECONDARY
 ip radius source-interface Vlan10

! =========================================================================
! 2. AAA METHOD LISTS FOR 802.1X AND MAB
! =========================================================================
! 802.1X Authentication and Authorization Lists
aaa authentication dot1x DOT1X-AUTH-METHOD group RADIUS-ISE-GROUP
aaa authorization network DOT1X-AUTHZ-METHOD group RADIUS-ISE-GROUP

! Accounting Method List for Session Logging and Profiling
aaa accounting network WIRELESS-ACCT-METHOD start-stop group RADIUS-ISE-GROUP

! =========================================================================
! 3. RFC 5176 DYNAMIC AUTHORIZATION (CoA) LISTENER
! =========================================================================
aaa server radius dynamic-author
 client 10.10.20.50 server-key 7 0822455D0A16
 client 10.10.20.51 server-key 7 0822455D0A16
 port 1700
 auth-type any

! =========================================================================
! 4. POLICY PROFILE BINDING FOR DYNAMIC AAA OVERRIDE
! =========================================================================
wireless profile policy Corp-Employee-Policy
 aaa-override
 nac
 accounting-list WIRELESS-ACCT-METHOD
 vlan WIRELESS_DATA
 no shutdown