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.bu...@lboro.ac.uk [a.l.m.bu...@lboro.ac.uk]
Sent: Wednesday, June 29, 2016 1:09 PM
To: Nadav Hod
Cc: Heikki Vatiainen; radiator@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
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
