Radiator Server Documentation — v10.33.2

reject_errors

Control whether pipeline errors result in request rejection

Table of Contents
  • reject_errors
  • Syntax
  • Parameters
  • Error Information
  • Examples
  • Reject on any pipeline error
  • Use with try-catch for graceful error handling
  • Related

reject_errors

The reject_errors action controls how Radiator handles pipeline errors. By default, when a pipeline error occurs on a RADIUS or TACACS+ request, the request is silently ignored (no response sent). When reject_errors on; is configured, errors cause the request to be rejected instead.

This behavior is chosen because RADIUS and TACACS+ do not have a standard way to communicate internal errors back to clients. For example RADIUS proxies use timeouts to detect broken servers, so sending an Access-Reject in case of internal errors may lead to unexpected behavior.

Syntax

reject_errors on;
reject_errors off;

Parameters

ValueDescription
onPipeline errors cause the request to be rejected (Access-Reject)
offPipeline errors cause the request to be ignored (no response sent)

Error Information

When errors occur, they are captured in the aaa.errors variable, which can be accessed in final-* pipeline stages for logging or debugging purposes.

Examples

Reject on any pipeline error

Enable rejection for errors to ensure clients receive a response:

aaa {
    policy "DEFAULT" {
        handler "AUTHENTICATION" {
            authentication {
                reject_errors on;

                backend {
                    name "USERS";
                    query "FIND_USER";
                }

                pap;
            }

            final-authentication {
                log "AUTHENTICATION" {
                    json {
                        "username" "%{aaa.identity}";
                        "result" "%{aaa.result}";
                        "errors" "%{aaa.errors}";
                    }
                }
            }
        }
    }
}

Use with try-catch for graceful error handling

For more granular error handling, use the try action instead:

authentication {
    try {
        backend {
            name "PRIMARY_DB";
            query "AUTH";
        }
    } catch {
        reject "backend failure: %{aaa.caught_error}";
    }
}
  • try - Catch and handle pipeline errors with custom logic
  • error - Generate an error for testing error handling
  • reject - Explicitly reject a request
Navigation
  • accept

  • all

  • any

  • append

  • assert

  • backend

  • challenge

  • chap

  • conditions

  • copy

  • count

  • debug

  • discard

  • each

  • eap

  • error

  • filter

  • first

  • hotp

  • http-basic-auth

  • if

  • ignore

  • invoke

  • log

  • map

  • message

  • modify

  • mschap

  • mschapv2

  • none

  • pap

  • reason

  • reject

  • reject_errors

  • replace

  • reply

  • rewrite

  • set

  • sleep

  • sometimes

  • stop

  • totp

  • trace

  • try

  • until

  • while

  • with

  • yubikey