Prevent statistics update for certain requests

[Alan DeKok]

On Aug 12, 2021, at 11:12 AM, Stefan Möding <s.moeding at gmail.com> wrote:
> 
> We are using FreeRADIUS as service provider.  For certain realms we need
> to forward the access request to customer specific radius servers while
> the rest is authenticated on our radius.  This work in the following ways:
> 
> 1) "user at example.net" wants access.
> 2) Our NAS tries to authenticate "example.net".

  What does that mean?  The NAS *should* just be sending "user at example.net" to FreeRADIUS.

> 3) "example.net" is a realm that needs to be forwarded to a customer
>   specific server so our radius sends a reply containing attributes (like
>   the IP) that tells the NAS which specific radius server to use.  This
>   is implemented by a local radius user named "example.net" with the
>   specific set of reply attributes.

  That seems very much non-standard.  There is no way in the RADIUS protocol for a NAS to ask a RADIUS server "do you support realm FOO?"

  i.e.. there is no way for a NAS to "authenticate example.net". 

  What equipment is doing this?  It seems like a weird vendor extension.

> 4) The NAS authenticates the user using the customer radius.
> 
> The other case is as follows:
> 
> 1) "user at example.com" wants access.
> 2) Our NAS tries to authenticate "example.com".
> 3) "example.com" is a realm that should be authenticated locally so the
>   radius server returns a reject.
> 4) The NAS then tries a second time using "user at example.com" and
>   sucessfully authenticates the user.

  That's just a terrible workflow.  I have no idea who came up with this, but it's very much the wrong thing to do.

> As you can imagine the second case leads to a notably number of access
> rejects in the statistics of the server.  Monitoring the rate of rejects
> alone no longer is useful to monitor the health of the system as these
> rejects are expected by design.

  I would very much like to know what equipment is doing this, and why,  It's perhaps cute, but a terrible idea.

  If someone does something like this, they *should* be using Status-Server, and then using an attribute inside of the reply packet to determine which realms are supported.

> Now we are thinking about a solution and came up with the idea of
> preventing a statistics update for these rejects.  A new internal
> attribute (e.g. FreeRADIUS-Inhibit-Stats-Update) would be added to the
> request and the statistics update function would ignore requests that have
> this attribute set.  Setting that attribute in unlang would be easy as it
> happens in a dedicated virtual server in our case.
> 
> Does this sound like a good solution for our problem?
> Could that be useful for others as well (say: a pull-request on Github)?

  It seems like a solution to problem that no one else has, and which is just bad.  :(

  If you really need this to work, my $0.02 is:

a) just hack the code yourself, and keep a separate patch / branch.  Git makes this trivial

b) put a proxy in front of the "real" RADIUS server.  It can handle the weird realm requests, and proxy packets for real users to the real server.

  You can then look at the stats on the real server to see what's up.

  But yeah... this is a weird and unusual use-case for RADIUS. 

  Alan DeKok.