- Have you been getting certificate trust issues when logging into vRealize Automation 7.x only to find that the certificate is trusted once you are logged in?
- Have you ever noticed that your login page for vRA 7.x uses a different host name in the URL than the application?
- Have you been having difficulty logging into the embedded vRealize Orchestrator instance?
- Have you been trying to use vRealize CodeStream only to find unusual authentication issues?
It could be that you have a simple misconfiguration in your deployment that can be easily corrected. That is the subject of this blog post.
For many deployments, a fully qualified domain name (FQDN) will be selected to access your vRealize Automation (vRA) 7.x application that is different than the actual host name of the box. This alias could be created for a simple installation to make it easier for users to recall the URL or it could be used to access the VIP provided by a load balancer in a more distributed installation.
Depending upon the steps taken during the deployment (e.g., changing the vRA FQDN after the installation), the hostname in the IDP can be different than hostname configured for use with vRA. For example, the following image illustrates the hostname configured for accessing the vRA application in a hands-on lab:
However, after appropriate tinkering, when users attempt to log in, they see the following:
In order to correct this, take appropriate backups then log in as a user with permission to administer the directory configuration (i.e., a tenant administrator). Select the Administration tab and navigate to Directories Management > Identity Providers. Select an IDP and you will be presented with an interface similar to the following:
Take note of the hostname and adjust this to be consistent with the vRA application FQDN found in the administration interface (VAMI) above. It is particularly important to rectify this if you happen to have the short name in the IDP, which can cause a number of problems. The changes take place immediately without restarting any services, though there may be additional steps needed to correct a particular issue. For example, I have had to re-register the vRO authentication after correcting this due to the state it was in after troubleshooting.
For additional reading, please review the following KB article: VMware KB Logging in to embedded vRealize Orchestrator fails (2146063)