Tuesday, January 15, 2019

Radiator Carrier Pack revision 1.5 released!


We are pleased to announce that Radiator Carrier revision 1.5 has been released. The many upgrades and enhancements in the new revision provide even better support for different carrier infrastructures than before.

Detailed changes and upgrades in revision 1.5
  • Added StreamServerUnix which allows to use UNIX domain sockets to connect to Radiator process. Integrator.pm in goodies shows an example how to create an integration interface which uses StreamServerUnix.
  • Updated ServerDIAMETERTelco and DiaPeerDef to fully support TLS_* configuration parameters.
  • DiaPeerDef now supports ReconnectTimeout parameter.
  • AuthBy DiaRelay now supports newly added DiaPeerDef selector Peer-Auth-Application-Id which allows selecting next hop Diameter peer based on the Auth-Application-Id advertised in the peer's CER or CEA. Requires Radiator 4.20 or later.
  • ReconnectTimeout and TLS support in DiaPeerDef requires Radiator 4.21 or later.
  • DiaPeerDef and ServerDiameterTelco now support SCTP multihoming when Radius::SCTP bindings for libsctp are available. Multiple local IP addresses are bound when BindAddress or LocalAddress are configured for ServerDIAMETERTelco or DiaPeerDef, respectively. DiaPeerDef now accepts one or more SCTPPeer configuration parameter for connecting to multiple destination IP addresses. Requires Radiator 4.22 and Radiator Radius::UtilXS package.
  • A number of code clean up and maintenance changes were done based on Perl::Critic and other tools.
  • Information about Diameter connection establishment, termination and DiaPeer selection is now logged on INFO level.

Now available as new Linux packages


Similar to Radiator 4.22, Radiator Carrier Pack is now available as packages suitable for Red Hat, CentOS and Ubuntu. These packages are based on the best practices we have used in our deployments and they comply with the current Linux distribution packaging practices. For more info regarding the new Radiator packages, please see our recent blog

These new packages are now available at:

As these are new packages, we are interested in any feedback you may have on the package design and installation. If you have any ideas, suggestions, feedback or questions of the new  packages, please do send them via this package feedback form or via email to support (a) radiatorsoftware.com.

Friday, January 11, 2019

Radiator v4.22: Now with Windows installer package!

In our efforts to make Radiator easier to install, deploy and update in Windows environment, we have build a Windows installer package for Windows installations. The new package comes as an MSI that can be installed silently when needed. Supported Windows versions are Windows Server 2012 or newer, but older Windows Server versions can also be used provided they have at least PowerShell 3.0 installed.

These new packages are now first available at:
https://radiatorsoftware.com/products/radiator/downloads/

The MSI package includes Strawberry Perl for convenience, so that separate installation of Perl is no longer needed. However, if your environment already has a Perl installation, Strawberry Perl in Radiator MSI package does not disturb it. Since Radiator does require certain Perl modules that are available in the Windows package, it is mandatory to use the Radiator binaries from provided command line shortcuts. These shortcuts are located under Program Files\Radiator folder and for convenience shortcut to this folder and to reference manual are also available in the Start Menu under Radiator Software.

In addition of the Strawberry Perl command line shortcuts there are other important files available on the Program Files\Radiator folder. For example the basic configuration that is automatically installed and installation time log. This folder is never cleaned during upgrade or uninstallation, so this is the suggested location for all your own configurations.


 Differences between the new Windows package and installation from zip 

  • Radiator will install itself automatically under Radiator\Radiator in the drive with largest space available
  • Automatically provided dictionary and users are no longer copied to Program Files\Radiator, instead they should be used from original location. If the files are changed locally, then these should be stored under Program Files\Radiator so they are not removed
  • Installation and other logs are available under Program Files\Radiator
  • Basic configuration file is available under Program Files\Radiator
    • Basic configuration file name has changed to radiator.conf
  • Strawberry Perl is included in the Windows package
    • Only way to avoid this is to install manually from package as before
    • Strawberry Perl is not in path, so when running commands manually they must be done from Perl command line shortcuts available under Program Files\Radiator
  • Windows Service with basic configuration is created automatically
    • This helps testing that installation has been successful with radpwtst
  • Radiator Software is added to Start menu, with shortcut to Program Files\Radiator and link to reference manual
  • Binary files are not copied under Strawberry Perl, instead they are available in Radiator location

 

 

