Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Common Configuration Items

 

This section explains the configuration items that are common across all SQL plug-ins. These configuration items are found in the .acc (accounting), .aut (authentication), and .gen (generic accessor) files.

[Bootstrap] Section

[Bootstrap] Section

The [Bootstrap] section (Table 143) of the SQL configuration file specifies information that Steel-Belted Radius Carrier uses to load and start an SQL method.

Table 143: [Bootstrap] Syntax

Parameter

Function

LibraryName

Specifies the name of the executable binary that implements the SQL plug-in. For example, radsql_auth_ora.so in the case of the Oracle native SQL Authentication Plug-in. It should not be necessary to change the default value unless you have developed your own plug-in.

Enable

Specifies whether the SQL method is enabled.

  • If set to 0, the SQL method is disabled

  • If set to 1, the SQL method is enabled.

Default value is 0.

InitializationString

Specifies the name of the SQL method.

The name of each SQL method must be unique.

[Settings] Section

[Settings] Section

The [Settings] section of the SQL configuration file defines parameters that control the database connection.

Note

The following log file warning message is shown when the Connect parameter is used along with a server definition in any of the .acc (accounting), .aut (authentication), and .gen (generic accessor) files:

WARNING: Deprecated ’Connect=’ string in [Settings] section of ’/opt/JNPRsbr/radius/radsql.acc’ - The connect string may overlap with [Server] connection/activation target settings.

The Connect parameter should only be defined in the [Server/name] section. For information on using the Connect parameter, see [Server/name] Sections.

Table 144: [Settings] Syntax

Parameter

Function

ConcurrentTimeout

Specifies the number of seconds a request may wait for execution before it is discarded. Because there may be only up to MaxConcurrent SQL statements executing at one time, new requests must be queued as they arrive until other statements are processed.

Note: The MaxConcurrent parameter is valid only for Oracle SQL methods (for example, radsql.aut). It is not valid for JDBC SQL (for example, radsqljdbc.aut).

ConnectDelimiter

(JDBC only) Specifies the character used to separate fields (DSN, UID, PWD) in the connect string.

Default value is ; (semicolon). If the JDBC connect string requires use of semicolons as part of a field value, you can use this parameter to specify a different delimiter, such as ^ (caret).

Note: In the case of JDBC, the Connect parameter is closely related to the Driver parameter. The exact syntax of these parameters is highly dependent upon the particular JDBC driver that you are using. You should always obtain your JDBC driver directly from your database vendor and consult the vendor's documentation for more details.

DisableMetaData

(MySQL JDBC only) Specifies whether to suppress errors that occur while using integer data types in a MySQL argument.

  • If set to 1, SBR Carrier suppresses errors that occur while using integer data types in a MySQL argument.

  • If set to 0, SBR Carrier displays errors that occur while using integer data types in a MySQL argument.

Default value is 0.

Driver

(JDBC only) Specifies the third-party JDBC driver to support the database connection. For example:

Driver=com/mysql/jdbc/Driver/

Oracle example (using ojdbc14.jar)

Driver=oracle/jdbc/OracleDriver

MySQL example (using mysql-connector-java-5.0.5-bin.jar)

Driver=com/mysql/jdbc/Driver

MSSQL example (using mssqlserver.jar)

Driver=com/provider/jdbc/sqlserver/SQLServerDriver

Note: In the case of JDBC, the Connect parameter is closely related to the Driver parameter. The exact syntax of these parameters is highly dependent upon the particular JDBC driver that you are using. You should always obtain your JDBC driver directly from your database vendor and consult the vendor's documentation for more details.

Note: Third-party JDBC drivers must be installed in the <JRE-path>/lib/ext directory. Where, <JRE-path> indicates the path where the JRE (that is integrated with SBR Carrier) is installed in your system.

See JDBC Plug-ins for more information.

ErrorMap

Specifies the name of the file that contains the native error codes that are treated as soft errors (that is, errors that do not require the SQL method to disconnect from and reconnect to the remote database).

Note: Steel-Belted Radius Carrier includes three default error map files: mssql.ini is for Microsoft SQL, mysql.ini is for MySQL, and oracle.ini is for Oracle. See ErrorMap for information about configuring error map files.

LogLevel

