802.1X Rollout Stalls on Printers and Certificates
A university deploys wired 802.1X on 3,000 endpoints with Cisco ISE 3.1 and Catalyst 9200 switches. Policy is employee laptops with EAP-TLS, BYOD through onboarding, and printers and badge readers with MAB. After rollout, 40 printers fail every morning at 07:00. ISE shows MAB unknown and then the authorization profile printer-deny. The printer MAC addresses are in a CSV group, but the switch port uses authentication host-mode multi-auth and a VoIP phone is daisy-chained. Certificate renewals caused 300 laptops to fail EAP-TLS with certificate revoked even though the CRL is reachable. The guest VLAN is also used for failed authentication. The university wants no disruption to clinical systems.
1. Diagnose the printer failures and propose switch and ISE changes. Explain why the failure is time-specific.
Read the worked answer
The failure pattern points to session and identity handling, not a simple bad MAC list:
- Multi-auth with a daisy-chained phone creates multiple authentication sessions on one port. The phone may authenticate or MAB first, and the printer's MAB can be attributed to the wrong session or VLAN. At 07:00, phones may reboot or reauthenticate after power scheduling, which resets the port and forces the printer to re-MAB.
- MAB unknown then printer-deny means ISE did not match the MAC to the printer identity group at that moment. Check MAC format, CSV import errors, and whether the group is referenced in the correct policy set. Also check that the printer's MAC is learned before any reauthentication timer expires.
- Guest VLAN on failure can put the printer on the wrong segment, so it appears offline and retries, repeating the cycle.
Change to a host-mode that fits the topology, such as multi-domain with a voice domain, or use a dedicated printer port template. Increase MAB timeout, disable periodic reauthentication for printers, and use profiling plus a static MAC group. Test by rebooting the phone at 07:00 and confirming the printer stays authorized. Verify with show authentication sessions and ISE live logs.
2. Why did EAP-TLS fail after certificate renewal, and how would you fix it without weakening certificate validation?
Read the worked answer
Certificate revoked after renewal usually means the new certificate is not trusted or the revocation check is failing for a reason other than the CRL being reachable:
- The supplicant selected the old certificate or a certificate without the client-authentication EKU. Renewal can leave multiple certificates; the GPO or supplicant profile may still point to the old template or thumbprint.
- The new certificate lacks the correct SAN or UPN, so ISE cannot match it to the AD account, or the certificate chain is incomplete on the endpoint.
- CRL or OCSP reachability from the endpoint and from ISE differ. The CRL URL may be reachable from ISE but blocked for endpoints, or the CRL is stale.
- Time skew or a reissued CA chain can make the certificate appear invalid.
Fix by validating the certificate template, EKU, SAN, and chain; updating the supplicant profile to select the new certificate; confirming CRL/OCSP from both endpoint and ISE; and checking ISE certificate authentication profiles and time. Do not disable revocation checking globally. Instead, scope an exception only if a specific non-clinical device cannot support revocation, and document it. Validate with a pilot group before touching clinical systems.