Freeradius-Users Digest, Vol 141, Issue 32

Sun Jan 15 07:47:04 CET 2017

Hi,

I wasn't to sms otp for covachili captive portal pl help.

On 14 Jan 2017 4:30 p.m., <freeradius-users-request at lists.freeradius.org>
wrote:

> Send Freeradius-Users mailing list submissions to
>         freeradius-users at lists.freeradius.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.freeradius.org/mailman/listinfo/freeradius-users
> or, via email, send a message with subject or body 'help' to
>         freeradius-users-request at lists.freeradius.org
>
> You can reach the person managing the list at
>         freeradius-users-owner at lists.freeradius.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Freeradius-Users digest..."
>
>
> Today's Topics:
>
>    1. RE: access reject problem (Greg Antic)
>    2. Re: access reject problem (Alan DeKok)
>    3. Re: access reject problem (Brian Candler)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 13 Jan 2017 13:33:40 +0000
> From: Greg Antic <greg.antic at stc.za.com>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: RE: access reject problem
> Message-ID: <8cf99a3251f14f2c8980de2e6f36c85f at stc.za.com>
> Content-Type: text/plain; charset="utf-8"
>
> The radpostauth table shows the rejects up until the point that a session
> starts in radacct and then the rejects stop in the radpostauth table, I
> wasn’t clear on that initially below.
>
> When the session arrives in the radacct table the customer goes back
> online like a full successful authentication has taken place.
>
> -----Original Message-----
> From: Freeradius-Users [mailto:freeradius-users-bounces+greg.antic=
> stc.za.com at lists.freeradius.org] On Behalf Of Alan DeKok
> Sent: Friday, 13 January 2017 2:38 PM
> To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
> Subject: Re: access reject problem
>
> On Jan 13, 2017, at 2:18 AM, Greg Antic <greg.antic at stc.za.com> wrote:
> > The user account has been disabled and the auth-type set as per radcheck
> output below. The logs show rejected for many hours and all of a sudden it
> will start a session however the postauth table shows it was rejected. It's
> almost like freeradius gets tired of saying no and eventually gives in and
> says yes.
>
>   That doesn't happen.
>
> > Below the radpostauth shows the continual rejects which it has been
> rejected all day then all of a sudden at 00:02:46 the session starts.
>
>   To be clear, the radpostauth table shows nothing but rejects.  The
> radacct table shows a session.
>
> > Does anyone have an explanation or idea as to why this would occur?
>
>   The NAS is broken.
>
>   What most people don't know is that authentication and accounting are
> entirely separate.  The NAS doesn't need an Access-Accept to start an
> accounting session.  It can just send accounting packets.
>
>   So if the radpostauth table shows nothing but rejects, and there's a
> session in radacct... the NAS is broken.
>
>   If you care to prove it to yourself, do:
>
> $ radsniff -r 'Packet-Type == Access-Accept'
>
>   and leave that running for hours.  You should see nothing being
> printed.  That means the server isn't sending Access-Accept.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 13 Jan 2017 08:47:57 -0500
> From: Alan DeKok <aland at deployingradius.com>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: access reject problem
> Message-ID: <8B8A8337-6D5A-474E-A956-674B194BB210 at deployingradius.com>
> Content-Type: text/plain; charset=utf-8
>
> On Jan 13, 2017, at 8:33 AM, Greg Antic <greg.antic at stc.za.com> wrote:
> >
> > The radpostauth table shows the rejects up until the point that a
> session starts in radacct and then the rejects stop in the radpostauth
> table, I wasn’t clear on that initially below.
>
>   I understand.
>
>   Are you logging Access-Accepts in the radpostauth table?  From the looks
> of it, the answer is either (1) No, or (2) yes, and there are no
> Access-Accepts being sent.
>
> > When the session arrives in the radacct table the customer goes back
> online like a full successful authentication has taken place.
>
>   Please read what I read.  I don't want to think I wasted my time trying
> to help you.
>
>   The NAS is in *complete control* of the user access.  The RADIUS server
> is acting only as an advisor.
>
>   If FreeRADIUS sends an Access-Reject, the NAS may still allow the user
> on... if it's broken.  There is nothing that FreeRADIUS can do about this.
>
>   Again, you need to find out what's happening.  Log Access-Accepts, and
> use radsniff as a double-check.  If FreeRADIUS never sends Access-Accepts
> but the NAS still lets the user on... the NAS is broken.  Throw it in the
> garbage, and buy a new one.
>
>   There is just no situation possible where FreeRADIUS magically returns
> an Access-Accept.  There *are* situations possible where a NAS is broken.
> Or where a NAS has a "fail to accept" VLAN, and lets the user on when the
> server returns a reject, or is unresponsive.
>
>   Alan DeKok.
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 13 Jan 2017 14:13:20 +0000
> From: Brian Candler <b.candler at pobox.com>
> To: Greg Antic <greg.antic at stc.za.com>,
>         "freeradius-users at lists.freeradius.org"
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: access reject problem
> Message-ID: <8b5ca053-3a61-0a6c-f17c-7b97422ecdd1 at pobox.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 13/01/2017 12:19, Greg Antic wrote:
> >> Firstly, do you have a log which shows that FreeRADIUS actually
> returned Access-Accept? Turning on auth detail logging may help here - or
> better, capture all the radius traffic with tcpdump.
> > I can see the start radius packet in the NAS log, I will look at detail
> logging and packet capture.
> When you say "start", do you mean an Accounting-Start packet sent by the
> NAS?
>
> Then that doesn't answer my question of whether FreeRadius returned
> Access-Accept or Access-Reject to the authentication request.
>
> It would be really weird if a NAS receives Access-Reject and still goes
> ahead and starts the session anyway.  However it would be equally weird
> if FreeRADIUS were to send Access-Accept even though you have set
> Auth-Type := Reject.  You need to prove one way or another what's going on.
>
> >
> > When our mysql connection is "offline" nobody can authenticate to get a
> session. I had a look through the config files but can't see where you
> would set an implicit reject or default action? We use mysql on the same
> box so all connections are local.
>
> OK, so it sounds like you're not using configurable failover.
>
> The behaviour I mentioned is implicit. In your "authorize" section I
> expect you have something like this:
>
>      ...
>      sql
>      ...
>
> Every module can return one of a number of return codes. FreeRADIUS has
> a default action associated with each return code:
>
>        notfound = 1
>        noop     = 2
>        ok       = 3
>        updated  = 4
>        fail     = return
>        reject   = return
>        userlock = return
>        invalid  = return
>        handled  = return
>
> What this means is, for example, a status of "fail" will cause the
> authorize block to return immediately. A status of "notfound", "noop",
> "ok" or "updated" will continue onto the next module in the block,
> remembering the associated priority value.  If execution continues to
> the very end of the block, then the final result code used is the one
> with the priority value.
>
> In the case of the sql module, if it failed to communicate with the
> backend server, you'd get a "fail" response and your authorize section
> would terminate at that point (fail = return).
>
> But a more sophisticated configuration would override these defaults so
> for example it would try a second sql instance. In that case, "fail" is
> no longer a hard error response from the mysql module.
>
> The details are in doc/configuration/configurable_failover.rst in the
> freeradius source.
>
> Regards,
>
> Brian.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html
>
> ------------------------------
>
> End of Freeradius-Users Digest, Vol 141, Issue 32
> *************************************************
>