[RADIATOR] Multiple secrets per client definition?

[Hugh Irvine]

Hi Leigh, Hi Jacob -

Or you could use a hardware loadbalancer - F5 or whatever.

regards

Hugh


On 19 Apr 2010, at 18:57, Leigh Porter wrote:

> 
> 
> If you could not have multiple secrets here is what I would do:
> 
> Move the current RADIUS server to differant ports.
> Use Linux iptables to do port mapping.
> 
> Setup another RADIUS server on the same host using differant ports with the new secret.
> 
> Then as you move clients to the new secret you can modify iptables to direct traffic fro those clients to the new RADIUS server.
> 
> When all clients are modified, you can then turn off the old server, remove the portmaps and move the new RADIUS server to the original prots.
> 
> --
> Leigh
> 
> 
> On 19/04/10 09:49, Jacob Rohlff wrote:
>> Hi.
>> 
>>  
>> I’ve searched through the mail archive, but haven’t found anything that could help me, I’m sorry if this has already been dealt with.
>> 
>>  
>> We are running Radiator 4.6 on Red Hat Linux.
>> 
>>  
>> Is it possible to have more than one secret per client definition? So if a device uses either of the secrets it will be able to authenticate successfully?
>> 
>>  
>> For example, if you need to change your client secret for some reason (i.e. audit found the secret to be too short or not complex enough) and you want a smooth transition for the devices which are using Radiator to authenticate, allowing them to use either secrets for a while, until all devices use the new secret, then remove the old secret from the Radiator config.
>> 
>> In this case however, the request might just be for the same client definition to allow several secrets.
>> 
>>  
>> Our client definition looks like this:
>> 
>> <Client DEFAULT>
>> 
>>       Secret <something>
>> 
>>       Identifier Default
>> 
>> </Client>
>> 
>>  
>> So every device/client has the same identifier.
>> 
>>  
>> Creating several client definitions to separate the IP subnets would be one way to gradually have the clients use the new secret, however this would still require the Radiator config to be changed at the same time as the client’s radius settings is changed (for the devices in the affected IP subnet).
>> 
>> Is there another practical way to change secret - without the clients losing the ability to authenticate until their radius config is changed?
>> 
>>  
>> Kind regards.
>> 
>> Jacob Rohlff
>> 
>> 
>> _______________________________________________
>> radiator mailing list
>> 
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB: 

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets), 
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.