Hi, I wasn't to sms otp for covachili captive portal pl help. On 14 Jan 2017 4:30 p.m., <freeradius-users-request@lists.freeradius.org> wrote:
Send Freeradius-Users mailing list submissions to freeradius-users@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@lists.freeradius.org
You can reach the person managing the list at freeradius-users-owner@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@stc.za.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: RE: access reject problem Message-ID: <8cf99a3251f14f2c8980de2e6f36c85f@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@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, 13 January 2017 2:38 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: access reject problem
On Jan 13, 2017, at 2:18 AM, Greg Antic <greg.antic@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@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: access reject problem Message-ID: <8B8A8337-6D5A-474E-A956-674B194BB210@deployingradius.com> Content-Type: text/plain; charset=utf-8
On Jan 13, 2017, at 8:33 AM, Greg Antic <greg.antic@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@pobox.com> To: Greg Antic <greg.antic@stc.za.com>, "freeradius-users@lists.freeradius.org" <freeradius-users@lists.freeradius.org> Subject: Re: access reject problem Message-ID: <8b5ca053-3a61-0a6c-f17c-7b97422ecdd1@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 *************************************************