access reject problem

Brian Candler b.candler at pobox.com
Fri Jan 13 15:13:20 CET 2017


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.


More information about the Freeradius-Users mailing list