Installing, upgrading and uninstalling the Windows Package

 

Installing the new Windows package is simple. Once the MSI file is copied to the target machine, double click the file, approve license screens, and the installation is done. It is not possible to select where Radiator is installing, it will automatically install to the drive with most space available under Radiator\Radiator. Strawberry Perl is installed under Radiator\StrawberryPerl-Radiator and configuration and logs will go under Program Files\Radiator.

Upgrading works similar way, double clicking the MSI file on the target machine will launch the upgrade functionality. Upgrade will not remove anything from Program Files\Radiator, and also the Windows Service will be available as it was before the upgrade.

Uninstalling can be done either from double clicking the MSI file used to install the software or from Control Panel - Add/Remove Programs. When uninstalling via MSI file, the only option available is Remove. Repair or Change is not available. All Radiator Software specific items are cleared out during the uninstall, except the Program Files\Radiator folder. This is to ensure your configurations are not lost.

The MSI also supports silent operations, so it is possible to start the installation, upgrade, or uninstallation from command line without any UIs.

Note that the MSI package is not signed.



How to change the Windows Service configuration

 

When Radiator Software is installed with the help of MSI package, it has automatically created Windows service with basic configuration. This configuration is mainly aimed to help testing with radpwtst that the installation was successful. Changing the configuration to the Windows Service requires manual steps:

Create the configuration and store it under Program Files\Radiator


Open Windows Services



Stop the Radiator service and close the Services dialog


Open Perl command line Elevated from Program Files\Radiator by double clicking



Initialize the new configuration to Windows Service with command:
perl  "C:\Radiator\Radiator\radiusd" -installservice -config "C:\Program Files\Radiator\lsa_eap_peap.cfg" -prepend_env PATH:C:\Radiator\StrawberryPerl-Radiator\perl\site\bin;C:\Radiator\StrawberryPerl-Radiator\perl\bin;C:\Radiator\StrawberryPerl-Radiator\c\bin;


Open Windows Services and verify from the Radiator service properties that the new configuration is available. Start the service.


Opening ports in Windows firewall for Radiator

 

For connections to work from outside localhost, UDP ports 1645, 1646, 1812, and 1813 need to be opened from the Windows firewall.


Open the Windows Defender Firewall with Advanced Security



Create new Inbound Rule



Rule Type should be Port



Select UDP protocol and specify the needed ports: 1645, 1646, 1812, 1813



Allow the connection



Apply the rule to all profiles



Give suitable name for the rule and Finish the creation

New firewall rule is now active, and incoming Radiator connections are possible.


Give us feedback

As these are new packages, we are interested in any feedback you may have on the package design and installation. If you have any ideas, suggestions, feedback or questions of the new  packages, please do send them via this package feedback form or via email to support (a) radiatorsoftware.com.

Thursday, January 10, 2019

Radiator v4.22: New Linux packages for Radiator products

Background


In our efforts to make Radiator easier to install, deploy and update, we have concentrated our efforts first to ensure Radiator software packaging is up-to-date with current Linux distribution packaging practices. We have started by designing our new packages based on the best practices we have used in our deployments and enhanced those with recommendations for packaging suitable for Red Hat, CentOS and Ubuntu.

These new packages are now available at:

In the near future we intend to introduce Linux package repositories for our customer interested in automating their Radiator updates. We will also continue making legacy RPM packages for a small number of future Radiator releases to provide time for users to migrate to new packages. We will publish blog posts with more detailed migration information during January 2019.

