authorized_mac best usage way

[Alan DeKok]

On Mar 2, 2023, at 9:43 AM, cedric delaunay <Cedric.Delaunay at insa-rennes.fr> wrote:
> On my last freeradius upgrade (to Version 3.2.1) I changed config files to reach this goal :
> 
>   Force the vlan for unknown mac adresses OR eduroam SSID
>   use user's one (comming from ldap module) for known mac adresses
> 
>     (yes it looks like a small network access control)
> 
> That for, I add this unlang command in default site :

  Be aware of the differences between the "default" virtual server, and the "inner-tunnel" virtual server.

  The "inner-tunnel" is for authenticating passwords inside of EAP methods (PEAP or TTLS).  But attributes you set there are set for the inner-tunnel.  They don't get sent to the NAS unless you make sure that happens.

  See the comments in "inner-tunnel" for more details.

> authorize {
> .....
> authorized_macs
> if (!ok) {
>        update reply {
>                         Tunnel-Private-Group-Id := 602
>                 }
> } else {
>         if (Called-Station-Id =~ /.*eduroam.*/i ) {
>                 update reply {
>                         Tunnel-Private-Group-Id := 602
>                 }
>         }
> }

  That likely gets run before the "eap" module...

>  and of course in ldap module :
> 
> reply:Tunnel-Private-Group-ID   := 'radiusTunnelPrivateGroupId'

  Does the LDAP module get run in the "inner-tunnel" virtual server? 

  And my guess is that you're copying the inner-tunnel reply to the outer reply.  And therefore *adding* another Tunnel-Private-Group-Id.

> Not shure why but sometimes, known mac addresses fall in vlan 602.
> 
> reading debug log, I see that access-accept request has 2 Tunnel-Private-Group-Id values.

  The debug log also shows you *why* it has 2 Tunnel-Private-Group-Id attributes.

> How can the WAP know which one apply ???

  It doesn't.  It picks one.

> My questions are :
> 
> - Is that method a valid one ? If not, how to ?
> - should I use an other operator to set Tunnel-Private-Group-Id value ?
> - why is the attribute present twice

  Because you told it do to that.

> even if := operator is always used and wiki says :

  Because at some point you're not using ":=" for Tunnel-Private-Group-Id, you're using "+=".  Read the debug output and your local configuration.

  The simple solution here is to move the check for authorized MACs from the "authorize" section to the "post-auth" section.  Put it at the *bottom* of the post-auth section:

post-auth {
	...


  authorized_macs
  if (!ok) {
       update reply {
                        Tunnel-Private-Group-Id := 602
                }
  } elsif (!&reply.Tunnel-Private-Group-Id) {
        if (Called-Station-Id =~ /.*eduroam.*/i ) {
                update reply {
                        Tunnel-Private-Group-Id := 602
                }
        }
  }
}

  i.e. for non-authorized MACs, always put them in 602.

  If SOMETHING set Tunnel-Private-Group-Id, then don't change it.

  Otherwise if Tunnel-Private-Group-Id is not set, then set it to 602 for eduroam.

  But... are you really setting Tunnel-Private-Group-Id to something other than 602 for Eduroam users?  I'd do it this way:

post-auth {
	...

  authorized_macs
  if (!ok) {
       update reply {
                        Tunnel-Private-Group-Id := 602
                }
  } elsif (Called-Station-Id =~ /.*eduroam.*/i ) {
                update reply {
                        Tunnel-Private-Group-Id := 602
                }
        }
}

  That's it.  Unauthorized MACs get 602.  Eduroam users get 602.  Everyone else gets a VLAN which was *previously* assigned by something else.

  Alan DeKok.