Problem with EAP Identity

Tue Jan 12 22:12:36 CET 2021

I enable MAC-auth only on switch ports that are used by 802.1x-unaware 
devices.  802.1x makes most sense on ports that are facing clients and I 
can easily distinguish which ports will be used with mac-auth and which 
by 802.1x-aware, so I just skip the issue.

If you for some reason need to have MAB enabled on every switch port and 
still connect 802.1x-aware device You can maybe try messing with 
guest-vlan timeout  - you need to set a guest-vlan and 
guest-vlan-period, but not too high value, so that it gives enough time 
for the client to boot up and start sending EAP frames and authenticate, 
without switch "taking matters in own hands" and going directly with MAB.

guest-vlan-period - The time, in seconds, for which the authenticator 
waits to see if any EAPOL packets are received on a port before 
authorizing the port and placing the port in the guest vlan (if 
configured). The guest vlan timer is only relevant when guest vlan has 
been configured on that specific port.

on edgemax switches with CLI it's something like:

configure

interface 0/1 [or other]

dot1x timeout guest-vlan-period 30

dot1x guest-vlan [some-vlan - it can be probably something bogus, just 
for the guest-vlan-period to work.

But I'd rather recommend dedicating ports for MAB and just disable it on 
everything else.

Also 802.1x in ubiquiti switches isn't perfect, but it's gotten way 
better in recent updates and I had some good interactions with ubiquiti 
support - even got some early alpha/beta patches to help with my 
specific issues.

Regards,

Kacper

W dniu 12.01.2021 o 19:55, Michael Schwartzkopff pisze:

> On 12.01.21 18:18, Kacper Wirski wrote:
>> 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
>>
> Yes, exactly the same vendor and scenario. So it seems to be a bug in
> the switch software. Do you know if there is any chance to change the
> timing behaviour of the switch, perhaps to wait longer for the host to
> answer the 802.1x request?
>
>
>> W dniu 12.01.2021 o 14:48, Alan DeKok pisze:
>>> On Jan 12, 2021, at 8:29 AM, Michael Schwartzkopff <ms at 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 at 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
> Mit freundlichen Grüßen,
>
>
> -
> 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