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.