Re: authorized_mac best usage way

2 Mar 2023

      On Mar 2, 2023, at 9:43 AM, cedric delaunay <Cedric.Delaunay@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.