Introduction

Introduction to Radiator Policy Server configuration structure

The basic structure of a Radiator configuration is shown below. The configuration sets up listening to requests from the network, defining allowed request sources, specifying backends from which users are authenticated and policies that tie together clients, policies and users.

A full configuration adds logging, statistics, UI and other configuration parameters too. These are placed in separate numbered files that load before the policy configuration.

The example configurations that come with Radiator split the configuration into easily manageable numbered files. Common settings shared across all examples (license, dictionary, logging, statistics, capture, clients) use prefixes 10_ through 20_. Example-specific settings (backends, servers, policies) use prefixes 30_ through 50_.

Package file structure

Radiator uses a configuration layout:

• Binary: /opt/radiator/server/bin/radiator
• Other read-only assets (dictionaries, templates, built-in failsafe): /opt/radiator/server/
• Working directory (mutable runtime & configuration): /var/lib/radiator. This should not grow to be more than a gigabyte.
• Logs: /var/log/radiator. This can grow up to several gigabytes depending on logging verbosity. See radiator sizing.
• Configuration directory: /var/lib/radiator/. All .radconf files in this directory are loaded in alphabetical order at startup.
• Database and user files: /var/lib/radiator/db/
• Management UI configuration and credentials: /var/lib/radiator/management/

Radiator loads every .radconf file from the configuration directory in alphabetical order. A numeric prefix on each filename controls the load order. For example, 10_license.radconf loads before 15_dictionary.radconf, which loads before 30_backends-file.radconf.

To start the server, run systemctl start radiator-server.service.

Configuration file structure and purposes

Full configuration sample: RADIUS/PAP

This section walks through the pap-minimal example configuration that ships with Radiator. It demonstrates a minimal Password Authentication Protocol (RADIUS/PAP) setup. The configuration files can be found under /opt/radiator/server/doc/example-configurations/pap-minimal or in the radiator-radconfs repository as a .zip package.

PAP-minimal specific files

Detailed look: server configuration

The server configuration in 40_servers-radius.radconf sets up RADIUS UDP listeners. Each server block defines a protocol, port and the client list to use:

servers {

    radius "RADIUS_UDP_1812" {
        # uncomment to enable packet capture for this server
        #capture "CAPTURE_TO_CONSOLE_AND_DIRECTORY";
        listen {
            protocol udp;
            port 1812;
            ip 0.0.0.0;
            ip ::;
        }
        clients "CLIENTS_RADIUS_ALL";
    }

    radius "RADIUS_UDP_1813" {
        listen {
            protocol udp;
            port 1813;
            ip 0.0.0.0;
            ip ::;
        }
        clients "CLIENTS_RADIUS_ALL";
    }

}

Detailed look: backend configuration

The backend configuration for PAP is simple: usernames, passwords and other user information are kept in a file named by the filename parameter. The <root> placeholder resolves to the working directory, /var/lib/radiator.

The backend has name USERS_INTERNAL_FILE. Other parts of the configuration reference this name when they need to look up user data.

This is the full contents of 30_backends-file.radconf:

backends {

    # file backend configuration
    file "USERS_INTERNAL_FILE" {
        filename "<root>/db/users-internal/users-internal.file";
    }

}

Detailed look: policy configuration

The policy configuration in 50_policies.radconf ties everything together. It defines which handler processes each type of request based on conditions:

aaa {
    policy "DEFAULT" {

        handler "AUTHENTICATION" {
            conditions all {
                radius.request.code == radius.ACCESS_REQUEST;
            }

            @execute {
                backend "USERS_INTERNAL_FILE";
                pap;
            }

            @final-execute {
                invoke "LOG_AUTHENTICATION";
            }
        }

        handler "ACCOUNTING" {
            conditions all {
                radius.request.code == radius.ACCOUNTING_REQUEST;
            }

            @execute {
                accept;
            }

            @final-execute {
                invoke "LOG_ACCOUNTING";
            }
        }

        handler "DEFAULT" {
            @execute {
                if all {
                    radius.request.code == radius.ACCOUNTING_REQUEST;
                } then {
                    accept;
                } else {
                    reason "DEFAULT: No other matching authentication handler found.";
                    reject;
                }
            }
            @final-execute {
                invoke "LOG_ACCOUNTING";
                invoke "LOG_AUTHENTICATION";
            }
        }
    }
}

The AUTHENTICATION handler matches RADIUS Access-Request packets, looks up the user in the USERS_INTERNAL_FILE backend and attempts PAP authentication. The ACCOUNTING handler accepts all accounting requests. The DEFAULT handler catches everything else - it accepts accounting but rejects authentication requests that did not match an earlier handler.