Activates logging for the SQL method and sets the level of detail of the message. The LogLevel may be the number 0, 1, or 2, where 0 is the lowest logging level, 1 is intermediate, and 2 is the most verbose. If the LogLevel that you set in the SQL method configuration file is different than the LogLevel in radius.ini, then the lowest value controls.

MaxConcurrent

Specifies the maximum number of instances of a single SQL statement that may be executing at one time.

Note: The MaxConcurrent parameter is valid only for Oracle SQL methods (for example, radsql.aut). It is not valid for JDBC SQL (for example, radsqljdbc.aut).

Note: A setting of MaxConcurrent = 1 is sufficient for all but the most demanding environments. Increase this value slowly and conservatively. For more information about executing overlapping SQL statements, see the SBR Carrier Administration and Configuration Guide.

MaxHardErrorRetries

This parameter is added to resolve an issue where the database disconnected due to inactivity timeout. The MaxHardErrorRetries parameter enables the connection to be reestablished without failing the authentication by allowing you to set the number of additional attempts you want to make after hard errors have been encountered.

Default is 0.

MaxWaitReconnect

Specifies the maximum number of seconds to wait after successive failures to reconnect after a failure of the database connection.

WaitReconnect specifies the time to wait after failure of the database connection. This value is doubled on each failed attempt to reconnect, up to a maximum of MaxWaitReconnect.

OracleFailoverRetry

Specifies the number of retry attempts that the Oracle client can perform when attempting an Oracle failover. No upper limit exists for the number of retries. Default value is 0. The retry attempts that the Oracle client performs are per database request.

When a value is set, Oracle failover retries are attempted until the set number of retries is reached, after which the retry process is canceled. If the default value of 0 is set, the retry attempts continue until the Oracle failover succeeds or fails.

Note: The Steel-Belted Radius Carrier shutdown process is not affected by the failover retry. When an SBR shutdown is initiated, the failover process is canceled and SBR is allowed to shut down.

OracleSocket

ReadTimeout

Specifies the maximum number of seconds a socket must wait when a network error has occurred or Oracle database is terminated abruptly.

The default value is 0 second, which means timeout does not occur. If set to 0, the socket waits until the OS level socket timeout is reached.

If a non-zero value is set, the socket waits until the configured time, after which the JDBC driver closes the database connection. Configuring a non-zero value prevents the waiting situation when there is a network error or database disconnection.

Note: The OracleSocketReadTimeout parameter is valid only for Oracle JDBC SQL plug-ins (radsqljdbc.aut, radsqljdbc.acc, and sqlaccessor_jdbc.gen) with Oracle JDBC driver files ojdbc5.jar, ojdbc6.jar, or later. The OracleSocketReadTimeout parameter is not valid for Oracle SQL plug-ins (for example, radsql.aut) and other JDBC SQL methods such as MySQL and MS SQL.

For MySQL and MS SQL, you can use the socketTimeout parameter (values in milliseconds) in the Connect string. For example:

Connect=DSN=jdbc:mysql://10.212.11.47:3306/test?

socketTimeout=20000;UID=sbr;PWD=sbr

ParameterMarker

Specifies the character or sequence of characters used as the parameter marker in a parameterized SQL query. Normally, this is the question mark (?), but this can vary among database vendors.

QueryTimeout

Specifies the number of seconds to wait for the execution of an SQL request to complete before timing out.

Note: QueryTimeout is not a precise timer and this parameter does not have any effect if there are network failures. Cancelling an SQL request also depends on the network latency as well as the query timeout setting on the server.

ShutdownTimeout

Specifies the maximum number of seconds to wait for outstanding database transactions when the server is in the process of shutting down. If this timeout expires, then any outstanding database transactions are forcibly terminated in order to allow the server to shut down. Changing the default value is not recommended.

SQL

Specifies the SQL statement used to access the database. The SQL statement may be broken over several lines by ending each line with a backslash. The backslash must be preceded by a space character, and followed by a newline character. The subsequent lines may be indented for better readability.

See SQL Parameter for more information.

WaitReconnect

Specifies the number of seconds to wait after a failure of the database connection before trying to connect again.

This section also explains the following:

  • Limitations of Underlying Database APIs

  • SQL Parameter

  • ErrorMap

  • LogLevel

Limitations of Underlying Database APIs

Limitations of Underlying Database APIs

