I've seen similiar behaviour on some ubiquiti switches, when port had "MAC authentication bypass" enabled and connected client was 802.1x aware (e.g. windows PC with eap/peap). What would sometimes happen is that when client for whatever reason didn't provide identity fast enough (depending on switch timeouts for 802.1x), and port had mac-auth-bypass enabled ,switch goes on with MAC-auth (as seen in the first acces-requeste), but then later connected client cathes on and sends it's reply to EAP-request-identity, so switch changes user-name. Maybe it's similar scenario? Check if MAC authentication bypass is enabled on Your switch's port or not (depending what You wish to achieve). Regards, Kacper W dniu 12.01.2021 o 14:48, Alan DeKok pisze:
On Jan 12, 2021, at 8:29 AM, Michael Schwartzkopff <ms@sys4.de> wrote:
I stumbled upon a strange behaviour of my switches. I want to configure 802.1x. In the first packet the Switch sends:
Debug: (7) Received Access-Request Id 81 from x.x.x.46:36296 to x.x.x.154:1812 length 152 Debug: (7) User-Name = "3464A9D11215" That's weird.
The debug goes on:
Debug: (7) eap: Peer sent packet with method EAP Identity (1) Debug: (7) eap: EAP session adding &reply:State = 0x45e56b9d45e46617 Debug: (7) modsingle[authenticate]: returned from eap (rlm_eap) Debug: (7) [eap] = handled
The next request from the switch is:
Debug: (8) Received Access-Request Id 82 from x.x.x.46:36296 to x.x.x.154:1812 length 167 Debug: (8) User-Name = "host/test@xxx.xx" (...) Debug: (8) State = 0x45e56b9d45e46617718e28efb749ef6f That's weirder. :(
and then the RADIUS server complains:
Debug: (8) eap: Previous EAP request found for state 0x45e56b9d45e46617, released from the list Debug: (8) eap: Identity does not match User-Name. Authentication failed Debug: (8) eap: Failed in handler
Can anyone explain what happens here? Does the switch change the User-Name within the RADIUS / EAP session? Is this a bug of the switch? Or does something other happen here? The switch is *supposed* to be sane. See RFC 3579 Section 2.1:
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request.
i.e. the switch is *not* supposed to change the User-Name in the middle of an EAP session.
My $0.02 is to post the full debug output to check. But also to "name and shame" the switch vendor. Then, throw it in the garbage and buy one that works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast. https://www.avast.com/antivirus