What has changed in packaging?


  • New packages are named as radiator-4.22-1.el7.noarch.rpm and radiator_4.22-1_all.deb. Legacy RPMs are named as Radiator-4.22-1.noarch.rpm. Note the changes in RPM name.
  • Radiator AAA server software now installs completely separately to /opt/radiator/radiator directory to keep Radiator product files separate from system files and Perl libraries. For this reason radiusd and radpwtst and other utilities are no longer copied in /usr/bin and other directories. Startup configuration that comes with the new packages sets this directory as the primary source for Radiator module files.
  • A system user and group radiator is created for Radiator as there is no need to run Radiator as a privileged user. Also the default configuration file and log file permissions have been revised to more secure defaults.
  • Radiator's log directory is now /var/log/radiator/ with permissions set correctly for radiator system user and group. If this directory exists, its permissions are updated but existing old log files are not changed.
  • Radiator package is now fully compliant with systemd for running a single as well as multiple Radiator  instances. This however means that the oldest supported Red Hat / CentOS distribution version for new packages is Red Hat Enterprise Linux or CentOS 7. For Ubuntu we will support Ubuntu 16.04 LTS (Xenial Xerus) as well as Ubuntu 18.04 LTS (Bionic Beaver).
  • systemd unit files set Radiator configuration file to /etc/radiator/radiator.conf
  • Radiator service is installed but is neither enabled nor started by default according to Red Hat packaging recommendations. This is also how Ubuntu packages are configured.
  • In addition to a new example configuration file, located at /etc/radiator/radiator.conf, the new package installs also a logrotate configuration file at /etc/logrotate.d/radiator. By default the configuration rotates and compresses Radiator logs every month and keeps 24 months worth of logs.
  • New packages are signed. More information will be available in Radiator documentation.
See Radiator documentation for the latest installation instructions and other information.

Give us feedback


As these are new packages, we are interested in any feedback you may have on the package design and installation. If you have any ideas, suggestions, feedback or questions of the new packages, please do send them via this package feedback form or via email to support (a) radiatorsoftware.com.


UPDATE 2019-01-11: Firewall configuration and migration information moved to be published in separate posts.


Wednesday, January 9, 2019

Radiator version 4.22 released!

We are pleased to announce the release of Radiator version 4.22!

This version comes with additional Radiator package formats and contains new features, enhancements and bug fixes.

Radiator is now packaged as RPM for Red Hat Enterprise Linux 7 and CentOS 7, deb for Ubuntu 16.04 and 18.04, and MSI for Windows. These are  in addition to the previous package formats: generic RPM, zip and tgz.  Other software, such as Radiator SIM pack, will be packaged later. More information about new packages will be posted separately.

Revision 4.22 (2019-01-09) major packaging update, new features,  enhancements and bug fixes

Selected compatibility notes, enhancements and fixes:

  • New Radiator packages: Red Hat Enterprise Linux 7 and Centos 7, Ubuntu 16.04 and 18.04, and Windows MSI
  • Major updates to Yubikey Validation server support
  • SCTP multihoming support for Diameter and other stream modules

Known caveats and other notes

  • TLSv1.3 is not enabled by default for TLS based EAP methods.
  • TLSv1.3 is not enabled by default for Stream based classes, such as RadSec.
More info and detailed changes can be found from our Radiator revision history.

Thursday, November 15, 2018

Transition from ISP to LTE Carrier - with the help of Radiator products

Recently, we have seen a transition with many operators evolving from traditional Internet Service Providers (ISPs) to LTE carriers who provide fixed line, WiFi, and mobile connections. At the same time, their needs for authentication, authorization, and accounting (AAA) become more complex. As an example, on top of a standard RADIUS AAA infrastructure, these carriers may need Diameter interfaces and a 3GPP AAA server.

For Radiator customers, we have made this transition as easy as possible - and with the flexibility of Radiator, it is easy to bring it to different infrastructures as a new solution.

How Radiator can help

As many of our customers have evolved from ISPs to LTE Carriers, their needs for different features have evolved at the same time. For these needs, we have developed Radiator Carrier class product line. In order to ensure cost-effective solutions, we offer a modular approach where you can purchase only the components that you will need in your project.

