v10.33.2

AAA Stop Location

Radiator Server now exposes aaa.stop_location in the execution context. The value is a read-only string in file:line format that points to the last executed pipeline action.

This helps when you need to log or inspect where request processing stopped or last advanced in a policy.

log "AUTHENTICATION" {
    json {
        "stop_location" "%{aaa.stop_location}";
    }
}

Pipeline Action Error Log Field

Radiator Server now includes an action_error field in AAA Pipeline Action trace log entries when an action fails with action_result: error.

This makes it easier to diagnose pipeline failures from a single structured log entry without having to correlate the failure with a separate error log.

See also: Log storage and formatting

Clear rejection reason when the pipeline succeeds

Previously, if a backend miss set a rejection reason on the AAA context and a later action led to an accepted result, the stale reason could still appear in the final response. This could produce misleading log entries and responses showing a rejection reason even though the request was ultimately accepted.

The pipeline now clears the rejection reason only when the final pipeline result is accept, ensuring that stale reasons are removed from successful responses without discarding reasons that still apply when the pipeline later rejects the request.

NTLM Helper Program Lookup

The NTLM backend program setting now accepts either an absolute path or a plain command name that the operating system resolves through PATH.

This makes it easier to run NTLM helpers through platform-managed wrappers, shell shims, or other environment-specific command names without hardcoding a full filesystem path.

If the configured command cannot be found, the error now comes from process startup when Radiator tries to launch the helper.

Related documentation has been updated in docs/configuration/backends.system.md.

Backend queries now set a rejection reason when no results are found

JSON file, LDAP, MySQL, PostgreSQL, and SQLite backend queries now set aaa.reason when a query finds no matching records. The reason includes the backend name and query name, which makes authentication failures easier to diagnose in logs, policies, and management responses.

Documentation for this behavior is now included in the backend reference pages:

• JSON file backend
• LDAP backend
• MySQL backend
• PostgreSQL backend
• SQLite backend

LDAP WhoAmI health checks tolerate unwillingToPerform

Radiator now treats an LDAP connection as healthy when the server rejects the WhoAmI extended operation with unwillingToPerform during shared connection health checks.

This improves compatibility with LDAP servers such as Okta, which reject the WhoAmI operation even when the connection is otherwise usable for backend queries.

Fixed MS-CHAP and MS-CHAPv2 Routing in Shared Handler Chains

Radiator now routes mschap and mschapv2 requests to the correct extractor when both are used in the same first { ... } handler chain. This removes config ordering sensitivity for shared MS-CHAP and MS-CHAPv2 pipelines, including EAP-TTLS inner authentication.

This fixes cases where an EAP-TTLS MS-CHAPv2 request could be picked up by the MS-CHAP extractor first and fail before the MS-CHAPv2 path ran. Shared plain RADIUS handler chains that accept both methods also work correctly.

Fixed MS-CHAPv2 Authentication for Domain-Qualified Usernames

EAP-TTLS MS-CHAPv2 authentication now correctly verifies usernames that include a Windows domain prefix, such as DOMAIN\user.

Radiator now preserves the inner tunneled username for MS-CHAPv2 verification and strips the domain prefix consistently when computing the MS-CHAPv2 challenge hash. This lets domain-qualified inner usernames authenticate correctly while still allowing backend lookups to rewrite the identity if needed.

Add --auth-method to radiator-client

The radiator-client tool now supports --auth-method for Access-Request password authentication. The default pap mode keeps using User-Password, while mschap and mschapv2 generate the required MS-CHAP-Challenge and response attributes automatically from --user and --password.

mschap and mschapv2 are supported only with --type auth.

radiator-client \
    --server 127.0.0.1 \
    --secret mysecret \
    --user 'DOMAIN\alice' \
    --password secret \
    --auth-method mschapv2

Use this to test handlers and backends that require MS-CHAP or MS-CHAPv2 without building the protocol attributes manually.

See radiator-client documentation for option details and examples.

Configuration Archive Metadata

Configuration export and backup ZIP files now include .radiator-archive-metadata.json at the archive root. The metadata records the radiator-server version that created the archive, when it was created, and the management user involved when available.

Automatic deployment backups also record the deployed files and their change types. The Management UI shows this information in the backup restore dialog, and configuration import responses now include a non-blocking warning when an archive was created by a different radiator-server version.

HTTP Responses Can Omit The Body

HTTP server policies can now use http.response = none to send no response body. This is useful with http.status = http.NO_CONTENT when a handler should return 204 No Content without the default JSON response wrapper.

modify {
    http.status = http.NO_CONTENT;
    http.response = none;
}

Nested assignments still behave as JSON fields. For example, http.response.body = none still returns {"body":null}.

The HTTP server documentation now includes a dedicated response construction section that explains http.response, http.response_header.NAME, http.json = false, and the difference between top-level and nested none assignments. See HTTP server configuration.

ipmap backend

Added a new ipmap backend that provides in-memory longest-prefix matching lookups. Populate the map from any data source (SQLite, RadiatorDB, or inline configuration) and query it at runtime to resolve IP addresses with no network I/O or external dependencies.

Key capabilities:

• Longest-prefix matching for both IPv4 and IPv6 addresses
• Populate from any backend or statically with modify actions
• Automatic periodic repopulation with interval
• Manual repopulation via the REST API
• Dynamic RADIUS client resolution in @pre-client hooks

backends {
    ipmap "IPMAP" {
        interval 5m;

        query "LOOKUP" {
            lookup radius.request.attr.NAS-IP-Address;
            mapping {
                vars.device_name = value;
            }
        }

        @populate {
            backend {
                name "SQLITE";
                query "POPULATE_IPMAP";
            }
        }
    }
}

New split() and rsplit() filters

Radiator now supports both split() and rsplit() value filters in expressions, with an optional maxsplit argument.

Use split(",") to split on a fixed string separator, or use a regex separator such as split(/[,-]+/) when the input can contain multiple delimiter variants. If you pass maxsplit, such as split(",", 1), at most that many splits are performed from the left.

Use rsplit() when you need the same behavior but want maxsplit to apply from the right. For example, rsplit(",", 1) keeps the rightmost field separate and leaves the remaining prefix unsplit.

See Filters for filter usage and examples.

TACACS+ built-in authorization session timeout

Radiator now documents and defaults the built-in TACACS+ authorization session cache to 15m per TACACS+ server.

Use session-timeout in the TACACS+ server block to override the default cache lifetime. Successful authorization cache hits refresh the lifetime while the session stays active.

The built-in TACACS+ authorization session cache stores a sanitized user snapshot for later authorization requests. The stored fields are:

• user.username
• user.group
• user.role
• user.backend
• user.privilege

Authentication-only state such as password authenticators, per-user conditions, and post-authentication callbacks is not stored.

See TACACS+ Authentication, Authorization, and Accounting for details.

TACACS+ TLS and interoperability improvements

Radiator Server now supports TACACS+ over TLS on server listeners. Combining tls and proxy-protocol on the same TACACS+ or RADIUS listener is rejected at configuration load. Challenge-driven (multistage ASCII) authentication flows have been clarified, including secret handling and the TACACS+ script context.

See TACACS+ Authentication, Authorization, and Accounting for configuration details and a worked multistage example.