Re: [RADIATOR] New features and changes in the next Radiator release
That are *great* news! Especially the work on sharing state between instances, we had problems with tacacs sessions from Cisco WLCs that authorize on a different server than the authentication happened which lead to non-working user rights. Regarding logging I'd love to see support for noSQL databases and messages queues like RabbitMQ and Elasticsearch which can be used as log target. I think those features justify a new version, maybe even a major one. Thanks, Alex On 2015-06-18 10:29, Heikki Vatiainen wrote: > There are a number of new features and changes in the current Radiator > 4.14 patches we thought might be of interest for the list members. > > Any comments and questions are welcome. > > > Windows Eventlog logging > > New modules AuthLog EVENTLOG and Log EVENTLOG are now included. See > goodies/eventlog.cfg for instructions and more information about DLLs > that are useful, but not required, to set up eventlog. There are both > sources and precompiled binaries for the DLLs in goodies. > > > Clustering control plane support with Gossip framework > ++ > Gossip [1] framework with Redis based implementation was recently added > in patches. The purpose of the framework is to allow individual Radiator > instances to share information between each other. > > For example, server farm members can use Gossip to relay next hop proxy > unreachability/reachability information to each other. This allows > faster recovery from failures and other events as opposed to each > instance doing detection and recovery individually. > > The patches have an implementation for this. Radiator instances, not > restricted to just farm members, can share next hop proxy status > information based on Status-Server or lack of responses to normal > requests. In addition, a farm can be configured so that Status-Server is > run by only one member whose responsibility is to send reachability > updates to the other members via Gossip. > > The future uses may include distributing TACACS+ authorisation > information, TLS session tickets, configuration updates or anything a > custom Radiator installation may require. > > > TLS updates > +++ > TLS and SSL configuration options for TLS based EAP methods and TLS > enabled stream protocol modules, RadSec, Diameter, ServerHTTP, etc., > have been updated. > > New configuration parameters EAPTLS_Ciphers and TLS_Ciphers allows > defining the supported ciphersuites. The current default for the both is > 'DEFAULT:!EXPORT:!LOW'. This should provide the least amount of suprises > when upgrading. > > New configuration parameters EAPTLS_TLS_Protocols and TLS_Protocols are > available for defining which TLS versions (or SSLv3) to support. > > When TLS_Protocols is defined, it overrides UseTLS and UseSSL. > EAPTLS_Protocols is available for restricting supported TLS versions for > TLS based EAP methods. The default is to support all available TLS versions. > > A useful resource for TLS configuration is for example the Mozilla TLS > server guide [2] > > > Server farm > +++ > Server farm users may be interested in the possibility to use shared > memory for duplicate cache. With this parameter, the > UseContentsForDuplicateDetection parameter is no longer needed. > > > Structured logging > ++ > New module LogFormat.pm has examples of how to format Radiator log and > authentication log messages in JSON and CEF (ArcSight Common Event > Format) formats. Configuration sample goodies/logformat.cfg has more > information about how to create a custom module for your local logging > requirements. > > > > [1] https://en.wikipedia.org/wiki/Gossip_protocol > [2] https://wiki.mozilla.org/Security/Server_Side_TLS > *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] New features and changes in the next Radiator release
On 06/18/2015 01:01 PM, Hartmaier Alexander wrote: > Especially the work on sharing state between instances, we had problems > with tacacs sessions from Cisco WLCs that authorize on a different > server than the authentication happened which lead to non-working user > rights. Thanks for your comments. Does WLC do this when it has been configured with multiple TACACS+ servers? That is, it does not try to use the same server for all requests that belong to the user's session even if that server is responding? I'll make a note that this is one case where state sharing would be needed for TACACS+. > Regarding logging I'd love to see support for noSQL databases and > messages queues like RabbitMQ and Elasticsearch which can be used as log > target. I would be interested to hear your and others' views about how to work with different noSQL DBs and how they should be used with Radiator. For example, there has been interest in Apache Cassandra for AuthBy CQL, AuthLog CQL, session database etc. With SQL we can use DBI to cover all the SQL databases. With noSQL it seems each noSQL server needs its own interface. Or in other words, if support for them is done one by one, which noSQL servers should be supported first? For example MongoDB has good Perl support and is widely used, but CQL seems to be a good, maybe better, match for this type of application. Amazon Dynamo DB is, of course, restricted to AWS (and has been used by us in one custom setup). What comes to Elasticsearch, would using Logstash to read the files while they are generated do the trick, at least for now? About message queues, are you thinking about RabbitMQ, or the other MQs, for logging only? I mentioned control plane in my previous message, but we are also thinking about data plane to have something to distribute requests between different instances. Pushing logs in a MQ could also be done too. Using both control and data plane is interesting because it allows for more automatic and easier set up of multiple instances as opposed to creating configuration files manually. A queue can be monitored to see if the instances are starting to have problems processing all the requests. If this happens, the queue management can log the problem or start additional instances. Other useful features include log routing, as you mentioned, maybe as a control plane service too. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] New features and changes in the next Radiator release
On 2015-06-19 09:16, Heikki Vatiainen wrote: > On 06/18/2015 01:01 PM, Hartmaier Alexander wrote: > >> Especially the work on sharing state between instances, we had problems >> with tacacs sessions from Cisco WLCs that authorize on a different >> server than the authentication happened which lead to non-working user >> rights. > Thanks for your comments. Does WLC do this when it has been configured > with multiple TACACS+ servers? That is, it does not try to use the same > server for all requests that belong to the user's session even if that > server is responding? Yes, sadly. > > I'll make a note that this is one case where state sharing would be > needed for TACACS+. > >> Regarding logging I'd love to see support for noSQL databases and >> messages queues like RabbitMQ and Elasticsearch which can be used as log >> target. > I would be interested to hear your and others' views about how to work > with different noSQL DBs and how they should be used with Radiator. > > For example, there has been interest in Apache Cassandra for AuthBy CQL, > AuthLog CQL, session database etc. > > With SQL we can use DBI to cover all the SQL databases. With noSQL it > seems each noSQL server needs its own interface. Or in other words, if > support for them is done one by one, which noSQL servers should be > supported first? For example MongoDB has good Perl support and is widely > used, but CQL seems to be a good, maybe better, match for this type of > application. Amazon Dynamo DB is, of course, restricted to AWS (and has > been used by us in one custom setup). > > What comes to Elasticsearch, would using Logstash to read the files > while they are generated do the trick, at least for now? We use a Perl daemon based on Message::Passing to read from a special fifo file generated with mkfifo and enqueue the log messages in RabbitMQ from where they are stored in Elasticsearch by another damon on the central log servers. > > About message queues, are you thinking about RabbitMQ, or the other MQs, > for logging only? I mentioned control plane in my previous message, but > we are also thinking about data plane to have something to distribute > requests between different instances. Pushing logs in a MQ could also be > done too. > > Using both control and data plane is interesting because it allows for > more automatic and easier set up of multiple instances as opposed to > creating configuration files manually. A queue can be monitored to see > if the instances are starting to have problems processing all the > requests. If this happens, the queue management can log the problem or > start additional instances. Other useful features include log routing, > as you mentioned, maybe as a control plane service too. That would be a great improvement over the current blocking nature of Radiator which would allow to scale it with multiple cores much better! I can recommend POE which we use in our inhouse NMS since over ten years without an issue. > > Thanks, > Heikki > Best regards, Alex *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
