[RADIATOR] Multiple secrets per client definition?

Hugh Irvine hugh at open.com.au
Mon Apr 19 05:29:34 CDT 2010


Hello Jacob -

No this is not possible.

The only suggestion I can make is to have individual Client clauses for each NAS device and change the secrets together.

Otherwise, some NAS devices allow different RADIUS targets to be defined for different purposes, so you could run two different Radiator configurations on different port numbers, and migrate the NAS devices by pointing them at the second Radiator instance with the new secret(s).

regards

Hugh


On 19 Apr 2010, at 18: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



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.





More information about the radiator mailing list