For example, many of our customers have used Radiator for both fixed and WiFi access for years. When they need to enable VoWiFi calling features, they can just add Radiator SIM Module to their network, and in this way, enable different EAP-SIM / EAP-AKA / EAP-AKA’ authentication methods and have a fully featured 3GPP AAA Server in their network as well.

Another example is our Radiator GBA/BSF Module that provides easy authentication for VoLTE supplementary services. This way you can ensure that VoLTE supplementary services (call forwarding, knocking, call barring) are in use in your LTE infrastructure without resorting to 2G/3G infrastructure.

Would you like to know more?

If you are interested in Radiator features such as Diameter interfaces, online charging, VoWiFi, or 3GPP AAA Server, you can find more details in our website or contact our sales team at sales@radiatorsoftware.com. We will be happy to help you with your project.

Monday, October 15, 2018

Improved support for Hotspots and subscription quotas!


New Radiator release version 4.22 will introduce an improved support for Hotspot functionality, including differentiated services and prepaid/postpaid quotas.

The release will include following new and updated modules which can be used to implement various service provider use cases:

A new module class called 'ServiceDatabase' which handles differentiated services and subscriptions:

  - <ServiceDatabase INTERNAL> stores service definitions and subscription data within in-memory.

  - <ServiceDatabase SQL> stores service definitions and subscription data within SQL database.

Existing <SessionDatabase INTERNAL> and <SessionDatabase SQL> modules have been updated to work seamlessly with new <ServiceDatabase> modules for RADIUS accounting based quota control.

A new generic <AuthBy HOTSPOT> module which combines <ServiceDatabase>, <SessionDatabase>, an authenticating <AuthBy>, and possible <AuthBy DYNAUTH> (RADIUS Dynamic Authorization) for sending CoA/DM e.g. after a successful authentication or when a quota has been depleted, into a working solution which can be used with captive portals (for example MikroTik) and network access controllers supporting RADIUS. Beside Hotspot use-case, the same solution can also be used to implement a quota control for fixed-line access or cellular APN.

A new <AuthBy HOTSPOTFIDELIO> module based on <AuthBy HOTSPOT> which uses Radiator Fidelio/Opera PMS integration for authenticating and billing guests. Note that <AuthBy HOTSPOTFIDELIO> obsoletes previous <AuthBy FIDELIOHOTSPOT> module.

Implementing a guest network access with Radiator using Fidelio/Opera PMS integration.

Examples

To demonstrate how new <AuthBy HOTSPOT> and <AuthBy HOTSPOTFIDELIO> combine these new features, see a following configuration examples of new Radiator Hotspot functionality:

Example 1. Using in-memory <ServiceDatabase INTERNAL> and <SessionDatabase INTERNAL> with <AuthBy HOTSPOT> and <AuthBy FILE>

# See goodies/hotspot.cfg for a full example config

...

### Service and Session databases ###

# ServiceDatabase INTERNAL for Services and Subscriptions
<ServiceDatabase INTERNAL>
  Identifier ServiceDatabase-INTERNAL

  # Service definitions
  # Service 1: free, 1 hour, 50M data, no policers  Service name:free price:0 prepaidTime:1h prepaidQuota:50M replyItems:"OSC-AVPAIR=Test1,OSC-AVPAIR=Test2" 
  # Service 2: price 1000 cents, 1 day, 100M data, 100M/10M policers
  Service name:premium price:1000 prepaidTime:24h prepaidQuota:100M prepaidUpRate:10M prepaidDownRate:100M

  # Service 3: price 2000 cents, 1 day, 1G data, 100M/100M policers
  Service name:gold price:2000 prepaidTime:24h prepaidQuota:1G prepaidUpRate:100M prepaidDownRate:100M
</ServiceDatabase>

# SessionDatabase INTERNAL for Sessions
<SessionDatabase INTERNAL>
  Identifier SessionDatabase-INTERNAL
</SessionDatabase>

...

### AuthBy Modules ###

# Authenticate Hotspot users with AuthBy FILE
<AuthBy FILE>
  Identifier AuthBy-FILE

  Filename %D/users
  NoDefault
</AuthBy>

