Port Security — Real-World Examples

Organization: A financial services firm with 400 employees. Branch office conference rooms have Ethernet ports under the tables and in the walls. The firm's CISO ran a penetration test; the pen tester walked into a conference room, plugged a laptop into the Ethernet port, and gained full access to the internal network in 45 seconds — no authentication required.

The problem scenario (before 802.1X):

Without 802.1X, a switch port that is administratively "up" accepts any connected device immediately. The pen tester's laptop received a DHCP address from the corporate DHCP server and could communicate with any internal system. The switch had no mechanism to ask "who are you?" before handing out network access. Physical access to the building was the only barrier — and conference rooms are accessible to any visitor, vendor, or delivery person.

The solution deployment:

The firm deployed 802.1X across all switch ports using PEAP with MSCHAPv2, integrated with their Active Directory via a Microsoft NPS (Network Policy Server) RADIUS server. Configuration steps:

1. All switch ports configured for 802.1X authentication (authenticator role)
2. NPS RADIUS server configured as authentication server, integrated with Active Directory
3. Windows domain policy pushed 802.1X supplicant configuration to all domain-joined computers
4. Conference room ports placed in "Guest VLAN" for failed authentications (internet-only, no corporate access)

What happens when the pen tester repeats the test after 802.1X:

Pen tester plugs laptop into conference room port
Switch detects connection → port enters unauthorized state
Switch sends EAP-Request/Identity to pen tester's laptop
Pen tester's laptop has no domain credentials → times out
Switch moves port to Guest VLAN (internet-only)
Pen tester gets internet access but no internal network access

Pen tester cannot reach internal servers, file shares, databases, or other resources
RADIUS server logs the failed authentication attempt with timestamp and port ID

Business outcome: The conference room ports are now safe for visitor use — guests get internet access via the Guest VLAN, but cannot access any corporate systems. An employee who plugs in their domain-joined laptop authenticates automatically and transparently (no password prompt — Windows handles the EAP exchange in the background). Security without friction for legitimate users; hard barrier for unauthorized devices.

Organization: A university with 15,000 students, 3,000 staff, and 500 wireless access points. Corporate Wi-Fi uses 802.1X with PEAP. Students and staff use their university credentials (same username/password as student portal and email).

What happens when a student connects to "University-WiFi" for the first time:

1. Association: Student's phone associates with the access point — no network access yet. The AP (authenticator) blocks all traffic except EAP messages.
2. Identity request: AP sends EAP-Request/Identity to the phone.
3. Identity response: Student's phone replies with the student's username (e.g., "jsmith@university.edu").
4. RADIUS forwarding: AP forwards this to the RADIUS server (Cisco ISE in this deployment).
5. PEAP outer tunnel setup: RADIUS server initiates a TLS handshake with the phone. The phone verifies the server's certificate (confirming it is the real university RADIUS server, not an impostor). TLS tunnel is established.
6. Inner authentication: Inside the TLS tunnel, RADIUS sends a MSCHAPv2 challenge. The student's phone presents the student's username and password (hashed via MSCHAPv2 — password never sent in plaintext). The MSCHAPv2 exchange is encrypted inside the TLS tunnel.
7. RADIUS validates: RADIUS server verifies the credentials against the university's Active Directory (via LDAP). The student account is valid and not disabled.
8. Access-Accept with VLAN: RADIUS returns Access-Accept to the AP, including a VLAN assignment: student accounts → VLAN 20 (student network), staff accounts → VLAN 10 (staff network).
9. Port opens: AP assigns the phone to VLAN 20 and opens normal traffic. Phone receives a DHCP address on the student network.

What the student experiences: A password prompt appears. They type their university username and password. They get connected. The entire EAP exchange took under 2 seconds. The PEAP TLS tunnel, the MSCHAPv2 inner authentication, and the RADIUS-to-AD verification all happened invisibly behind that single password prompt.

Security properties of this deployment: The student's password was never exposed — it traveled inside a TLS tunnel. If someone sets up a rogue access point with the same SSID, the phone will reject the rogue AP's certificate (unless the user overrides the warning), preventing credential capture. Staff and student networks are automatically segregated based on AD group membership, not manual VLAN assignment.

Organization: A government contractor handling classified research data. Security policy requires that only company-issued, certificate-provisioned devices can access any internal network resource — not just any user with a valid password. An employee's personal laptop should never reach the internal network, even if the employee has valid credentials.

Why PEAP is insufficient here: PEAP authenticates the user (via username/password). A user could authenticate from their personal laptop, a compromised device, or even a device controlled by an attacker who stole their credentials. The organization needs to authenticate the device, not just the user.

