Dropping requests when no authentication possible
Hi, I've set up a 2.1.4 server, and working pretty well with authentication against LDAP alone. What I've noticed though is that if the LDAP server is down on the same box then the LDAP module, rightfully, fails. However whilst this leaves the service unable to authenticate the user, it still replies back with a REJECT packet to the client. As such the client switch / router whatever, doesn't try the next server in it's config, as it's had a valid RADIUS response. Is there any way to force a logic whereby if the ldap module fails, it would drop the RADIUS request on the floor, to make it look like a service failure to the client? Kinda wrecks our resiliency model if not! We're only using a single ldap server per box, but even if we were using other ldap servers on other servers, there still is a logic whereby it may be impossible to reach any LDAP server whilst another FreeRADIUS box can reach one, but is of a lower order of preference so can't be used. Thanks Chris
I've set up a 2.1.4 server, and working pretty well with authentication against LDAP alone. What I've noticed though is that if the LDAP server is down on the same box then the LDAP module, rightfully, fails. However whilst this leaves the service unable to authenticate the user, it still replies back with a REJECT packet to the client. As such the client switch / router whatever, doesn't try the next server in it's config, as it's had a valid RADIUS response.
Is there any way to force a logic whereby if the ldap module fails, it would drop the RADIUS request on the floor, to make it look like a service failure to the client?
Read the list. There is another thread about the same "problem". Only about unreachable sql servers. Ivan Kalik Kalik Informatika ISP
On Thu, Mar 12, 2009 at 4:33 PM, <tnt@kalik.net> wrote:
I've set up a 2.1.4 server, and working pretty well with authentication against LDAP alone. What I've noticed though is that if the LDAP server is down on the same box then the LDAP module, rightfully, fails. However whilst this leaves the service unable to authenticate the user, it still replies back with a REJECT packet to the client. As such the client switch / router whatever, doesn't try the next server in it's config, as it's had a valid RADIUS response.
Is there any way to force a logic whereby if the ldap module fails, it would drop the RADIUS request on the floor, to make it look like a service failure to the client?
Read the list. There is another thread about the same "problem". Only about unreachable sql servers.
Ivan Kalik Kalik Informatika ISP
Quite a coincidence, I was looking at the weekend and could find nothing. I'll try having a go at the example in the sql thread: authorize { ... redundant_sql if (fail) { update control { # Do-Not-Respond Response-Packet-Type = 256 } reject } elsif (notfound) { reject } } And respond back one way or another. Thanks Chris
Hi,
Is there any way to force a logic whereby if the ldap module fails, it would drop the RADIUS request on the floor, to make it look like a service failure to the client? Kinda wrecks our resiliency model if not! We're only using a single ldap server per box, but even if we were using other ldap servers on other servers, there still is a logic whereby it may be impossible to reach any LDAP server whilst another FreeRADIUS box can reach one, but is of a lower order of preference so can't be used.
seems to be a current popular feature. if you read the mialing list archive this veyr minth theres a similar case for doing pretty much the same with SQL (insteda of your ldap). you could, perhaps not need to do this if you let each RADIUS server also talk to each LDAP. you can then configure LDAP as a failover/redundant system (see the guides/docs for doing redundant LDAP). so RADIUS1 - ldap 1, ldap 2, ldap 3 RADIUS2 - ldap 2, ldap 1, ldap 3 RADIUS3 - ldap 3, ldap 2, ldap 1 if they can share their LDAP this would be ideal... however, if not, then you'll have to use the method mentioned previously on the list - note the (fail) and return the fail attribute to the NAS rather than reject. if the NAS is good/proper, it'll try the next RADIUS itself. alan
On Thu, Mar 12, 2009 at 5:07 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Is there any way to force a logic whereby if the ldap module fails, it would drop the RADIUS request on the floor, to make it look like a service failure to the client? Kinda wrecks our resiliency model if not! We're only using a single ldap server per box, but even if we were using other ldap servers on other servers, there still is a logic whereby it may be impossible to reach any LDAP server whilst another FreeRADIUS box can reach one, but is of a lower order of preference so can't be used.
seems to be a current popular feature. if you read the mialing list archive this veyr minth theres a similar case for doing pretty much the same with SQL (insteda of your ldap). you could, perhaps not need to do this if you let each RADIUS server also talk to each LDAP. you can then configure LDAP as a failover/redundant system (see the guides/docs for doing redundant LDAP). so
RADIUS1 - ldap 1, ldap 2, ldap 3 RADIUS2 - ldap 2, ldap 1, ldap 3 RADIUS3 - ldap 3, ldap 2, ldap 1
if they can share their LDAP this would be ideal... however, if not, then you'll have to use the method mentioned previously on the list - note the (fail) and return the fail attribute to the NAS rather than reject. if the NAS is good/proper, it'll try the next RADIUS itself.
Well they can share the LDAP servers, but if these servers have 2 nics, 1 for RADIUS access and 1 solely for back end access between RADIUS and LDAP, and this rear network connection fails then this scenario comes back big style and there's not much ideal about it. Whilst it's no fault specifically of its own, that RADIUS server is completely useless, and no client device of mine would try the second ever whilst it's getting nice and polite REJECT's back. I'll be checking out that other sql thread, although at the moment it seems that it's not working for the other guy... Cheers Chris
Chris Phillips wrote:
I've set up a 2.1.4 server, and working pretty well with authentication against LDAP alone. What I've noticed though is that if the LDAP server is down on the same box then the LDAP module, rightfully, fails. However whilst this leaves the service unable to authenticate the user, it still replies back with a REJECT packet to the client. As such the client switch / router whatever, doesn't try the next server in it's config, as it's had a valid RADIUS response.
Ah... if both ldap modules fail, then the redundant{} section returns fail, and the request stops being processed.
Is there any way to force a logic whereby if the ldap module fails, it would drop the RADIUS request on the floor, to make it look like a service failure to the client? Kinda wrecks our resiliency model if not! We're only using a single ldap server per box, but even if we were using other ldap servers on other servers, there still is a logic whereby it may be impossible to reach any LDAP server whilst another FreeRADIUS box can reach one, but is of a lower order of preference so can't be used.
Try: authorize { ... redundant { redundant { ldap1 ldap2 } group { update control { Response-Packet-Type = Do-Not-Respond } ok } } } That should work better... The outer "redundant" block says: try the first "redundant" block. if it fails, try the "group" block The inner "redundant" block says: try ldap1 if it fails, try ldap2 if it fails, return fail The inner "group" block says: update the control list so that the server doesn't respond force an "OK" return code I don't have time to try this now... but if it works, we can put a sample in the default configuration. Alan DeKok.
On Fri, Mar 13, 2009 at 8:13 AM, Alan DeKok <aland@deployingradius.com>wrote:
Chris Phillips wrote:
I've set up a 2.1.4 server, and working pretty well with authentication against LDAP alone. What I've noticed though is that if the LDAP server is down on the same box then the LDAP module, rightfully, fails. However whilst this leaves the service unable to authenticate the user, it still replies back with a REJECT packet to the client. As such the client switch / router whatever, doesn't try the next server in it's config, as it's had a valid RADIUS response.
Ah... if both ldap modules fail, then the redundant{} section returns fail, and the request stops being processed.
Is there any way to force a logic whereby if the ldap module fails, it would drop the RADIUS request on the floor, to make it look like a service failure to the client? Kinda wrecks our resiliency model if not! We're only using a single ldap server per box, but even if we were using other ldap servers on other servers, there still is a logic whereby it may be impossible to reach any LDAP server whilst another FreeRADIUS box can reach one, but is of a lower order of preference so can't be used.
Try:
authorize { ... redundant { redundant { ldap1 ldap2 }
group { update control { Response-Packet-Type = Do-Not-Respond }
ok } } }
That should work better...
The outer "redundant" block says:
try the first "redundant" block. if it fails, try the "group" block
The inner "redundant" block says:
try ldap1 if it fails, try ldap2 if it fails, return fail
The inner "group" block says:
update the control list so that the server doesn't respond force an "OK" return code
I don't have time to try this now... but if it works, we can put a sample in the default configuration.
Alan DeKok.
Thanks Alan, here's where I've ended up so far... Fri Mar 13 09:57:22 2009 : Error: rlm_ldap: (re)connection attempt failed Fri Mar 13 09:57:22 2009 : Info: [ldap] search failed Fri Mar 13 09:57:22 2009 : Debug: rlm_ldap: ldap_release_conn: Release Id: 0 Fri Mar 13 09:57:22 2009 : Info: +++[ldap] returns fail Fri Mar 13 09:57:22 2009 : Info: +++- entering group {...} Fri Mar 13 09:57:22 2009 : Info: ++++[control] returns fail Fri Mar 13 09:57:22 2009 : Info: ++++[ok] returns ok Fri Mar 13 09:57:22 2009 : Info: +++- group returns ok Fri Mar 13 09:57:22 2009 : Info: ++- policy redundant returns ok Fri Mar 13 09:57:22 2009 : Info: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user Fri Mar 13 09:57:22 2009 : Info: Failed to authenticate the user. Fri Mar 13 09:57:22 2009 : Auth: Login incorrect: [fbloggs] (from client my-switch port 0 cli 10.10.10.10) Fri Mar 13 09:57:22 2009 : Info: Using Post-Auth-Type Reject Fri Mar 13 09:57:22 2009 : Info: +- entering group REJECT {...} Fri Mar 13 09:57:22 2009 : Info: [attr_filter.access_reject] expand: %{User-Name} -> fbloggs Fri Mar 13 09:57:22 2009 : Debug: attr_filter: Matched entry DEFAULT at line 11 Fri Mar 13 09:57:22 2009 : Info: ++[attr_filter.access_reject] returns updated Fri Mar 13 09:57:22 2009 : Info: Delaying reject of request 1 for 1 seconds Fri Mar 13 09:57:22 2009 : Debug: Going to the next request Fri Mar 13 09:57:22 2009 : Debug: Waking up in 0.9 seconds. Fri Mar 13 09:57:23 2009 : Info: Sending delayed reject for request 1 Sending Access-Reject of id 142 to 10.20.30.40 port 32776
From this code...
authorize { preprocess auth_log chap mschap files redundant { ldap group { update control { Response-Packet-Type = Do-Not-Respond } ok } } } As the group returns ok, the Response-Packet-Type is presumably being executed fine, but still that reject is coming out of the bottom of all of it... any clues? all other sections in the sites-enabled/default file are default. Could something elsewhere be overriding it? Thanks Chris
Thanks Alan, here's where I've ended up so far...
Fri Mar 13 09:57:22 2009 : Error: rlm_ldap: (re)connection attempt failed Fri Mar 13 09:57:22 2009 : Info: [ldap] search failed Fri Mar 13 09:57:22 2009 : Debug: rlm_ldap: ldap_release_conn: Release Id: 0
Fri Mar 13 09:57:22 2009 : Info: +++[ldap] returns fail Fri Mar 13 09:57:22 2009 : Info: +++- entering group {...} Fri Mar 13 09:57:22 2009 : Info: ++++[control] returns fail Fri Mar 13 09:57:22 2009 : Info: ++++[ok] returns ok Fri Mar 13 09:57:22 2009 : Info: +++- group returns ok
That sets Do-Not-Respond ...
Fri Mar 13 09:57:22 2009 : Info: ++- policy redundant returns ok Fri Mar 13 09:57:22 2009 : Info: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
.. but that puts it to Access-Reject.
From this code...
authorize { preprocess auth_log chap mschap files redundant { ldap group { update control { Response-Packet-Type = Do-Not-Respond
Try changing that to Tmp-String-0 := "silent"
} ok } } }
And than add to Post-Auth-Type REJECT: if(control:Tmp-String-0 == "silent") { update control { Response-Packet-Type := 256 } } Ivan Kalik Kalik Informatika ISP
Response-Packet-Type = Do-Not-Respond
Try changing that to Tmp-String-0 := "silent"
And than add to Post-Auth-Type REJECT:
if(control:Tmp-String-0 == "silent") { update control { Response-Packet-Type := 256 } }
Ivan Kalik Kalik Informatika ISP
I can see the logic there, but the packet still exists. I can't see any evidence of this Response-Packet-Type having any notable impact at all. Fri Mar 13 12:07:30 2009 : Error: rlm_ldap: (re)connection attempt failed Fri Mar 13 12:07:30 2009 : Info: [ldap] search failed Fri Mar 13 12:07:30 2009 : Debug: rlm_ldap: ldap_release_conn: Release Id: 0 Fri Mar 13 12:07:30 2009 : Info: +++[ldap] returns fail Fri Mar 13 12:07:30 2009 : Info: +++- entering group {...} Fri Mar 13 12:07:30 2009 : Info: ++++[control] returns fail Fri Mar 13 12:07:30 2009 : Info: +++- group returns fail Fri Mar 13 12:07:30 2009 : Info: ++- policy redundant returns fail Fri Mar 13 12:07:30 2009 : Auth: Invalid user: [fbloggs] (from client my-switch port 0 cli 10.10.10.10) Fri Mar 13 12:07:30 2009 : Info: Using Post-Auth-Type Reject Fri Mar 13 12:07:30 2009 : Info: +- entering group REJECT {...} Fri Mar 13 12:07:30 2009 : Info: ++? if (control:Tmp-String-0 == "silent") Fri Mar 13 12:07:30 2009 : Info: ? Evaluating (control:Tmp-String-0 == "silent") -> TRUE Fri Mar 13 12:07:30 2009 : Info: ++? if (control:Tmp-String-0 == "silent") -> TRUE Fri Mar 13 12:07:30 2009 : Info: ++- entering if (control:Tmp-String-0 == "silent") {...} Fri Mar 13 12:07:30 2009 : Info: +++[control] returns noop Fri Mar 13 12:07:30 2009 : Info: ++- if (control:Tmp-String-0 == "silent") returns noop Fri Mar 13 12:07:30 2009 : Info: Delaying reject of request 1 for 1 seconds Fri Mar 13 12:07:30 2009 : Debug: Going to the next request Fri Mar 13 12:07:30 2009 : Debug: Waking up in 0.9 seconds. Fri Mar 13 12:07:31 2009 : Info: Sending delayed reject for request 1 Sending Access-Reject of id 4 to 10.20.30.40 port 32776 authorize { preprocess auth_log chap mschap files redundant { ldap group { update control { Tmp-String-0 := "silent" } } } } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject if (control:Tmp-String-0 == "silent") { update control { Response-Packet-Type := Do-Not-Respond } } } } Thanks Chris
Chris Phillips wrote:
Fri Mar 13 09:57:22 2009 : Info: +++[ldap] returns fail Fri Mar 13 09:57:22 2009 : Info: +++- entering group {...} Fri Mar 13 09:57:22 2009 : Info: ++++[control] returns fail Fri Mar 13 09:57:22 2009 : Info: ++++[ok] returns ok Fri Mar 13 09:57:22 2009 : Info: +++- group returns ok Fri Mar 13 09:57:22 2009 : Info: ++- policy redundant returns ok
So that works.
Fri Mar 13 09:57:22 2009 : Info: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
Ok. Change the "update" block to: update control { Response-Packet-Type = Do-Not-Respond Auth-Type := Accept } I think that will finally work. But if the client re-transmits... the server will respond with a packet of code 0. I've fixed that in git. (Give me a bit to push the change publicly). So you'll still need to update in order to have this perfect. Alan DeKok.
Fri Mar 13 09:57:22 2009 : Info: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
Ok. Change the "update" block to:
update control { Response-Packet-Type = Do-Not-Respond Auth-Type := Accept }
I think that will finally work.
But if the client re-transmits... the server will respond with a packet of code 0. I've fixed that in git. (Give me a bit to push the change publicly). So you'll still need to update in order to have this perfect.
Alan DeKok.
We're close, I can really feel it, but that packet is still hitting the wire. Fri Mar 13 13:26:01 2009 : Error: rlm_ldap: (re)connection attempt failed Fri Mar 13 13:26:01 2009 : Info: [ldap] search failed Fri Mar 13 13:26:01 2009 : Debug: rlm_ldap: ldap_release_conn: Release Id: 0 Fri Mar 13 13:26:01 2009 : Info: +++[ldap] returns fail Fri Mar 13 13:26:01 2009 : Info: +++- entering group {...} Fri Mar 13 13:26:01 2009 : Info: ++++[control] returns fail Fri Mar 13 13:26:01 2009 : Info: ++++[ok] returns ok Fri Mar 13 13:26:01 2009 : Info: +++- group returns ok Fri Mar 13 13:26:01 2009 : Info: ++- policy redundant returns ok Fri Mar 13 13:26:01 2009 : Info: Found Auth-Type = Accept Fri Mar 13 13:26:01 2009 : Info: Auth-Type = Accept, accepting the user Fri Mar 13 13:26:01 2009 : Auth: Login OK: [fbloggs] (from client my-switch port 0 cli 10.10.10.10) Fri Mar 13 13:26:01 2009 : Info: +- entering group post-auth {...} Fri Mar 13 13:26:01 2009 : Info: ++[exec] returns noop Sending Access-Accept of id 242 to 10.20.30.40 port 32771 authorize { preprocess auth_log chap mschap files redundant { ldap group { update control { Response-Packet-Type := Do-Not-Respond Auth-Type := Accept } ok } } } Thanks Chris
On Fri, Mar 13, 2009 at 1:43 PM, Alan DeKok <aland@deployingradius.com>wrote:
Chris Phillips wrote:
We're close, I can really feel it, but that packet is still hitting the wire.
Hmm... then I think the functionality will need someone to write a bit more code
Thanks, frustrating this, maybe I'll need to revert to ideas about a cron job to do some housekeeping checks... Is there an angle to filter out the Access-Type field in the packet that gets sent back? Would a useless packet have the same effect as no packet at all? Thanks Chris
Chris Phillips wrote:
Thanks, frustrating this, maybe I'll need to revert to ideas about a cron job to do some housekeeping checks...
One more thought: authorize { ... redundant { redundant { ldap1 ldap2 } group { update control { Response-Packet-Type = Do-Not-Respond } handled # i.e. not "ok" } } ... } The "handled" return code says "stop processing right now..."
Is there an angle to filter out the Access-Type field in the packet that gets sent back? Would a useless packet have the same effect as no packet at all?
What's Access-Type? Alan DeKok.
On Sat, Mar 14, 2009 at 8:08 AM, Alan DeKok <aland@deployingradius.com>wrote:
Chris Phillips wrote:
Thanks, frustrating this, maybe I'll need to revert to ideas about a cron job to do some housekeeping checks...
One more thought:
authorize { ... redundant { redundant { ldap1 ldap2 }
group { update control { Response-Packet-Type = Do-Not-Respond }
handled # i.e. not "ok" } } ... }
The "handled" return code says "stop processing right now..."
Yahooooooo! that's the one! Debug instantly said that it will stop processing the request and no response is to be sent. Brilliant.
Is there an angle to filter out the Access-Type field in the packet that gets sent back? Would a useless packet have the same effect as no packet at all?
What's Access-Type?
It's me not remembering RADIUS correctly. I just wondered if it was possible to send a packet back that was not an accept, reject or anything useful at all. Irrelevant now anyway, thanks for your help. Chris
Chris Phillips wrote:
Yahooooooo! that's the one! Debug instantly said that it will stop processing the request and no response is to be sent. Brilliant.
OK. In order for this to work properly, you WILL need to grab the latest "stable" branch from git.freeradius.org. It has another fix that prevents the server from responding on client re-transmits. I've also added a sample policy in raddb/policy.conf. You can now do: ... redundant { ldap1 do_not_respond } ... Which says "if ldap1 fails, do not respond" That's a lot easier to understand. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Chris Phillips -
tnt＠kalik.net