By William De Keyzer
When installing and configuring vRealize Automation and vRealize Orchestrator, the requirement of Active Directory users and groups will undoubtedly come into play sooner or later. It is in the nature of most companies to want to re-use Active Directory accounts in order to easily access the vRealize Automation portal without much impact or (extensive) preparation. The Active Directory structure is there, so why not re-use it, the reasoning goes.
When configuring vRealize Automation (version 7.x), you have to configure a Directory to sync over specific users and groups from an existing Active Directory server. In vRealize Automation the question then is: are you logging in using the sAMAccountName or the UniversalPrincipalName (UPN)?
While most companies prefer to use the sAMAccountName, it doesn’t have to be that way - especially if you are configuring the setup for a large company with many linked Active Directory servers and many different domains, each with potentially different trust relationships. In that case, the sAMAccountNames may not be not unique. The same user could be in different domains, with the same sAMAccountName.
Note: This goes hand in hand if the Active Directory server you connect to is configured as a Global Catalog server, where individual Active Directory servers do not see an overview of the full AD structure, thus allowing non-unique sAMAccountNames to exist.
This obviously causes a major inconvenience for vRealize Automation, as it has no way to determine the actual user to use for logging in. Consequently, the following error is shown when attempting to login, in /var/log/vmware/horizon/connector.log.
For debugging purposes, the following command can be run from the vRealize Automation appliance to search for the user taking note of the amount of different Active Directory accounts that are found. If more than 1 different user is found, the sAMAccountNames are not unique within your environment.
The only way to enable these users to be able to login, is to change to UniversalPrincipalName, as all the domain names which the Global Catalog server can see, must be different – the UPN name will be unique either way.
Unfortunately, changing the directories in vRealize Automation to use UPN instead of sAMAccountName is not possible once the directory has been configured and synced over users and/or groups.
The way to go would be to remove the directory, losing all configuration made in Entitlements, Business Group administrator users and support users etc, which would be a lot of work. Fortunately, there is an easier solution.
When adding a second Directory, you cannot enter the same name or IP address with sAMAccountName binding. What you can do, however, is add a second Directory using the IP address, if it was configured on hostname the first time, or use the hostname if it was configured with an IP address. This way vRA has no issue adding a second Directory using UPN as usernames this time (mind that in reality they are one and the same AD server).
Note: Do not forget to add multiple Connectors to the Identity Provider of this Directory, if you have a distributed environment.
Congratulations, you have now successfully changed from sAMAccountName to UPN. Verify by logging in to vRealize Automation, using UPN (email@example.com). Your entitlements and settings for Business Groups, Fabric Groups, etc. are all left untouched, with the same users/groups configured as before.
While it is a good thing that vRA is working, and users with multiple sAMAccountNames across the environment can now log in again, there is a major inconvenience involved on the vRO side. You can verify if you try to login with the vRealize Orchestrator client - you probably will not succeed logging in anymore.
The problem here is that when UPN is used as username in vRealize Automation, vRA adds the domain a second time while syncing, as seen in the image below.
This is not an issue for vRA portal itself, as the username would be firstname.lastname@example.org and vRA adds the second @domain.com itself - without the user noticing it.
However, when logging in to vRO, you will have to manually add this second @domain.com yourself before you can login again. This means your username will become email@example.com@domain.com for logging into vRO client.
Also, do not trust the Control Center page to test logging on to the vRealize Orchestrator client once you are using UPN. Somehow this test fails with an HTTP error 404 when attempting to test the login.
This is not an official VMware procedure. Perform at own risk, and ensure you can revert to snapshots