A question - User Auth etc

[Peter Lambrechtsen]

I had a similar problem at my old role.

What I talked about doing would be to create a dummy virtual network on the
BNG that didn’t route anywhere.

Then have a single host even a Raspberry Pi would do with DNS and a web
server.
On the dns have the Microsoft / Apple / google redirect dns domains all
pointing to your Pi for a web server

Then on the web server have a singe page saying the config on your router
is wrong and you need to fix it.

I provided it worked fine and expected in the lab but we never deployed it
into production as no one wanted to fund buying a server for it and we
weren’t allowed to use unsupported hardware such as a Pi in the core.

But that is how you solve it.

On Thu, 25 Jun 2020 at 01:37, Alan DeKok <aland at deployingradius.com> wrote:

> On Jun 24, 2020, at 9:27 AM, Richard J Palmer <richard at merula.net> wrote:
> > I have 'possibly' a slightly odd request - I am sure this can be solved
> with FreeRadius but I'd really appreciate some pointers.
>
>   FreeRADIUS can do almost anything.  v4 will be able to do more. :)
>
> > We are using FreeRadius to authenticate broadband connections reaching
> us via L2TP over a number of providers. So far it works really well and
> I've had a few questions and help from here in the past which I really
> appriciate
>
>   Good to hear.
>
> > Obviously we get some connections reach us with invalid username's or
> wrong passwords.
> >
> > The problem (and which we don't have any control over) is that in the
> case of a wrong username - the customers router etc can simply try
> constantly to log on. Obviously it never connects (as the current design)
> but this obviously causes extra records in postauth and so on.
> >
> > What I'd like to do is
> >
> > 1) user logs on and works (as now)
> > 2) user with wrong login (wrong password / unknown username) - we allow
> this to log on - send a specific reply back that pushes them into a VRF
> which has a walled garden. it should also make the user ad being in an IP
> Pool so it gets an IP from there)
>
>   Sure.  That's relatively common.  Let them on, but push them to a
> blocked VLAN, etc.
>
> > 3) BUT ideally logs this connection as 'failed' OR adds a flag so we can
> see easily that the login was accepted by the above rule - so it's not a
> 'working' session
>
>   You can use the "linelog" module to selectively log bad
> authentications.  i.e.
>
>         if (!known user) {
>                 linelog_bad_user
>         }
>
>   Where you can create a "linelog" module:"
>
> linelog linelog_bad_user {
>         ... stuff to log ...
> }
>
>   And that logs what you want, where you want.
>
>   How to check for an unknown user is up to you.  It depends on a number
> of things.  And no, you can't just do "if (!known_user)".  That's just an
> example.
>
> > The change to radreply - I know and have something we already use for a
> disabled or suspended user,
>
>   i.e. add a custom reply attribute which says "bad user".  This doesn't
> have to be an attribute which is sent to the NAS.  It can just be in
> raddb/dictionary
>
> > I am however after some guidance on how I can allow the user to get an
> 'accept' packet back with the extra reply attribute - and the logging
> information. There's some extra complexity which is this should only be the
> case where I am authenticating on a username with a '@' (realm). Any login
> being authenticated via Calling Station ID or with no realm (just a
> username) should perform as now.
>
>   You can write whatever complex rules you want in "unlang".  :)
>
>         if (User-Name =~ /@/) {
>                 ... check database for known users...
>
>                 if (!known_user) {
>                         linelog_bad_user
>                         put them in a VRF / VLAN / whatever
>                         accept
>                 }
>         }
>         }
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html