--- title: RADIUS Decision node description: Configure the RADIUS Decision node to authenticate users against a RADIUS server, handling Access-Accept, Access-Reject, and Access-Challenge responses. component: auth-node-ref version: 8.1 page_id: auth-node-ref::radius-decision canonical_url: https://docs.pingidentity.com/auth-node-ref/latest/radius-decision.html llms_txt: https://docs.pingidentity.com/auth-node-ref/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: 2026-09-01T13:00:59Z keywords: ["Nodes & Trees", "Journeys", "Authentication", "RADIUS"] section_ids: example: Example availability: Availability inputs: Inputs dependencies: Dependencies configuration: Configuration outputs: Outputs callbacks: Callbacks outcomes: Outcomes errors: Errors --- # RADIUS Decision node The RADIUS Decision node performs authentication with the RADIUS (Remote Authentication Dial-In User Service) server, where AM is acting as the RADIUS client. The node performs the following actions: * Sends an `Access-Request` packet to the RADIUS server to initiate the authentication request. * Handles the RADIUS server's response to determine the outcome of the authentication attempt. * Sends additional `Access-Request` packets if the RADIUS server responds with an `Access-Challenge` packet requesting more information from the user. Learn more in [RADIUS Authentication](https://docs.pingidentity.com/pingam/8.1/am-authentication/radius-authentication.html). ## Example The following example shows how you can implement RADIUS authentication with AM acting as the client: ![RADIUS authentication journey](_images/radius-journey.png) * The [Page node](page.html) with the [Platform Username node](platform-username.html) and [Platform Password node](platform-password.html) prompt the user for their credentials. * The [RADIUS Decision node](radius-decision.html) sends the user's credentials in an `Access-Request` packet to the configured RADIUS server. * If the RADIUS server responds with an `Access-Accept` packet, the user is successfully authenticated. * If the RADIUS server responds with an `Access-Reject` packet, authentication fails. * If the RADIUS server responds with an `Access-Challenge` packet, the [RADIUS Challenge Collector node](radius-challenge-collector.html) presents the challenge message to the user and collects their response. After the user has responded, the [RADIUS Decision node](radius-decision.html) sends another `Access-Request` packet to the RADIUS server, including the user's response. Depending on the RADIUS server's response to the second `Access-Request` packet, the user is either authenticated or denied access. ## Availability | Product | Available? | | ------------------------------------- | ---------- | | PingOne Advanced Identity Cloud | Yes | | PingAM (self-managed) | Yes | | Ping Identity Platform (self-managed) | Yes | ## Inputs * The node reads the `username` and `password` from the shared state. For standalone AM deployments, implement a [Username Collector node](am-only/username-collector.html) and a [Password Collector node](am-only/password-collector.html) earlier in the journey. For Ping Identity Platform deployments, implement a [Platform Username node](platform-username.html) and a [Platform Password node](platform-password.html) earlier in the journey. * The node reads the challenge response from the `radiusChallenge` object in the incoming node state if it exists. ## Dependencies This node has no dependencies. ## Configuration | Property | Usage | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Primary RADIUS Servers | A list of primary RADIUS servers to use for authentication.Enter the fully qualified domain name or IP address of the RADIUS server and click Add. You can optionally include the port number after the server name using a colon, for example, `radius.example.com:1812`. If the port number is omitted, the default port number `1812` is used.You can adjust the order of the servers by dragging and dropping them in the list. | | Secondary RADIUS Servers | A list of secondary RADIUS servers to use for authentication if no primary servers are available.Enter the fully qualified domain name or IP address of the RADIUS server and click Add. You can optionally include the port number after the server name using a colon, for example, `radius.example.com:1812`. If the port number is omitted, the default port number `1812` is used.You can adjust the order of the servers by dragging and dropping them in the list. | | RADIUS Shared Secret Label Identifier | An identifier used to create a secret label for mapping to the shared secret in the secret store. The shared secret is used to secure communication between AM and the RADIUS server.When you enter an identifier in this field, a secret label is automatically created with the format `am.authentication.nodes.radius.identifier.secret`. For example, if the identifier is `myRadius`, AM creates the label `am.authentication.nodes.radius.myRadius.secret`.When the journey processes the node, it retrieves the shared secret from the secret store using the generated secret label.The identifier can only contain alphanumeric characters (`a-z`, `A-Z`, `0-9`) and periods (`.`). It can't start or end with a period.Learn about mapping secrets in [Map and rotate secrets](https://docs.pingidentity.com/pingam/8.1/security/secret-mapping.html). | | Timeout | The number of seconds to wait for the RADIUS server to respond.Default: `5` | | Health Check Interval | The number of minutes between health checks to previously unavailable RADIUS servers.Default: `5` | | Stop RADIUS binds after lockout | Select this option to prevent the node from sending `Access-Request` packets to the RADIUS server if the user's account is locked in AM.Default: Not enabled | | Require Message-Authenticator attribute | To mitigate the risk of a [Blast-RADIUS attack](https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/), select this option to make the `Message-Authenticator` attribute required in all packets sent to and from the RADIUS server.You can use this attribute (defined in [RFC 3579](https://datatracker.ietf.org/doc/html/rfc3579#section-3.2)) to verify incoming RADIUS responses to prevent spoofing.When this option is enabled:- AM includes a valid `Message-Authenticator` attribute in the `Access-Request` packets it sends to the RADIUS server. - AM expects the RADIUS server to include a valid `Message-Authenticator` attribute in the `Access-Accept`, `Access-Reject` and `Access-Challenge` packets. If the attribute isn't present or is invalid, AM silently drops the response and continues listening for responses until the timeout period has elapsed.Default: Enabled | ## Outputs The node has the following outputs depending on the RADIUS server's response: * Access-Accept The node adds the `radiusAttributes` object to shared state if the RADIUS server responds with an `Access-Accept` packet that includes [Vendor-Specific Attributes (VSA) (Attribute 26)](https://datatracker.ietf.org/doc/html/rfc2865#section-6.2). The `radiusAttributes` object includes the following information: ```json { "vendorId": "", "bytes": "" } ``` Connect the `Accept` outcome to a [Scripted Decision node](scripted-decision.html) to read the VSA and make decisions based on the custom data provided by the RADIUS server. > **Collapse: Sample script** > > The following sample script retrieves the `radiusAttributes` object from shared state. It then parses the `bytes` field for specific details, obtains the value for a specific vendor ID, and validates the result against a custom value. > > | | | > | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | | This example assumes the following VSA structure:- Byte 0: Type > > - Byte 1: Length > > - Bytes 2-5: Vendor ID > > - Byte 6: Sub-type > > - Byte 7: Sub-length > > - Bytes 8-n: ValueAdjust the script to match the structure of your VSA. | > > ```javascript > var radiusAttrs = nodeState.get("radiusAttributes"); > var attr = radiusAttrs.get(0); > var bytes = attr.get("bytes"); > var value = null; > > // parse the bytes value for the vendor ID (bytes 2-5) > var b0 = bytes[2] & 0xFF; > var b1 = bytes[3] & 0xFF; > var b2 = bytes[4] & 0xFF; > var b3 = bytes[5] & 0xFF; > var vendorId = (b0 << 24) | (b1 << 16) | (b2 << 8) | b3; > > // parse sub-type (byte 6) > var subType = bytes[6] & 0xFF; > > if (vendorId == vendor-id) { // replace vendor-id with a valid numeric vendor ID > > // decode the bytes value (bytes 8-n) > value = new java.lang.String(bytes, 8, bytes.length - 8); > } > > if (value === "custom-value") { // replace custom-value with the value to check > outcome = "true"; > } else { > outcome = "false"; > } > ``` * Access-Challenge The node adds the `radiusChallenge` object to transient state if the RADIUS server responds with an `Access-Challenge` packet. The `radiusChallenge` object includes the following information: ```json { "octets": "", "replyMessage": "", "response": null } ``` ## Callbacks This node doesn't send any callbacks. ## Outcomes * Accept The RADIUS server responds with an `Access-Accept` packet and the user is successfully authenticated. * Reject The RADIUS server responds with an `Access-Reject` packet and authentication fails. * Challenge The RADIUS server responds with an `Access-Challenge` packet requesting additional information from the user. Connect this outcome to the [RADIUS Challenge Collector node](radius-challenge-collector.html) to present the challenge message to the user and collect their response. * Error The node encounters an error and authentication fails. ## Errors The node can log the following: * Warnings * `User account is locked: username` The user's account in AM is locked. * `Could not find user identity for username: username` The node can't find a user profile in AM for the username. * Errors * `Error connecting to RADIUS server` The node can't connect to the RADIUS server.