[RADIATOR] Questions regarding new release and current roadmap

[Nadav Hod]

Hi Alan,

2.5) I probably wasn't clear enough. The include command isn't what I'm looking for since that takes blocks of configuration, not variables, and embeds it in the current configuration. It can't be used to extract a specific variable within that external file. A header file isn't a configuration file which is put into another configuration file, it's just variables and declarations.

I've used Radiator 4.15, and I couldn't use external variables as part of parameters in order to make a generic configuration. What I'm looking for is something like the following:  assume I have an AuthBy LDAP2 clause. I would like to declare:

Host %{GlobalVar:my_ldap_variables.txt::FirstHost}    

In this example my_ldap_variables.txt contains variables bindings for LDAP configurations, FirstHost being one of them.

Something like this, as far as I can tell, isn't possible today. I would need to have FirstHost configured within the local configuration file. 

If I could create a directory on each server that contains files, each of which contain variables relevant to that file, it would make things very easy and manageable. I could put the same Radiator configuration on each server, and just update the variables per server.

Is this possible with Radiator using existing features?


2.6) Password vaults are designed to not only maintain passwords (by a strong complexity policy, frequent generation of new passwords, etc.) but also be physically tamper-proof, provide high availability and be FIPS 140-2 compliant. That's not the same as storing it on a mysql database on a remote machine.

The service running Radiator can be a strong user which needs to know only the hostname of the clients, without the passwords. The passwords can be maintained somewhere else. Yes, passwords will be loaded into RAM during authentication and a more sophisticated attacker can extract these passwords locally if they are local admins, but password vaults update these passwords frequently so that it doesn't really matter. 

I think that allowing a 3rd party solution manage the passwords, assuming that the API exists, could help secure credentials immensely. 

________________________________________
From: A.L.M.Buxey at lboro.ac.uk [A.L.M.Buxey at lboro.ac.uk]
Sent: Wednesday, June 29, 2016 1:09 PM
To: Nadav Hod
Cc: Heikki Vatiainen; radiator at open.com.au
Subject: Re: [RADIATOR] Questions regarding new release and current roadmap

Hi,

> 2.5) A method of synchronizing configuration files (apart from certain variables) across multiple servers. If all Radiator servers have very similar configuration and are distributed for load balancing and redundancy, it's a shame that the configuration needs to be managed and configured separately for each server. There are differences between servers, but the bulk of the configuration can remain the same.
>
> There is 3rd party software such as rsync for synchronizing files, but the variables for each Radiator configuration file have to be within the file itself (as far as I can tell). If the variables could be configured outside of each configuration file, such as a header file, this would allow for synchronizing the configuration files effectively across all servers while still taking into account the differences between each server.

eh???  we do multi server configuration syncing already -  you know that you can just include different files for
each server...using...a headerfile as you say - our radius.cfg contains all local requirements and then pulls in
the local config file for the server.  (in our case we use a database to hold all details, generate the required
new configs for each server then push out to each server)

> 2.6) A more secure method for storing credentials, at the moment they can only be stored locally on the Radiator servers. Perhaps integration with popular 3rd party solutions (such as CyberArk) if their API permits it.

read discussions on the list - if stored elsewhere there are still security issues. what are you hoping to fix/resolve?
you can store configs on a remote DB if there are basic local issues (though anyone with admin access could still read the
DB credentials and then connect to the DB to get hold of config).

alan