How to deal with switches not sending User-Password attribute for MAC-based authentication

[Alan DeKok]

On Jan 24, 2020, at 12:47 PM, Martin Gignac <martin.gignac at gmail.com> wrote:
> 
> I'm setting up wired 802.1x authentication for Juniper and Ubiquiti
> switches. Each device supports supplicant-based authentication and can fall
> back to MAC-based authentication. When using the Juniper, if it falls back
> to MAC-based authentication it sends an Access-Request with User-Name and
> User-Password attributes that both contain the MAC address of the device
> connecting to the switch, such as "e6e849A201e8". However, when the
> Ubiquiti falls back to MAC-based auth the Access-Request it sends only
> contains the User-Name attribute.

  That's a violation of the RFCs, unfortunately.

> Since my sites-enabled/default file
> contains:
> 
>       if (User-Password) {
>               update control {
>                       Auth-Type := rest
>               }
>       }
> 
> in the authorize section, REST authentication is completely skipped. I then
> tried adding:
> 
>       if (&NAS-Port-Type == "Ethernet" && !User-Password) {
>                update control {
>                        User-Password = &User-Name

  Don't do that.

>                        Auth-Type := rest
>                }
>        }
> 
> right on top of the previous section, but then I get this:

  Where you haven't included the Access-Request packet coming in.  How can we help debug things if were don't know what we're debugging?

> (1)     if (&NAS-Port-Type == "Ethernet" && !User-Password) {
> (1)     if (&NAS-Port-Type == "Ethernet" && !User-Password)  -> TRUE
> (1)     if (&NAS-Port-Type == "Ethernet" && !User-Password)  {
> (1)       update control {
> (1)         User-Password = &User-Name -> 'E6E849A201E8'
> (1)         Auth-Type := rest
> (1)       } # update control = noop
> (1)     } # if (&NAS-Port-Type == "Ethernet" && !User-Password)  = noop
> (1)     if (User-Password) {
> (1)     if (User-Password)  -> FALSE
> (1) pap: WARNING:
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> (1) pap: WARNING: !!! Ignoring control:User-Password.  Update your
> !!!
> (1) pap: WARNING: !!! configuration so that the "known good" clear text !!!
> (1) pap: WARNING: !!! password is in Cleartext-Password and NOT in
> !!!
> (1) pap: WARNING: !!! User-Password.
> !!!
> (1) pap: WARNING:
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  That's pretty clear.

> So I changed it to this:

  i.e. "randomly changed things in the hope it would do something".

  That's not the way to debug or fix issues.  The better method is to understand what's going on.  And, to understand what you want.

>       if (&NAS-Port-Type == "Ethernet" && !User-Password) {
>                update control {
>                        Cleartext-Password = &User-Name
>                        Auth-Type := rest
>                }
>        }
> 
> (2)     if (&NAS-Port-Type == "Ethernet" && !User-Password) {
> (2)     if (&NAS-Port-Type == "Ethernet" && !User-Password)  -> TRUE
> (2)     if (&NAS-Port-Type == "Ethernet" && !User-Password)  {
> (2)       update control {
> (2)         Cleartext-Password = &User-Name -> 'E6E849A201E8'
> (2)         Auth-Type := rest
> (2)       } # update control = noop
> (2)     } # if (&NAS-Port-Type == "Ethernet" && !User-Password)  = noop
> (2)     if (User-Password) {
> (2)     if (User-Password)  -> FALSE
> (2) pap: WARNING: Auth-Type already set.  Not setting to PAP
> (2)     [pap] = noop
> (2)   } # authorize = updated
> (2) Found Auth-Type = rest
> (2) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
> (2)   authenticate {
> (2) rest: ERROR: You set 'Auth-Type = REST' for a request that does not
> contain a User-Password attribute!

  Exactly.

> Am I approaching the problem in a wrong way? What would be the best way to
> deal with the lack of the User-Password attribute?

  Define "deal with".  What do you want to do?  What's in the packets?  What is the REST API doing?

  "I want to do stuff" is a request we can't help with.

  If you want to see if the device is authorized, and only the User-Name contains the MAC address, then look up the MAC address via the REST API.

  Alan DeKok.