EAP-TLS solution:

1. The organization operates an internal Certificate Authority (CA).
2. Every company-issued workstation and laptop receives a machine certificate issued by the internal CA during provisioning. The certificate contains the device's identity (hostname, serial number).
3. The RADIUS server is configured to require EAP-TLS and to trust only certificates issued by the internal CA.
4. When any device connects to a switch port or wireless AP, the EAP-TLS exchange requires the device to present its machine certificate.

What happens with different device types:

Company laptop (has internal CA certificate):
→ Presents certificate → RADIUS verifies against internal CA → Access-Accept → Full network access

Employee's personal laptop (no internal CA certificate):
→ Cannot present valid certificate → RADIUS returns Access-Reject → No network access
Even if employee knows their own username and password — irrelevant for EAP-TLS

Attacker with stolen credentials:
→ No certificate → Cannot authenticate → No network access
Stolen username/password provides zero benefit — cert is required

Mutual authentication benefit: The device also verifies the RADIUS server's certificate. A rogue RADIUS server cannot impersonate the legitimate one — the device will reject any server whose certificate is not trusted by the internal CA.

Operational overhead accepted: Every device needs a certificate. Device provisioning includes certificate enrollment. Certificate lifecycle management (renewal, revocation) is required. This is the cost the organization accepts for device-level authentication assurance.

Problem: A hospital deploys 802.1X across all wired switch ports. After deployment, 47 network printers, 12 IP cameras, and 8 building management system (BMS) controllers stop working. These devices — mostly 5–10 years old — do not have 802.1X supplicant software. They connect to the switch, the switch requests EAP authentication, and the devices respond with nothing. The switch keeps the port in the blocked state. The printers cannot print, the cameras cannot stream, and the BMS cannot communicate with the building management server.

Why these devices cannot use 802.1X: Embedded systems (printers, cameras, industrial controllers) often run minimal firmware with no 802.1X client implementation. The manufacturer never added 802.1X support because the device was designed for simpler networks. Upgrading firmware is not always possible for end-of-life devices, and purchasing all-new equipment is cost-prohibitive for dozens of devices.

Solution: MAC Authentication Bypass (MAB):

1. Each device's MAC address is registered in the RADIUS server database.
2. Switch ports assigned to these devices are configured for MAB fallback: if the connected device does not respond to EAP authentication within a timeout period, the switch falls back to MAB mode.
3. In MAB mode, the switch sends the device's MAC address to the RADIUS server as the authentication credential.
4. RADIUS checks the MAC address against the registered list → returns Access-Accept with the device-specific VLAN assignment.
5. The device's port opens, and the device resumes normal operation.

The security trade-off of MAB: MAC addresses can be spoofed. An attacker who knows that printer MAC address 00:11:22:33:44:55 is authorized can configure their laptop's network adapter with that MAC address and be granted network access. MAB should be:

• Used only for specific devices that genuinely cannot support 802.1X
• Combined with VLAN segmentation (MAB devices on a restricted VLAN with only the access they need, not full corporate network access)
• Complemented with physical security (locked wiring closets; port security limiting the number of MAC addresses per port)

Hospital outcome: Printers, cameras, and BMS controllers are placed on dedicated VLANs accessible only to the specific servers they need to communicate with. 802.1X with EAP handles all employee devices with no MAB fallback. The 67 legacy devices use MAB on restricted VLANs. The hospital gets 802.1X protection everywhere it is technically feasible, with a documented exception process for legacy devices.

Scenario: A law firm with 200 attorneys and 50 support staff operates three physical locations: headquarters (primary data and systems), two branch offices (shared conference rooms, client meeting areas). The IT team is deploying 802.1X enterprise-wide. Answer the following questions.

Question 1: The IT team wants employees to use their existing Active Directory credentials for 802.1X authentication — no separate passwords. Which centralized authentication integration should the RADIUS server use?

Question 2: The firm's managing partner insists that only firm-issued laptops, not attorneys' personal devices, should be able to access the firm's internal document management system — even if an attorney provides their valid AD credentials. Which EAP method satisfies this requirement?

Question 3: Client meeting rooms at branch offices have Ethernet ports and Wi-Fi. Clients need internet access. They should not have access to any internal firm systems. What is the correct 802.1X configuration for these ports?

Question 4: After deployment, the help desk reports that employees at one branch office cannot connect to any network resource — neither wired nor wireless — despite entering correct credentials. Attorneys at headquarters are unaffected. What is the most likely cause?