access reject problem
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
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:
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
More information about the Freeradius-Users