[RADIATOR] Multiple secrets per client definition?

[Raphael Luta]

Jacob,

If you have some control on your NAS migration, you can have a sort of "auto-migrating" setup:

For example, assuming you can use a MySQL 5 server with the default Radiator SQL schema:

<Client DEFAULT>
	Secret <oldsecret>
</Client>

<ClientListSQL>
	DbSource   <db_dsn>
	DbUsername <db_user>
	DbAuth     <db_pass>
	RefreshPeriod 600 # Only set that low during your migration period, it will impact your perf
</ClientListSQL>

<Handler>
	<AuthBy WHATEVER>
	</AuthBy>
	<AuthLog SQL>
		DbSource   <db_dsn>
		DbUsername <db_user>
		DbAuth     <db_pass>

		LogSuccess 0
		LogFailure 1

		FailureQuery insert into RADCLIENTLIST (NASIDENTIFIER,SECRET) select "%c","<newsecret>" from (select %u as name) as user where user.name = '<mymigrationuser>' 
	</AuthLog>
</Handler>

Basically the idea is to start with a DEFAULT client clause associated with the old password but whenever a new NAS is migrated, the first auth attempt needs to be done with a specific marker user like 'migrationtest' that doesn't exist in your main database.
Since the authenticator will not match, the auth will always fail, the AuthLog clause will catch the failure and the FailureQuery will actually update the client list and associate the NAS with your new secret. One RefreshPeriod later your NAS is automatically up and running with the new secret.

(A cleaner implementation would be to write a stored proc in MySQL that correctly handles all cases instead of that ugly INSERT that is expected to fail whenever you don't actually want to write in the RADCLIENTLIST table...).

-- raphael

Le 19 avr. 2010 à 12:29, Hugh Irvine a écrit :

> 
> 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.
> 
> 
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
> 

Raphael Luta
raphael.luta at aptiwan.com