In MAB, the endpoint has no supplicant and stays silent when the authenticator sends its EAP identity request. Which message then carries the identity that ISE matches for that endpoint, and in what form does it arrive?
Select an answer to reveal the explanation.
Short Explanation
Right on: MAB authenticates a hardware address rather than a person. The MAC address travels in as the RADIUS username, so ISE resolves it against your endpoint records before any rule can match. It's like checking a name badge that anyone could reprint.
Full Explanation
In MAB, the endpoint does not answer the authenticator’s EAP identity request; instead, the switch uses the endpoint’s MAC address as the identity in a RADIUS Access-Request. The MAC is sent in the RADIUS User-Name attribute, allowing ISE to match it against an endpoint record and apply the associated policy. Putting the MAC in Calling-Station-ID while sending a generic User-Name is a real way to convey the client’s MAC in RADIUS, and ISE policies can use that attribute, but it does not satisfy the specified MAC-as-User-Name identity behavior. Sending the MAC as User-Name while checking an internal user account is a possible identity-store design, but it fails the stated endpoint-record lookup; MAB endpoint identity and user-account authentication are distinct lookup paths. An Accounting-Request can report a MAC in User-Name, but it is not the message that initiates MAB authentication: accounting is generally sent after authorization or to report session activity, so it cannot provide the identity for the initial decision. Exam caveat: exact MAC formatting and attribute normalization depend on switch and ISE configuration, so do not assume separators or letter case from the protocol alone. Practical check: inspect a live RADIUS Access-Request in ISE Live Logs or a packet capture and verify the User-Name value and the endpoint record ISE matched.