Certificate Renewal Breaks 802.1X and Lands Laptops in Quarantine
A campus of about 6,000 endpoints runs Cisco ISE with 802.1X on wired access ports in multi-auth mode. Both dot1x and MAB are enabled on the port; voice is on a critical VLAN. Corporate Windows laptops authenticate with EAP-TLS using machine certificates from an internal CA. Printers use MAB. After the internal CA root was renewed and rolled, users report that laptops take roughly 90 seconds to reach the network and frequently land in the quarantine VLAN. ISE shows the laptop MAC authenticating successfully by MAB as an unknown endpoint shortly before a successful EAP-TLS attempt on a later attempt.
1. Account for the ~90 seconds and the quarantine result without blaming the switch configuration, and say what you would fix first.
Read the worked answer
With both dot1x and MAB enabled, the switch starts with EAPOL and falls back to MAB only after the dot1x attempt finishes. The default supplicant timeout is 30 s and the default maximum retransmissions is 2, giving three attempts - 30 s x 3 = 90 s. That matches the reported delay almost exactly, which tells you the supplicant is not answering at all, rather than failing the TLS handshake quickly. A cert that was rejected inside the supplicant would fail in well under a second.
The reason a laptop ignores EAPOL Request-Identity is that its supplicant validates the ISE server certificate chain. The renewed root is not in the machine trust store yet, so the supplicant silently discards the identity request and never responds. The port then falls through to MAB, ISE has no MAB entry for the laptop MAC, the default authorization result applies - quarantine - and the user sees a working but wrong network. The later successful EAP-TLS is a manual retry or a user who happened to have the new root.
Fix in this order:
- Push the new root to the Windows machine store via GPO and confirm it is trusted before the old root is retired - this is the actual defect, and it is outside the switch entirely.
- Add the new CA to ISE's trusted certificates for client certificate validation, otherwise EAP-TLS will fail even with a trusted client.
- Reduce the blast radius of the next event:
dot1x timeout supp-timeout 10anddot1x max-reauth-req 1on access ports cuts the worst case to 20 s, andauthentication event no-response action authorize vlan <voice-or-migration>gives a deterministic landing spot instead of relying on the default result.
Note that MAB as a fallback is inherently weak here: a laptop that can do 802.1X should never be authorized by MAB, so treat any MAB success for a laptop MAC as an alert.
2. A wall port has an IP phone with a PC daisy-chained behind it. Today the port is multi-auth. Explain what changes if you convert it to multi-domain, and what would break.
Read the worked answer
Multi-auth treats the port as an arbitrary collection of hosts: every MAC gets its own authentication session, each independently authorised. Multi-domain instead allows exactly one session per domain - one data, one voice - and the switch decides which domain a frame belongs to using CDP/LLDP from the phone or an OUI list. The phone gets the voice session, the PC behind it gets the data session, and the two authorisations can carry different VLANs and ACLs without interfering.
What improving to multi-domain buys you: the phone and the PC can be in different VLANs and different authorization profiles without needing two physical ports, and the phone's session is deterministic rather than one of N sessions racing.
What breaks:
- A hub or unmanaged switch behind the PC: multi-auth would put each device in its own session; multi-domain allows only one data session, so the second device is rejected or triggers a violation action.
- Phones that do not speak CDP/LLDP, or where the OUI is not configured: the switch classifies the phone as a data device, and the voice domain is never created - the phone lands in the data VLAN.
- Guests on a PC that has two NICs or a dock with a pass-through port: same one-session-per-domain limit.
A practical decision rule: multi-domain where the topology is strictly one phone and one PC and you need distinct VLANs; multi-auth where you cannot guarantee the downstream topology, accepting that each device must authenticate on its own and that voice classification depends on OUI rather than session design.
3. Two weeks after the fix, a scheduled ISE policy change disconnected all 400 desk phones for about 30 seconds mid-morning. Identify the most likely cause and the control you would put in place.
Read the worked answer
The signature - an instant, campus-wide drop at a scheduled policy change - points at a Change of Authorization, not at a timer. When ISE pushes a policy change it can signal endpoints with a CoA: reauthenticate, terminate, or (depending on the platform and the action chosen) bounce the port. A reauthenticate CoA for a MAB device forces the switch to restart the session; a terminate or port bounce drops the link entirely, which for a phone means a power/link event and a 20-40 s re-registration with CUCM.
The likely mechanism is that the policy set matched the phone MAB sessions and issued a CoA that restarted them, and because phones are MAB-only there is no supplicant to re-run, so the session had to be rebuilt from scratch on every one of the 400 ports at once.
Controls:
- Check the CoA action type before pushing: CoA reauthenticate is far less disruptive for dot1x endpoints than a port bounce; avoid port bounce for anything that is MAB-only.
- Exclude the voice MAB policy set from bulk CoA where the platform allows it, or scope the CoA to the affected endpoints rather than the whole group.
- Stage the change: apply the policy to a small pilot group first, watch
show authentication sessionsfor restart behaviour on one floor, then expand. - Keep an eye on the port's violation and critical-VLAN behaviour, since a restart storm plus link events can push phones into the critical VLAN and cause a second outage as they recover.