The MaxConcurrent parameter is valid only for Oracle SQL authentication (radsql.aut). It is not valid for JDBC SQL authentication (radsqljdbc.aut).

The OracleSocketReadTimeout parameter is valid only for Oracle JDBC SQL plug-ins (radsqljdbc.aut, radsqljdbc.acc, and sqlaccessor_jdbc.gen) with Oracle JDBC driver files ojdbc5.jar, ojdbc6.jar, or later.

SQL Parameter

SQL Parameter

  • SBR tracks certain data pertaining to each RADIUS transaction. Data that comes directly from the RADIUS attributes contained in the RADIUS packets are referred as “attributes” (including subattributes). Data generated internally by SBR as a side-effect of processing the RADIUS transaction are referred as “items”.

  • Attributes are defined in SBR configuration files known as “dictionaries”. Dictionaries determine data type of each attribute.

    Items are not defined by dictionaries and the SBR data type of each item is fixed internally.

  • SQL plug-ins support all attributes, as well as items such as AuthType, TransactionTime, Name, FullName, UserName, Password, User, EffectiveUser, Realm, EffectiveRealm, RadiusClientName, NASName, NASModel, NASAddress, and NASIPv6Address.

  • The SQL= configuration parameter specifies an SQL statement to be executed.

    In the case of authentication, there are typically some inputs supplied by SBR that are used by the database in order to retrieve some outputs that are then processed further by SBR.

    In the case of accounting, there are typically only inputs supplied by SBR that are stored by the database (outputs could also be retrieved by the database, but are ignored by SBR as it does not do any further processing for accounting).

    In general, either attributes or items can be supplied as inputs or outputs, or both to SQL statements.

  • Inputs and outputs can be specified by substituting ’terms’ of the SQL statement that would normally represent literal values or parameters to a database stored procedure. The substituted terms of the SQL statement are known as ’positional parameters’ because they are automatically assigned integer placeholders in the order they appear. For example, :1, :2, :3, ...

  • Outputs can also be specified by mapping 'columns' of the SQL statement 'result set'. However, the SQL statement result set must not contain more than one 'row'. An error occurs if SBR attempts to process a 'result set' that contains more than one row. See the [Results] section for more information.

  • SBR cannot interpret the meaning of an SQL statement beyond the simple mechanics of substituting positional parameters and mapping columns of the result set. This makes it nearly impossible to detect errors and inconsistencies in the configuration. In particular, SBR cannot determine whether the SQL statement generates a result set or whether the only outputs are positional parameters. Ensure that you comment out the [Results] section if no result set is generated.

  • The general syntax for substituting a positional parameter for a term of the SQL statement is as follows:

    %<item>/[size][.digits][type][&][!direction]

    Or

    @<attribute>/[size][.digits][type][&][!direction]

    Where, <> indicates required fields and [] indicates optional fields.

    • item—name of an SBR item, for example, UserName

    • attribute—name of an SBR attribute, for example, Acct-Status-Type

    • size—maximum size in bytes required to represent this parameter

    • digits—maximum number of decimal digits required to represent this parameter

    • type—database type used to represent this parameter.

      The 'type' of a positional parameter refers to the database type used to represent the parameter within the database, as opposed to the SBR type that is used to represent the corresponding item or attribute internally within the SBR. SBR must convert each item or attribute into a compatible database representation before these can be passed to the database as positional parameters. The specified type provides a hint to the SBR as to what type of conversion should be performed. The database may also perform additional type conversions, either explicitly as part of the SQL statement or implicitly when the type of the positional parameter is not exactly that which is required to perform some calculation or store/retrieve a column value.

      SBR supports the following type flags for positional parameters: "s” = VARCHAR; “b” = VARBINARY; “t” = TIMESTAMP; “numeric” = NUMERIC; “n32” = INTEGER (32bit); “n64” = BIGINT (64bit); “n16” = SMALLINT (16bit); “n8” = TINYINT (8bit).

      Note

      The exact database types in capital may vary across database vendors and implementations. The default type depends on the SBR type and the database type detected by the SBR, but usually “s” = VARCHAR is assumed.

    • &—This flag indicates that this parameter may be NULL (optional).

      The optional null flag “&” indicates that a positional parameter may pass a NULL value. NULL values may be provided as inputs in lieu of missing/undefined items and attributes. NULL values may also be retrieved as outputs that do not cause any changes to the values of existing items and attributes. Without the optional null flag "&", the SBR converts any NULL values to something appropriate for the type of positional parameter involved, for example, an empty string for VARCHAR or zero for NUMERIC. By default, the SBR assumes that NULL values should not be passed and all NULL values are converted to some appropriate non-NULL value.

    • direction—Direction in which the data flows.

      The direction of a positional parameter refers to the direction in which the data flows. SBR supports the combination of the following direction flags for positional parameters: “i” = INPUT (data flows from the SBR into the database); “o” = OUTPUT (data flows out of the database to the SBR); “r” = REJECT OUTPUT (data flows out of the database to the SBR, but is only included in a RADIUS ACCESS-REJECT packet). The default direction is “i” = INPUT.

  • It is often best to experiment with and verify the execution of the SQL statement using a command line utility such as Oracle sqlplus before attempting to configure the SQL plug-in. However, the configured SQL statement may differ in some minor ways, for example, terminating semi-colon (;) required when using the command line utility but prohibited when configuring the SQL plug-in. These minor differences may vary across database vendors and implementations.

