[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: Prevent statistics update for certain requests
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2021-08-12 15:26:20
Message-ID: 0F510D5D-8B93-4036-A32D-C7A99D3C59AC () deployingradius ! com
[Download RAW message or body]

On Aug 12, 2021, at 11:12 AM, Stefan Möding <s.moeding@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@example.net" wants access.
> 2) Our NAS tries to authenticate "example.net".

  What does that mean?  The NAS *should* just be sending "user@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@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@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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]