This article provides details and a solution for Error Code: 1 when installing or updating the Okta RADIUS agent. This error message may appear slightly different between Windows and Linux failed installations. 

In Windows, the error message shows something similar to: 

Unable to save configuration parameters. Error code: 1.

In Linux, Error Code: 1 usually logs along with a Failed to save properties entry similar to:

ERROR - Failed to save properties
com.okta.agent.AgentRuntimeException: Unknown Token request error: null - null
at com.okta.agent.api.http.RestClient.getTokenFromOAuthCode(RestClient.java:334) ~[okta-agent.base-03.46.00-9e97824.jar:?]
at com.okta.ragent.util.ValidatorUtil.validateCmdArgs(ValidatorUtil.java:188) ~[OKTARadiusAgent.jar:?]
at com.okta.ragent.app.Agent.main(Agent.java:37) ~[OKTARadiusAgent.jar:?]
dpkg: error processing package ragent (--configure):
installed ragent package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
ragent
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

• Okta RADIUS Agent
• Windows
• Linux
• Network Zones
• Threat Insight

This error is known to present when the RADIUS Server Agent is denied connection back to the Okta home tenant. This may happen for a number of reasons, including:

• A network zone is defined to not allow connections from the Server IP address.
• Okta Threat Insight engine has flagged the communication as suspicious. 
• Network traffic interruption from the RADIUS agent is being blocked, or a Downstream Device is interrupting communication.

More details on the root cause of the error Failed to save properties / Unable to save configuration parameters. Error code: 1. may be identified by Working with Okta RADIUS Agent Logs, identifying the request-id before the error message, and searching the request-id in the System Logs from the Okta Admin Console.

Before these error messages present in the RADIUS Logs, there should be a log entry similar to:

01:01:001.001 [main] DEBUG com.okta.agent.api.http.RestClient - Response headers: [Date: <dayname>, <day#> <month> <year> hh:mm:ss GMT, x-okta-request-id: <AlphaNumericValue>]

The x-okta-request-id value can be referenced in the Okta System Log from the Admin Console to reveal more information on the root cause. 

NOTE: If there is downstream network interruption preventing the RADIUS agent from being able to connect back to the Okta Tenant, then an x-okta-request-id may not be present in the RADIUS Logs, and there may be no record or sign of the agent attempting to make a connection to the home tenant in the system log. 

If a x-okta-request-id from the RADIUS agent logs exists, search the Okta system logs to identify the specific issue.

1. Threat Insight blocking

If this error is caused by Threat Insight blocking the request, the following error may appear:

• • Request from suspicious actor - DENY.

NOTE: For more information on Threat Insight Log tracing, see the manual chapter System Log events for Okta ThreatInsight.

When this issue occurs, it is necessary to ensure the RADIUS Agent's server IP address (shown above as 127.0.0.1) is added to the "Legacy Network Zone" "Trusted Proxy IPs" List, and or added to the Threat Insight Exemption Zone. 

2. Blocked by Network Zone

• • If the error is caused by the RADIUS Server IP being blocked by a network zone, Okta Administrators will find a corresponding log in the System Log for the x-okta-request-id stating:

 Blocked request from IP:<ServerIPAddr>

• • A RADIUS Agent's Server IP cannot function while being defined in a Network Zone configured to deny access (for example, the "BlockedIpZone" Network Zone). A resolution for this issue can be found in the article: A Dynamic Blocking Network Zone will Block an Internal Service IP.
  • The network zone is blocking the server based on predefined parameters (for example, IP, location, network type). To allow connections, adjust the Network Zone settings by removing the IP or server location or network type from any direct or indirect restrictions.
  • Okta recommends adding the Okta RADIUS Agent Server IP to the Trusted Proxy IP list within the Network Zone. This way, the server IP is clearly defined in the IP chain as belonging to a trusted proxy location and will allow any additional IPs in the connection chain (like that of the client making authentication requests) to be properly identified and evaluated. 

3. No x-okta-request-id or system log

If there is no x-okta-request-id in the RADIUS agent logs and no sign of the agent attempting a connection in the System Logs from the admin console, ensure the communication is not being interrupted in transit. This is common with appliances like a Firewall, Web App filter, or even DNS configuration. An effective way to quickly check the connection from the server to the Okta tenant would be to launch a web browser from the server and ensure that the browser is able to successfully navigate back to the home tenant (<OrgName>.okta.com) and log in. If the browser is not able to connect, then the RADIUS agent will not be able to, either.