Opsmanager Upgrade to 3.3.x fails login after successful import of installation.zip
search cancel

Opsmanager Upgrade to 3.3.x fails login after successful import of installation.zip

book

Article ID: 442200

calendar_today

Updated On:

Products

VMware Tanzu Platform - Cloud Foundry

Issue/Introduction

After deployment of Opsman OVA and import of installation.zip using correct passphrase the login to UI fails with invalid credentials. Error can be seen when attempt to login

2026/05/20 09:29:03 token could not be retrieved from target url: An error occurred while calling https://OPSMAN/uaa/oauth/token {"error":"invalid_client","error_description":"Bad credentials"}

The decrypt and import of the installation.zip end up in a Opsman, that seems to be up and running, but the login credentials are denied.


Deleting the Opsman and reverting to older 3.2.x version for example Opsman 3.2.6 works fine and the login-credentials from admin-account is accepted.
Trying to update the admin-password in opsman 3.2.x and do the upgrade afterwards does not help when completed from https://<OPSMAN>/uaa/profile (from admin - my account)

Environment

Opsman 3.3.x upgrade from Opsman 3.2.x

Cause

The reason for the problem is likely to be related to discrepancy between the tables in the Opsman database.

The correct way to update the admin password In the classic ui, the appropriate page for changing a user's password is /classic/internal_identity_provider/new.

In the Foundation Core UI, it is /core/settings/internal-authentication.

From classic view from settings (top right corner):

Internal Authentication Settings -> 
provide passphrase and update the admin pass with passphrase or set your own.

Once the change is applied, the restart of opsman persists the change 

The reason for the discrepancy:

The uaa.yml file is generated by the ops manager process. The source of truth for all uaa config is the ops manager database.

In 3.3.x  the config in the ops manager database overrides any config in the uaa database. In 3.2.x and below, this isn't the case.

Correcting the password should fix the Opsman login process. 

 

Resolution

To resolve this problem.

Option 1:

SSH to Opsman and attempt to retrieve the password from uaa.yml

sudo cat /var/vcap/jobs/uaa/config/uaa.yml| grep admin
...
  - admin|<PASSWORD>|[email protected]|OpsMan|Admin|opsman.admin,scim.me,uaa.admin,clients.admin|uaa

Login to opsman with the admin/<PASSWORD> and then update the password from https://<OPSMAN>/classic/internal_identity_provider/new using passphrase and update the password.

Option 2: 

In case you cannot login to UI using Option 1:

Revert to 3.2.x if the Old Opsman is still present revert to it, In case the Opsman is not available (deleted) deploy Opsman OVA 3.2.x and import installation.zip

Confirm you can login 

Update the password from https://<OPSMAN>/classic/internal_identity_provider/new using passphrase and update the password.

 

Exporte the new installation.zip 

Deploy 3.3.1 using the new zip and the login should be successful with the updated password