ErrorMap

ErrorMap

Specifies the name of the file that contains the native error codes that are treated as soft errors (that is, errors that do not require Steel-Belted Radius Carrier to disconnect from and reconnect to the remote database).

Note

Steel-Belted Radius Carrier includes three default error map files: mssql.ini (for Microsoft SQL using ODBC), mysql.ini (for MySQL using JDBC), and oracle.ini (for Oracle using OCI).

The following sections explain the error map files:

mssql.ini File

The mssql.ini configuration file specifies which errors returned by a back-end MS-SQL database are classified as soft errors. Error codes not listed in mssql.ini are presumed to be hard errors, which cause Steel-Belted Radius Carrier to drop and re-establish the connection to the MS-SQL database. Database-dependent RADIUS transactions fail while the connection to the MS-SQL database is being re-established.

Each entry in the mssql.ini configuration file consists of an error number (positive integer), followed by a descriptive comment. For best performance, use the mssql.ini file to identify only the most common soft errors.

Note

If you incorrectly define a hard error as a soft error and the error is encountered during processing, you may need to restart Steel-Belted Radius Carrier to reset the database plug-in.

[SoftErrors] Section

The [SoftErrors] section identifies each MS-SQL error code to be classified as a soft error. To include a comment or description for the error code, enter a semi-colon after the error code, followed by the comment.

mysql.ini File

The mysql.ini configuration file specifies which errors returned by a back-end MySQL database are classified as soft errors. Error codes not listed in mysql.ini are presumed to be hard errors, which cause Steel-Belted Radius Carrier to drop and re-establish the connection to the MySQL database. Database-dependent RADIUS transactions fail while the connection to the MySQL database is being re-established.

Each entry in the mysql.ini configuration file consists of an error number (positive integer), followed by a descriptive comment. For best performance, use the mysql.ini file to identify only the most common soft errors.

Note

If you incorrectly define a hard error as a soft error and the error is encountered during processing, you may need to restart Steel-Belted Radius Carrier to reset the database plug-in.

[SoftErrors] Section

The [SoftErrors] section identifies each MySQL error code to be classified as a soft error. To include a comment or description for the error code, enter a semi-colon after the error code, followed by the comment.

oracle.ini File

The oracle.ini configuration file specifies which errors returned by a back-end Oracle database are classified as soft errors. Error codes not listed in oracle.ini are presumed to be hard errors, which cause Steel-Belted Radius Carrier to drop and re-establish the connection to the Oracle database. Database-dependent RADIUS transactions fail while the connection to the Oracle database is being re-established.

Each entry in the oracle.ini configuration file consists of an error number (positive integer), followed by a descriptive comment. For best performance, use the oracle.ini file to identify only the most common soft errors.

Note

If you incorrectly define a hard error as a soft error and the error is encountered during processing, you may need to restart Steel-Belted Radius Carrier to reset the database plug-in.

[SoftErrors] Section

The [SoftErrors] section identifies each Oracle error code to be classified as a soft error. To include a comment or description for the error code, enter a semi-colon after the error code, followed by the comment.

LogLevel

LogLevel

