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 and its subdirectories are loaded at startup, in the order described in Configuration directory load order.
• Database and user files: /var/lib/radiator/db/
• Radiator UI configuration and credentials: /var/lib/radiator/management/

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

Configuration directory load order

When Radiator Server starts with a configuration directory, it loads every .radconf file in the directory and its subdirectories. Files merge in load order. For example, 10_license.radconf loads before 15_dictionary.radconf, which loads before 30_backends-file.radconf.

Radiator Server orders the files as follows:

1. Files in the management/ directory at the root of the configuration directory load first.
2. All other files are compared one path component at a time, so the directories in a path control the order before the file name does. For example, every file under 10_common/ loads before every file under 20_policies/.
3. A component is numbered when its name starts with digits that are followed by _, -, . or the end of the name. 10_clients.radconf, 10-clients.radconf, 10.radconf and a directory named 10 all have the number 10. Leading zeros don't change the number: 010-clients.radconf also has the number 10.
4. Numbered components load in ascending numeric order, so 9-a.radconf loads before 10-a.radconf, which loads before 100-a.radconf.
5. Components with the same number load in the text order of their full names. For example, 10-b.radconf loads before 10_a.radconf because - sorts before _.
6. Unnumbered components load after all numbered ones, in the text order of their names. A name such as 10abc.radconf is unnumbered because the digits are not followed by _, - or ..

Files and directories whose name starts with _ are not loaded. Rename a file to start with _, for example _50_policies.radconf, to disable it.

Package-manager backup and staging entries are ignored without warnings, including their contents when they are directories. The ignored suffixes are:

• Debian dpkg: .dpkg-dist, .dpkg-old, .dpkg-new, .dpkg-tmp, .dpkg-bak, .dpkg-backup and .dpkg-remove.
• RPM: .rpmnew, .rpmsave and .rpmorig.
• Debian ucf: .ucf-dist, .ucf-old and .ucf-new.

Suffix matching is case-insensitive and applies at every directory depth. Other unsupported suffixes still produce configuration warnings.

Note: Earlier Radiator Server versions treated only _ as the end of a number, so names such as 10-clients.radconf were unnumbered and loaded after all underscore-numbered files.

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 "RADIUS" {

        conditions all {
            aaa.protocol == protocol.RADIUS;
        }

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

            @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.