<AuthBy HOTSPOT>
  Identifier AuthBy-HOTSPOT

  # Authenticate Hotspot users with AuthBy FILE
  AuthBy AuthBy-FILE

  # Use ServiceDatabase-INTERNAL for services and subscriptions
  ServiceDatabase ServiceDatabase-INTERNAL

  # Lookup a subscription based on username (%1) and Calling-Station-Id MAC address
  SubscriptionId %1-%{Calling-Station-Id}

  # Use SessionDatabase-INTERNAL for sessions
  SessionDatabase SessionDatabase-INTERNAL

  # Lookup a session based on username (%1) and Calling-Station-Id MAC address
  SessionId %1-%{Calling-Station-Id}
  # Empty SessionAttribute
  SessionAttribute

  # If RADIUS accounting will be used for quota monitoring,
  # create a new session upon a successful authentication
  #PreProvisionSession

  # Alternatively, reply with remaining time quota
  #UsageMonitoring
  # and remaining data quota
  #ReplyWithDataQuota
  #DataLimitAttribute Mikrotik-Total-Limit
  #DataLimitGigawordsAttribute Mikrotik-Total-Limit-Gigawords

  # Use service 'free' as a default service
  DefaultService free
  ServiceAttribute OSC-Service-Identifier
  #ServiceAttributePrefix Service=
</AuthBy>

# AuthBy DyNAUTH for creating DM/CoA requests for exceeded sessions
<AuthBy DYNAUTH>
  Identifier AuthBy-DYNAUTH

  SessionDatabase SessionDatabase-INTERNAL

  # Send Change-Filter-Request (CoA) to NAS UDP port 3799
  #RequestType Change-Filter-Request
  # Send Disconnect-Request (DM) to NAS UDP port 3799
  RequestType Disconnect-Request
  DynAuthPort 3799

  # Do not try to lookup a session again
  NoSessionMapping

  # Send CoA/DM to IP address within NAS-IP-Address RADIUS attribute
  NasAddrAttribute NAS-IP-Address

  # Identify user session by User-Name, Acct-Session-Id and NAS-Port
  DynAuthAttribute User-Name
  DynAuthAttribute Acct-Session-Id
  DynAuthAttribute NAS-Port
</AuthBy>

# AuthBy RADIUSBYATTR for sending out DM/CoA requests for exceeded sessions
<AuthBy RADIUSBYATTR>
  Identifier AuthBy-RADIUSBYATTR
</AuthBy>

### Request Handlers ###

# Accounting Handler
<Handler Request-Type=Accounting-Request>
  Identifier Accounting-Handler

  # Acknowledge Accounting-Request immediately
  AccountingAccepted

  AuthByPolicy ContinueUntilRejectOrChallenge

  # Handle RADIUS accounting
  AuthBy AuthBy-HOTSPOT
  # Send DM/CoA request for exceeded session
  AuthBy AuthBy-DYNAUTH
</Handler>

# Outgoing DM/CoA Handler
<Handler DynAuthRequest=1>
  Identifier Handler-DYNAUTH

  AuthBy AuthBy-RADIUSBYATTR
</Handler>

# Default Handler
<Handler>
  Identifier Default-Handler

  # Handle RADIUS authentication
  AuthBy AuthBy-HOTSPOT

  RejectHasReason
</Handler>
Example 2. Using <ServiceDatabase SQL> and <SessionDatabase SQL> with <AuthBy HOTSPOTFIDELIO>

# See goodies/hotspot-fidelio.cfg for a full example config
#
# Requires SQL definitions from goodies/hotspot.sql and goodies/hotspot-fidelio.sql
# See goodies/README.hotspot-fidelio for more information
#

...

### Service and Session databases ###

# ServiceDatabase SQL for Services and Subscriptions
<ServiceDatabase SQL>
  Identifier ServiceDatabase-SQL

  # Details of how to contact the service and subscription database
  DBSource   dbi:SQLite:dbname=hotspot.db
  #DBSource   dbi:mysql:hotspot
  DBUsername mikem
  DBAuth     fred
