Radiator Server Documentation — v10.33.3

reject_errors

Control whether pipeline errors result in request rejection

Table of Contents
  • reject_errors
  • Syntax
  • Parameters
  • Action result
  • 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)

Action result

The reject_errors action changes how later pipeline errors are handled and preserves the previous action result.

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

  • append

  • assert

  • backend

  • challenge

  • chap

  • conditions

  • copy

  • count

  • debug

  • discard

  • EAP

  • error

  • filter

  • hotp

  • http-basic-auth

  • if

  • ignore

  • invoke

  • log

  • map

  • message

  • modify

  • mschap

  • mschapv2

  • must

  • pap

  • reason

  • reject

  • reject_errors

  • replace

  • reply

  • rewrite

  • set

  • sleep

  • sometimes

  • stop

  • totp

  • trace

  • try

  • until

  • yubikey