802.1X Deployment Breaks a Legacy Printer VLAN
A site rolls out 802.1X on ArubaOS-CX access switches. Employee ports use PEAP with a RADIUS server; authenticated users land in VLAN 100, unauthenticated in VLAN 999 (a captive-portal quarantine). A legacy label printer on VLAN 50 has a static IP and no 802.1X supplicant. After cutover, the printer is unreachable and print jobs queue. The switch port shows the printer as unauthenticated and placed in VLAN 999. The team's first instinct is to add a MAC authentication (MACA) fallback for the printer's MAC. Separately, the RADIUS server has been returning Access-Accept for a user whose account was disabled in Active Directory two hours earlier.
1. Why did the printer break, and is MAC authentication the right fix? What are the risks?
Read the worked answer
The printer broke because the port now requires 802.1X and the printer cannot authenticate, so the port fell to the unauthenticated VLAN (999) instead of VLAN 50. The printer's static IP is on VLAN 50, so it is unreachable.
MACA fallback is a common fix but has risks:
- MAC addresses are easily spoofed; MACA is a weak credential. Anyone who learns the printer's MAC can impersonate it.
- If MACA is enabled as a fallback on all ports, an attacker can bypass 802.1X by spoofing a MACA-authorized device.
Safer approach:
- Scope MACA to the specific port(s) the printer uses, not globally, and restrict the authorized MAC list to known devices.
- Place the printer in a dedicated VLAN (or keep VLAN 50) via a MACA-derived authorization, and apply an ACL limiting the printer to only the print server and required services.
- Alternatively, use a static/unauthorized-port profile on that one port with a restricted ACL rather than opening MACA broadly.
Document the exception and review it periodically; do not let exceptions accumulate.
2. The disabled AD user still authenticates successfully. What is the likely cause and how do you fix it?
Read the worked answer
The RADIUS server is returning Access-Accept for a disabled account, which means the authorization decision is not reflecting current directory state. Likely causes:
- Cached credentials / session reuse: The user may have an existing authenticated session, or the RADIUS server is caching a prior Access-Accept. Check session tables and RADIUS caching settings.
- Group/attribute mapping: The RADIUS policy may authorize based on group membership or a static user entry that was not updated when the account was disabled. Verify the policy evaluates current AD attributes, not a stale local entry.
- CoA/re-authentication not configured: Disabling an account does not terminate an active session unless the RADIUS server sends a Change of Authorization (CoA) or the switch re-authenticates on a short interval.
Fix:
- Confirm the RADIUS policy queries AD live (or syncs promptly) and does not cache Accept decisions beyond policy.
- Configure re-authentication on the switch (e.g., a reasonable reauth period) and enable CoA from the RADIUS server so disabling an account terminates the session.
- Test by disabling a test account and confirming the session drops within the expected window.
This is a security-control failure, not a switch bug - treat it as an incident and verify other accounts are not similarly affected.