</ServiceDatabase>

# SessionDatabase SQL for Sessions
<SessionDatabase SQL>
  Identifier SessionDatabase-SQL

  # Details of how to contact the session database
  DBSource   dbi:SQLite:dbname=hotspot.db
  #DBSource   dbi:mysql:hotspot
  DBUsername mikem
  DBAuth     fred

  # Modified SQL queries/statements for a new session database schema (goodies/hotspot.sql)
  CountQuery SELECT nas_id, nas_port, id, ipv4 FROM SESSIONS WHERE user_name=%0
  ClearNasQuery DELETE FROM SESSIONS WHERE nas_id='%0'
  AddQuery
  DeleteQuery
  ClearNasSessionQuery
</SessionDatabase>

...

### AuthBy Modules ###

<AuthBy HOTSPOTFIDELIO>
  Identifier AuthBy-HOTSPOTFIDELIO

  # Use ServiceDatabase-SQL for services and subscriptions
  ServiceDatabase ServiceDatabase-SQL
  # Lookup a subscription based on username (%1), Fidelio PMS    Guest Number (%2) and Calling-Station-Id MAC address
  SubscriptionId %1-%2-%{Calling-Station-Id}

  # Use SessionDatabase-SQL for sessions
  SessionDatabase SessionDatabase-SQL
  # Lookup a session based on username (%1), Class (%3) and    Calling-Station-Id MAC address
  SessionId %1-%3-%{Calling-Station-Id}
  # Empty SessionAttribute
  SessionAttribute

  # If RADIUS accounting will be used for quota monitoring,
  # create a new session upon a successful authentication
  PreProvisionSession

  # Alternatively, reply with remaining time quota
  #UsageMonitoring
  # and remaining data quota
  #ReplyWithDataQuota
  #DataLimitAttribute Mikrotik-Total-Limit
  #DataLimitGigawordsAttribute Mikrotik-Total-Limit-Gigawords

  # Details of how to contact the Fidelio posting database
  # See AuthSQL for details
  DBSource   dbi:SQLite:dbname=hotspot.db
  #DBSource   dbi:mysql:hotspot
  DBUsername mikem
  DBAuth     fred

  # Fidelio PMS interface
  Protocol tcp
  Port 5010
  Host localhost

  # Validity time in seconds of plan purchased
  # Default 86400 seconds (1 day)
  BlockDuration 86400

  # Default price for plan
  # Price in database overrides this value
  BlockPrice 900

  # ServiceAttribute defines the RADIUS attribute that is
  # used select the desired prepaid service or plan. On
  # Mikrotik login page you can create a menu as shown
  # below to display the different purchase
  # options. Note: "name=radius0-9048" is OSC-AVPAIR.
  #  <tr><td>Service:</td><td>
  #  <select name="radius0-9048">
  #  <option value="Mikrotik-Service=free">best effort (free)  </option>
  #  <option value="Mikrotik-Service=premium">premium ($5)</option>
  #  </select></td></tr>
  ServiceAttribute OSC-AVPAIR

  # If it is possible that there are multiple instances
  # of the ServiceAttribute in the request, you can use
  # an optional prefix to choose the correct instance.
  ServiceAttributePrefix Mikrotik-Service=

  # By default upgrade or renewal of the current plan is
  # automatically processed and charged. With this option
  # you can ask the guest to confirm the charge first.
  # With Mikrotik you can show the message to the guest
  # by including
  #  $(if error)<br /><div style="color: #FF8080; font-size: 14px">$(error)</div><br>$(endif)
  # on the Mikrotik login page
  #ConfirmUpgradeOrRenew
  #ConfirmationMessage "You are going to upgrade or renew your plan, please login again to confirm the charge"

  # This one uses the last part of the guest name (case sensitive) as the
  # password. This is usually the guest surname
  UserPasswordHook sub {my @n = split(/\s/, $_[1]->{'GN'}); return $n[$#n];}

  # Need this to ensure the Guest Number is included in the postings
  # Required when there are multiple guests per room
  #PostingExtraFields G#,%4

  # You can add extra attributes in the reply here if you wish
  # to set limits or controls over access
  #AddToReply Mikrotik-Recv-Limit-Gigawords=1,Mikrotik-Xmit-Limit-Gigawords=1
</AuthBy>

# AuthBy DyNAUTH for creating DM/CoA requests for exceeded sessions
<AuthBy DYNAUTH>
  Identifier AuthBy-DYNAUTH

  SessionDatabase SessionDatabase-SQL

  # Send Change-Filter-Request (CoA) to NAS UDP port 1700
  #RequestType Change-Filter-Request
  # Send Disconnect-Request (DM) to NAS UDP port 1700
  RequestType Disconnect-Request
  DynAuthPort 1700

  # Do not try to lookup a session again
  NoSessionMapping

  # Send CoA/DM to IP address within NAS-IP-Address RADIUS attribute
  NasAddrAttribute NAS-IP-Address

  # Identify user session by User-Name, Acct-Session-Id and NAS-Port
  DynAuthAttribute User-Name
  DynAuthAttribute Acct-Session-Id
  DynAuthAttribute NAS-Port
</AuthBy>

# AuthBy RADIUSBYATTR for sending out DM/CoA requests for exceeded sessions
<AuthBy RADIUSBYATTR>
  Identifier AuthBy-RADIUSBYATTR
</AuthBy>

### Request Handlers ###

# Accounting Handler
<Handler Request-Type=Accounting-Request>
  Identifier Accounting-Handler

  # Acknowledge Accounting-Request immediately
  AccountingAccepted

  AuthByPolicy ContinueUntilRejectOrChallenge

  # Handle RADIUS accounting
  AuthBy AuthBy-HOTSPOTFIDELIO
  # Send DM/CoA request for exceeded session
  AuthBy AuthBy-DYNAUTH
</Handler>

# Outgoing DM/CoA Handler
<Handler DynAuthRequest=1>
  Identifier Handler-DYNAUTH

  AuthBy AuthBy-RADIUSBYATTR
</Handler>

# Default Handler
<Handler>
  Identifier Default-Handler

  # Use SessionDatabase-SQL
  SessionDatabase SessionDatabase-SQL
  # Don't try to delete a session before authentication
  SessionDatabaseOptions NoDeleteBeforeAuthentication

  # Handle RADIUS authentication
  AuthBy AuthBy-HOTSPOTFIDELIO

  RejectHasReason
</Handler>

Tuesday, September 18, 2018

Radiator as a Cisco ACS replacement

We have been contacted by customers looking for a replacement for Cisco ACS (Secure Access Control System) because it is near of its end of support. Radiator AAA Server Software is a fully featured and cost-effective solution that is known in the market as the “Swiss Army of AAA Servers for RADIUS, Diameter and TACACS+”.

To assist with migration, we are also selling consulting services. As we have had a wide range of customers with different needs migrating to Radiator, we can easily tailor a cost-effective consulting package for your needs. Because of our experience in similar projects, Radiator configuration can be adjusted to new environments without any extra hassle.

At the same time, Radiator is actively developed and it runs with variety of platforms, including Linux, Windows and others. You can be sure that you will have a supported AAA solution that is always kept up to date. Radiator has at least two releases per year, with interim patches made available for those who require the latest updates. Radiator is actively used by thousands of companies and organisations in over 180 countries.

Other key features of Radiator include:

  • Supports authentication by over 60 different types of methods
  • Interoperates with a huge range of devices, databases, billing packages, and tokens
  • Includes RadSec - secure, reliable RADIUS proxying
  • Includes Diameter - the RADIUS successor protocol used already by mobile operators
  • Includes TACACS+ - for infrastructure management

Would you like to know more?

With Radiator, you get direct professional technical support for configuration, for deployment, and for development. We have consultation and support packages ranging from limited email support to 24x7 telephone support, provided by Radiator experts. Additionally, Radiator Software and its partner companies provide installation and consultation support whenever needed. If you would like to know more about Radiator, licensing options, and support, please contact our team at info@radiatorsoftware.com