Automation Orchestrator client fails with error 400 "Required query parameter client_id is not present
search cancel

Automation Orchestrator client fails with error 400 "Required query parameter client_id is not present

book

Article ID: 438798

calendar_today

Updated On:

Products

VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

When attempting to log in to the Automation Orchestrator (vRO) client, the page fails to load and displays the following error:

{"timestamp":1777531778355,"type":"CLIENT_ERROR","status":"400 BAD_REQUEST","error":"Bad Request","serverMessage":"400 BAD_REQUEST \"Required query parameter 'client_id' is not present.\""}

Additional symptoms may include:

  • Failure to configure or re-register the authentication provider in the vRO Control Center with an "Error 400".
  • The issue often occurs immediately following a certificate replacement or FQDN/hostname change for Aria Automation (vRA) or the Load Balancer.

Environment

  • Product: VCFAutomation (formerly VMware Aria Suite)
  • Component: Automation Orchestrator (vRO) 8.x

Cause

The Automation Orchestrator has lost its trust relationship with the authentication provider (Aria Automation/vIDM). When certificates are updated or hostnames change, the stored OAuth2 registration becomes invalid or untrusted. Consequently, the client fails to pass the mandatory client_id parameter during the initial authentication handshake.

Resolution

To resolve this issue, you must re-register the vRO authentication provider via the Command Line Interface (CLI) to establish a new trust relationship.

Detailed Steps:

  1. Log in to the vRO Appliance: Connect via SSH as the root user.
  2. Run the Re-registration Command: Execute the vracli command provided above. You will be prompted for the configadmin password.
    bash
     
    vracli vro authentication set -p vra -hn https://<vRA-FQDN> -u configadmin

    Note: Replace <vRA-FQDN> with the Fully Qualified Domain Name of your Aria Automation appliance or Load Balancer.

  3. wait for a few min for the pods to restart.
  4. Open a new browser window to test the login. This ensures that stale OAuth2 session data does not interfere with the new registration.