Sending authentication-requests to multiple radius-servers
Hello. I have a short question: Is it possible to send an authentication-request from a client to multiple servers simultaneously ? +----------+ /----->| radius A | +--------+ +--------------+ / +----------+ | client |--->| radius proxy |X +--------+ +--------------+ \ +----------+ \----->| radius B | +----------+ We now authenticate with HMAC-based One Time Password Token (aka event-based token) from a Cisco ASA via radius to only one freeradius-server. But we want to establish a second authentication server for failover reasons. When using event based tokens, it's absolute necessary that every server receives the same authentication request simultaneously from the client to trigger the next "event" on the server side. Best Regards, Stefan Kuegler
Stefan Kuegler wrote:
Is it possible to send an authentication-request from a client to multiple servers simultaneously ?
Not really, no.
We now authenticate with HMAC-based One Time Password Token (aka event-based token) from a Cisco ASA via radius to only one freeradius-server. But we want to establish a second authentication server for failover reasons.
That's different.
When using event based tokens, it's absolute necessary that every server receives the same authentication request simultaneously from the client to trigger the next "event" on the server side.
Well.. database synchronization really isn't a RADIUS problem. You're better off fixing the token system so that it works. Alan DeKok.
Some NASes can successfully use several servers. If the first one doesn't respond, the request will be sent to the next RADIUS server On 11/28/2012 4:07 PM, Alan DeKok wrote:
Stefan Kuegler wrote:
Is it possible to send an authentication-request from a client to multiple servers simultaneously ? Not really, no.
We now authenticate with HMAC-based One Time Password Token (aka event-based token) from a Cisco ASA via radius to only one freeradius-server. But we want to establish a second authentication server for failover reasons. That's different.
When using event based tokens, it's absolute necessary that every server receives the same authentication request simultaneously from the client to trigger the next "event" on the server side. Well.. database synchronization really isn't a RADIUS problem. You're better off fixing the token system so that it works.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 28 Nov 2012, at 14:02, Stefan Kuegler <freeradius@kuegler.org> wrote:
Hello.
I have a short question: Is it possible to send an authentication-request from a client to multiple servers simultaneously ?
+----------+ /----->| radius A | +--------+ +--------------+ / +----------+ | client |--->| radius proxy |X +--------+ +--------------+ \ +----------+ \----->| radius B | +----------+
We now authenticate with HMAC-based One Time Password Token (aka event-based token) from a Cisco ASA via radius to only one freeradius-server. But we want to establish a second authentication server for failover reasons.
When using event based tokens, it's absolute necessary that every server receives the same authentication request simultaneously from the client to trigger the next "event" on the server side.
Is there really a requirement for the Authentication-Request to hit simultaneously, or just within a short period of time? Most OTP token systems do have a built in fudge period where the previous token code will still be accepted. If this is the case you should be able to tune failover period so that it occurs within the period and tune the retransmit times on the NAS so that it provides enough requests to trigger the failover. Alternatively you can use multicast. There's some alpha code for v3 which Alan wrote a while back but has not been integrated. It allows you to listen on a multicast IP address for RADIUS packets and would allow you to do what you've described. Let me know if you want to try this and i'll merge it into the main repo. You could also use rlm_replicate to duplicate the packet, but there's currently no way of checking the aliveness of a realm at runtime, so you'd end up sending duplicate requests to whatever the primary OTP server was. -Arran
You could also use rlm_replicate to duplicate the packet, but there's currently no way of checking the aliveness of a realm at runtime, so you'd end up sending duplicate requests to whatever the primary OTP server was.
and that wouldn't help if you were actually wanting to authenticate the user instead of just performing some kind of synchronisation between the OTP servers. -Arran
Hi Arran.
You could also use rlm_replicate to duplicate the packet, but there's currently no way of checking the aliveness of a realm at runtime, so you'd end up sending duplicate requests to whatever the primary OTP server was.
and that wouldn't help if you were actually wanting to authenticate the user instead of just performing some kind of synchronisation between the OTP servers.
Because we don't have any multicast-infrastructure, I will try rlm_replicate. Do you have some information, which files do I have do modify ? Thanks for your help. Stefan
On 29 Nov 2012, at 09:21, Stefan Kuegler <freeradius@kuegler.org> wrote:
Hi Arran.
You could also use rlm_replicate to duplicate the packet, but there's currently no way of checking the aliveness of a realm at runtime, so you'd end up sending duplicate requests to whatever the primary OTP server was.
and that wouldn't help if you were actually wanting to authenticate the user instead of just performing some kind of synchronisation between the OTP servers.
Because we don't have any multicast-infrastructure, I will try rlm_replicate.
You can't setup a VLAN between the OTP servers and the RADIUS server? You don't need all the fancy IGMP/PIM stuff if you can get the devices in the same L2 domain.
Do you have some information, which files do I have do modify ?
Thanks for your help.
Sure, you use the control attribute Proxy-To-Realm to specify multiple realms to replicate to, and then call the replicate module. update control { Replicate-To-Realm := <foo> Replicate-To-Realm += <bar> } replicate Thinking about it you may be able to setup something like: proxy.conf: home_server otp0 { type = acct ipaddr = <foo> port = 1812 secret = <bar> } home_server otp1 { type = acct ipaddr = <foo> port = 1812 secret = <bar> } home_server_pool otp0 { home_server = otp1 home_server = otp0 } home_server_pool otp1 { home_server = otp0 home_server = otp1 } realm otp0 { auth_pool = otp0 } realm otp1 { auth_pool = otp1 } sites-available/default: authorize { update control { Proxy-To-Realm := otp0 Replicate-To-Realm := otp1 } replicate } IIRC home server state is tracked on a per homeserver basis (irrespective of pool), and proxy-to-realm and replicate-to-realm will only replicate to the first alive server in a given pool. So the above *may* do exactly what you want, with the caveat that the replicated packets won't be retransmitted if they're lost. Should work ok in v2.x.x -Arran
Hi Arran.
You could also use rlm_replicate to duplicate the packet, but there's currently no way of checking the aliveness of a realm at runtime, so you'd end up sending duplicate requests to whatever the primary OTP server was.
and that wouldn't help if you were actually wanting to authenticate the user instead of just performing some kind of synchronisation between the OTP servers.
Because we don't have any multicast-infrastructure, I will try rlm_replicate.
You can't setup a VLAN between the OTP servers and the RADIUS server? You don't need all the fancy IGMP/PIM stuff if you can get the devices in the same L2 domain. No, not really. The 2nd server is about 250km away :-)
Sure, you use the control attribute Proxy-To-Realm to specify multiple realms to replicate to, and then call the replicate module.
update control { Replicate-To-Realm := <foo> Replicate-To-Realm += <bar> }
replicate
Thinking about it you may be able to setup something like:
proxy.conf: home_server otp0 { type = acct ipaddr = <foo> port = 1812 secret = <bar> }
home_server otp1 { type = acct ipaddr = <foo> port = 1812 secret = <bar> }
home_server_pool otp0 { home_server = otp1 home_server = otp0 }
home_server_pool otp1 { home_server = otp0 home_server = otp1 }
realm otp0 { auth_pool = otp0 }
realm otp1 { auth_pool = otp1 }
sites-available/default: authorize { update control { Proxy-To-Realm := otp0 Replicate-To-Realm := otp1 }
replicate }
IIRC home server state is tracked on a per homeserver basis (irrespective of pool), and proxy-to-realm and replicate-to-realm will only replicate to the first alive server in a given pool. So the above *may* do exactly what you want, with the caveat that the replicated packets won't be retransmitted if they're lost.
Should work ok in v2.x.x
I will try. Thanks a lot. Stefan
IIRC home server state is tracked on a per homeserver basis (irrespective of pool), and proxy-to-realm and replicate-to-realm will only replicate to the first alive server in a given pool. So the above *may* do exactly what you want, with the caveat that the replicated packets won't be retransmitted if they're lost.
Should work ok in v2.x.x
I will try.
Thanks a lot.
Found/fixed a bug where using rlm_replicate on an authentication request will result in the server skipping the authenticate section. If you want to try this you should use the latest HEAD of the master branch. -Arran
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Marinko Tarlac -
Stefan Kuegler