Bits and Bytes of Virtualization

Invalid Username or Password When Logging Into Embedded vRO


Granting user authentication from vRealize Automation (vRA) 7.2 to vRealize Orchestrator (vRO) is not as easy as it should be. I received an “Invalid Username or Password” error when logging into vRO, as shown below. vRO with an invalid username or password error.My vRA environment was configured to use my home lab Active Directory (AD) domain without any issue. Next I wanted to get my vRO appliance configured. I logged into the vRO Control Center to configure the authentication and other items. Since I am using the embedded vRO, the Authentication Provider is automatically set to vRealize Automation. The custom tenant was set and I was able to populate the AD groups from the dropdown without any issues. Since I could see my AD groups, I didn’t think vRO would have any issues with authenticating any user within my selected AD group. I was mistaken.

A quick search across blogs and forums did not provide much help. I went to the vExpert Slack channel and hit another roadblock. A couple members told me to follow a blog post from vCOTeam to correctly configure the domain login. I had already tried this without any success. The channel said that is how it works now and could not see much else from the logs I provided. With a bit more searching, I found a blog post on Spas Kaloferov’s blog that was my key to finding the solution to this problem, twice.

Solution 1

The solution that worked in my home lab was referenced under his misconfiguration of the Identity Provider in vRA. He mentions changing the IdP Hostname to the vRA Load Balancer address. Unfortunately, my vRA environment contains zero load balancers. I did notice that my IdP Hostname was not the vRA FQDN. It was set as the hostname with no domain suffix. After changing the IdP Hostname to the correct vRA FQDN, I was able to login with my AD user account.

IdP Hostname with the correct FQDN causes vRO to not authenticate.

Solution 2

While working with a client, I ran into this issue again. Immediately, I checked the IdP Hostname. This time, the IdP Hostname had the correct FQDN configured. Later, we accidentally discovered that the certificate that was generated by one of their team members had a misspelled FQDN for the vRA appliance and lacked another Subject Alternative Name (SAN). A new certificate was generated with all of the correct FQDNs and SANs required for our deployment. This proved to be the solution for their version of this issue.

In Conclusion

VMware needs to address this finicky configuration between vRA and vRO. There are too many variables that may cause this issue.

With the release of vRA/vRO 7.3, they changed the back-end authentication again and will probably eliminate this issue. However, they will create a new issue. They always do.



  1. Setting up a new install of 7.3 and running into this very same issue. Everything looks to be configured correctly, certs a correct with proper SANs, IdP set to LB name…but I can’t log into the VRO client with my AD account that’s part of the specified VRO admins group, but can login with the local admin account I had to create when I setup my custom tenant. I can login to the Control Center just fine with my AD account…

    So I’d like to say things improved in 7.3 in this regard, but it doesn’t appear to be so. (Oh and if you make changes to the Authentication Provider in Control Center and have to step away long enough for the interface to timeout or you Save Settings without actually making changes in the AP – you’ll render the interface inaccessible and will have to run a command against the appliance to reset your authentication in VRO and set it back up again!).

  2. As a follow up to my previous response, my VRO Client login issue ended up being because I had UserPrincipalName selected in the Directory configuration (I could actually login after all if I used the format After noting my sync settings, backing my VROs AP back to the default vsphere.local tenant, I removed/re-added my directory back using sAMAccountName instead. After that, bingo. We’re in business now…

Leave a Reply

Required fields are marked *.

This site uses Akismet to reduce spam. Learn how your comment data is processed.