SQL Accounting Overview
Steel-Belted Radius Carrier can write RADIUS accounting information to an external SQL database, independently of the Steel-Belted Radius Carrier accounting log.
To set up an external database for use as a repository for RADIUS accounting data, you must place an .acc database configuration file in the same directory that contains the Steel-Belted Radius Carrier daemon. This file must be modified to contain specialized information about your enterprise database.
Steel-Belted Radius Carrier offers the SQL accounting feature as a plug-in software module. Key features of the SQL plug-in include:
The SQL statement is completely user-specified, allowing support of existing tables with existing field names and formats.
The SQL statement can include a wide variety of arithmetic and string expressions.
The SQL statement is parameterized, so it is compiled once, and each execution uses variable data without need for recompilation.
Attribute and other data from the accounting request can be mapped to any parameter of the SQL statement (and hence to any field in the table) by means of a simple syntax.
Different request types can be mapped to different SQL statements that may operate against distinct tables within the database.
Multiple instances of a SQL statement can be overlapped for simultaneous execution.
Multiple instances of the SQL accounting module can operate simultaneously, allowing logging to multiple databases.
If the database connection drops, it is automatically reestablished after a configurable timeout without restarting Steel-Belted Radius Carrier.
SQL accounting responses can return information.
Stored procedures invoked by SQL accounting can make use of input parameters, record results, and return output parameters.
While Steel-Belted Radius Carrier tries to provide uniformity in the operation of databases from different vendors, differences exist, particularly in the way SQL statements are interpreted. The capabilities of the SQL Authentication module depend on the capabilities of the underlying databases and their clients; things that work with one database may not work with another.
A stored procedure is a sequence of SQL statements that form a logical unit and perform a particular task. You can use stored procedures to encapsulate a set of queries or operations that can be executed repeatedly on a database server. For example, you can code operations on an employee database, such as password lookup, as stored procedures that can be executed by application code.
Stored procedures can be compiled and executed with different parameters and results. Stored procedures can use any combination of input parameters (the values passed to the stored procedure at execution time) and output parameters (the values set or returned by the stored procedure to the calling application or environment).
You can write stored procedures for SQL that communicate with Steel-Belted Radius Carrier via input and output parameters to implement custom functions. Stored procedures let you use server-side processing on the SQL server to manipulate the information specified by variables. How you use these stored procedures depends on details specific to the implementation of SQL that you are using.
For information about using stored procedures with the Oracle SQL database, see Working with Stored Procedures in Oracle. For information about using stored procedures with the Microsoft SQL database, see Working with Stored Procedures in MS-SQL.
Steel-Belted Radius Carrier may encounter serious problems if the connection between Oracle and Steel-Belted Radius Carrier becomes unstable. The most common reasons for a connection becoming unstable are:
Slow or unreliable network response times
Interruptions in connectivity caused by intervening network devices, such as a firewall timing out the connection
To prevent connectivity problems, consider implementation of one of the following solutions:
To minimize problems caused by intervening firewalls, configure your firewall to pass traffic on the Oracle communications ports between the Steel-Belted Radius Carrier server and the Oracle server without restriction.
To minimize network latency and firewall-related problems, move the Steel-Belted Radius Carrier server to the same network segment as the Oracle server.
If moving your Steel-Belted Radius Carrier server is not feasible, locate a second Steel-Belted Radius Carrier server on the same network segment as your Oracle server, and configure your current Steel-Belted Radius Carrier server to proxy all authentication requests to this new device. This configuration will allow you to open RADIUS ports on the firewall only for the Steel-Belted Radius Carrier server (instead of opening RADIUS ports for all network access servers). Because proxy functions in Steel-Belted Radius Carrier do not require an uninterrupted connection to process requests, this solution allows you to retain your current firewall timeout settings.