Activates logging for the SQL method and sets the level of detail of the message. The LogLevel may be the number 0, 1, or 2, where 0 is the lowest logging level, 1 is intermediate, and 2 is the most verbose. If the LogLevel that you set in the configuration file is different than the LogLevel in radius.ini, the lower value of the setting controls.

[Server] Section

[Server] Section

There are two methods to establish a connection to the server:

  • Connecting to a Single SQL Server

  • Connecting to Multiple Servers

To connect to a single server, include a connect statement in the [Settings] section of sqlaccessor.gen or sqlaccessor_jdbc.gen. For example:

Steel-Belted Radius Carrier can maintain multiple SQL server connections and authenticate users against authentication databases in a round-robin fashion. This convention distributes the authentication workload across several servers. The [Server] section of the SQL configuration file gives Steel-Belted Radius Carrier a pool of servers from which to create the round-robin list. The [Server] section names each server that might be used. It also provides rules for when to include or exclude each of the possible servers in the round-robin list.

Table 145: [Server] Syntax

Parameter

Function

ServerName

The name of the configuration file section that contains configuration information for that server.

TargetNumber

An activation target number, a number that controls when this server is activated for backup purposes.

TargetNumber is optional and may be left blank.

A Steel-Belted Radius Carrier server maintains connectivity with its SQL servers according to the following rules:

  • The priority of the server by order. The first entry in the [Server] section has the highest priority.

  • By activation target number. The rule for the activation target is that if the number of SQL servers to which Steel-Belted Radius Carrier is connected is less than the activation target, Steel-Belted Radius Carrier connects to the server and includes it in the round-robin list. While the number of active servers is equal to or greater that the activation target, Steel-Belted Radius Carrier does not use that server in the round-robin list. An activation target of 0 indicates that, in the current configuration, this machine is never used.

Note

If you configure the [Server] section, then you should also configure a [Server/ServerName] section for each ServerName specified in the [Server] section. The ServerName represents an arbitrary but unique name for each server. The [Server/ServerName] sections may be used to override parameters specified in the [Settings] section. Each [Server/ServerName] section must at least override the Connect parameter. Unlike other parameters, the Connect parameter in the [Settings] section should always be commented out when it is overridden; otherwise, the Connect parameter would be counted as an additional activation target, leading to an unexpected behavior.

[Server/name] Sections

[Server/name] Sections

You must provide a [Server/ name ] section for each server you named in the [Server] section:



where the values for username and password are specific to the SQL database, and servicename is the Oracle service name.

The Connect parameter specifies the string that must be passed to the database client engine to establish a connection to the database. This string has (or refers to) information about the name of the database, its location on the network, the password required to access it, and so forth.

The format of the Connect string depends on the type of database you use:

Oracle plug-ins:

Connect=<dB_username> /< dB_password>

JDBC plug-ins:

Connect=DSN=< jdbc: provider:driver:dsn _name_here>;UID= <username_ for_dB>;PWD= <password_for_dB>

MySQL Example (DBNAME instance at IP address 10.10.10.10 port 3306):

Connect=DSN=jdbc:mysql://10.10.10.10:3306/DBNAME; UID=scott;PWD=tiger

MS-SQL Example (DBNAME instance at IP address 10.10.10.10 port 1433):

Connect=DSN=jdbc:microsoft:sqlserver://10.10.10.10:1433;

databaseName=DBNAME;UID=scott;PWD=tiger

Oracle Example (DBNAME instance at IP address 10.10.10.10 port 1521):

Connect=DSN=jdbc:oracle:thin:@10.10.10.10:1521:DBNAME;

UID=scott;PWD=tiger

Note

Do not use the SA account or leave the password blank.

Last Resort Server

Last Resort Server

You may identify a “last resort” SQL server by providing a LastResort parameter in one of these [Server/ name ] sections, and setting its value to 1. If a SQL query against some other server results in “no record found,” the authentication server tries the last resort server before accepting or rejecting the user.

In the following example, server s3 is the last resort server. The @mydb string refers to the service name for an Oracle database in the tnsnames.ora file (the server cannot connect to the Oracle database without this).

You might use the LastResort parameter to identify your primary accounts database. This enables Steel-Belted Radius Carrier to authenticate the user in the case where a user account is newly added to the primary accounts database but has not yet been propagated to all the SQL databases.

