Re: Authentication Responses during error conditions
I am a bit confused now. I understood that if a module returns RLM_MODULE_FAIL that radiusd would not return an authorization reject. However, it appears that it still does. rad_recv: Access-Request packet from host 127.0.0.1:53579, id=193, length=71 User-Name = "visitor" User-Password = "asdfjkle" Called-Station-Id = "8053342021" Calling-Station-Id = "3232546586" rad_lowerpair: User-Name now 'visitor' Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 hints: Matched DEFAULT at 59 modcall[authorize]: module "preprocess" returns ok for request 0 users: Matched entry visitor at line 51 modcall[authorize]: module "files" returns ok for request 0 rlm_lafn: Found USER_NAME rlm_lafn: Found NAS rlm_lafn: Found Calling ID rlm_lafn: Found Called ID rlm_lafn: Found Hint get_time returns 60 Unable to connect to 0: Can't connect to MSQL server on 0 modcall[authorize]: module "lafn" returns fail for request 0 modcall: group authorize returns fail for request 0 There was no response configured: rejecting request 0 Server rejecting request 0. Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 193 to 127.0.0.1:53579 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 193 with timestamp 42e96be9 Nothing to do. Sleeping until we see a request. zool# ./visitor Received response ID 193, code 3, length = 20 From radiusd.conf: # Authorization. First preprocess (hints and huntgroups files), authorize { preprocess files lafn }
Doug Hardie <bc979@lafn.org> wrote:
I am a bit confused now. I understood that if a module returns RLM_MODULE_FAIL that radiusd would not return an authorization reject. However, it appears that it still does.
RADIUS servers are supposed to return Access-Reject's for Access-Accepts, rather than just dropping the packets.
modcall: group authorize returns fail for request 0 There was no response configured: rejecting request 0
That's what the server does. If the server *requires* a back-end DB, and that DB is down, then arguable the server can pretend it's down, too. Alan DeKok.
On Jul 28, 2005, at 17:09, Alan DeKok wrote:
RADIUS servers are supposed to return Access-Reject's for Access-Accepts, rather than just dropping the packets.
If the server *requires* a back-end DB, and that DB is down, then arguable the server can pretend it's down, too.
I am trying to get the Ascend NASs to switch to the secondary radius server when the primary has a failure condition. I know that no response will cause that, but haven't been able to find any way to make the switch occur with the primary is not working properly. Is there a particular value to send back that would cause the switch?
Doug Hardie wrote:
I am trying to get the Ascend NASs to switch to the secondary radius server when the primary has a failure condition. I know that no response will cause that, but haven't been able to find any way to make the switch occur with the primary is not working properly. Is there a particular value to send back that would cause the switch?
You should setup both your radius servers with 2 database backends in failover, so that if one db is down, both radius servers can still handle things. If freeradius itself is down or the complete host is down, then the NAS should switch to the other radius server. Maybe your NAS can also do round-robin for load-balancing. -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
Doug Hardie <bc979@lafn.org> wrote:
I am trying to get the Ascend NASs to switch to the secondary radius server when the primary has a failure condition. I know that no response will cause that, but haven't been able to find any way to make the switch occur with the primary is not working properly. Is there a particular value to send back that would cause the switch?
doc/configurable_failover. Use "rlm_always", and have it return "handled" in the "authorize" section. It may work. Then again, I think the server core always answers requests. Fixing that would require code changes. Alan DeKok.
Doug Hardie wrote:
I am a bit confused now. I understood that if a module returns RLM_MODULE_FAIL that radiusd would not return an authorization reject. However, it appears that it still does.
Have a look at doc/configurable-failover -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
participants (3)
-
Alan DeKok -
Doug Hardie -
Thor Spruyt