MAB · Service-Type Call-Check not matching

MAC Authentication Bypass not working — why MAB is rejected

802.1X users authenticate fine, but the non-802.1X devices you rely on MAC Authentication Bypass for — printers, cameras, badge readers — get rejected or dumped on the wrong VLAN. MAB is “authentication by MAC address,” and the two things that break it are both about matching.

1. The MAC-address format doesn’t match your allow-list

The device MAC arrives in Calling-Station-Id, and its format is vendor-specific and not case-consistent:

• aa-bb-cc-dd-ee-ff
• aabb.ccdd.eeff
• AA:BB:CC:DD:EE:FF

All three are the same device. If your allow-list (in AD, a SQL table, or the RADIUS config) stores one format and the switch sends another, the lookup misses and the device is rejected — even though the MAC is “on the list.” Fix: normalize on both sides — strip separators and fold case before comparing. This is also why the same printer works on one switch model and fails on another.

2. The policy keys on the wrong Service-Type

MAB requests don’t look like a user login. The switch sends Service-Type = Call-Check (10), with the MAC as both the username and the Calling-Station-Id. A network policy written for interactive users (matching user groups, or EAP conditions) won’t match a Call-Check request — so MAB falls through to a catch-all reject or a default VLAN. Fix: write a separate policy matched on Service-Type = Call-Check (and/or the MAB-specific NAS attributes) so MAB devices are evaluated on their own terms.

3. It’s authenticating — but as the wrong identity

On Windows NPS especially, a MAB MAC that happens to resemble a username, or a missing MAB account object, produces the same family as Reason Code 8 “user account does not exist” — the MAC was looked up as an identity and not found. Check the User field in the event: if it’s the bare MAC and your design expects a MAB host object or a group-membership check, the lookup path is the problem, not the device.

4. MAB isn’t enabled on the port, or 802.1X hasn’t timed out first

Many switches try 802.1X first and only fall back to MAB after the EAPOL timeout — so a “rejected” device may simply be a port where MAB isn’t configured, or where the 802.1X-then-MAB order adds a long delay that looks like a failure. Check the port’s authentication config and order (authentication order/mab on Cisco, the equivalent elsewhere).

The one diagnostic that settles it

Read the request as the server received it: radiusd -X on FreeRADIUS, or the 6273/6274 event on NPS. Confirm the User-Name and Calling-Station-Id format, and that Service-Type is Call-Check. When the MAC format on the wire doesn’t match your stored list, you’re in cause 1; when the request never hits your MAB policy, it’s cause 2. That one look tells you which.