Load Balancing Example

Load Balancing Example

The following excerpt from a .acc example file configures load balancing between two SQL servers (so that the work load is shared nearly equally between two servers). The tradeoff with this technique is that the data is split between two servers and must be reintegrated when processed. For example, the Accounting-START for an end user may be stored on one server and the corresponding Accounting-STOP on the other.

 

JDBC Plug-ins

JDBC Plug-ins

This section describes how to install the JDBC driver from MySQL, MS-SQL, Oracle.

For MySQL:

  1. Download the latest JDBC driver from Oracle that is appropriate for your MySQL server version.
  2. Follow the installation directions provided by the vendor.

    This typically involves extracting a zip file to obtain .jar files that implement the JDBC driver, for example, mysql-connector-java-5.0.5-bin.jar and possibly others.

  3. Copy all the .jar files to the <JRE-path>/lib/ext directory. Where, <JRE-path> indicates the path where the JRE (that is integrated with SBR Carrier) is installed in your system.
  4. Determine the name of the JDBC driver by consulting the documentation provided by the vendor.

    It is usually possible to determine the name of the JDBC driver by executing a shell command similar to: jar -tf mysql-connector-java-5.0.5-bin.jar |grep Driver. Select the name that most resembles /com/mysql/jdbc/Driver and omit the .class extension.

  5. Use the driver name obtained in Step 4 to configure the Driver parameter in the JDBC plug-in configuration file.

See https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-versions-java.html for JDBC driver specifications and its compliance with MySQL.

For MS-SQL:

  1. Download the latest JDBC driver from Microsoft that is appropriate for your MS-SQL server version.
  2. Follow the installation directions provided by the vendor.

    This typically involves extracting a tar file and running an install script to obtain a directory such as /opt/mssql or /opt/msSQLjdbc that contains the .jar files that implement the JDBC driver, for example, mssqlserver.jar and possibly others such as msbase.jar and msutil.jar.

  3. Copy all the .jar files to the <JRE-path>/lib/ext directory. Where, <JRE-path> indicates the path where the JRE (that is integrated with SBR Carrier) is installed in your system.
  4. Determine the name of the JDBC driver by consulting the documentation provided by the vendor.

    It is usually possible to determine the name of the JDBC driver by executing a shell command similar to: jar -tf mssqlserver.jar |grep Driver. Select the name that most resembles /com/microsoft/jdbc/sqlserver/SQLServerDriver and omit the .class extension.

  5. Use the driver name obtained in Step 4 to configure the Driver parameter in the JDBC plug-in configuration file.

See https://docs.microsoft.com/en-us/sql/connect/jdbc/system-requirements-for-the-jdbc-driver for JDBC driver specifications and its compliance with MS-SQL.

For Oracle:

  1. Download the latest JDBC driver from Oracle that is appropriate for your Oracle server version.
  2. Follow the installation directions provided by the vendor.

    This typically involves extracting a tar file to obtain .jar files that implement the JDBC driver, for example, ojdbc14.jar and possibly others.

  3. Copy all the .jar files to the <JRE-path>/lib/ext directory. Where, <JRE-path> indicates the path where the JRE (that is integrated with SBR Carrier) is installed in your system.
  4. Determine the name of the JDBC driver by consulting the documentation provided by the vendor.

    It is usually possible to determine the name of the JDBC driver by executing a shell command similar to: jar -tf ojdbc14.jar |grep Driver. Select the name that resembles /oracle/jdbc/OracleDriver and omit the .class extension.

  5. Use the driver name obtained in Step 4 to configure the Driver parameter in the JDBC plug-in configuration file.

A similar procedure should be used for other databases that are not listed here. Consult the database vendor documentation for further details.

See http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-faq-090281.html#01_03_1 and http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-faq-090281.html#01_03_2 for JDBC driver specifications and its compliance with Oracle.

Note

In the case of Oracle, the native Oracle Plug-ins are preferred over JDBC Plug-ins since the JDBC API is necessarily more generic, less capable, and less performant than the native OCI API that is used by the native Oracle Plug-ins. Juniper does not recommend the use of Oracle JDBC Plug-ins in cases where no native Oracle Plug-in exists for very old or very new versions of Oracle servers that are no longer or not yet supported by SBRC.