Active Directory with vRealize Automation and vRealize Orchestrator

By William De Keyzer

Subscribe to our blog

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)?

What if the sAMAccountNames aren’t unique?

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.

2017-01-01 10:00:00,000 INFO  (tomcat-http--5) [NUMBER@TENANT;-;10.0.0.10] com.vmware.horizon.directory.ldap.LdapConnector - Query Completed for SearchDN -  SearchFilter - (&(objectCategory=person)(sAMAccountName=sAMAccountName)) 2017-01-01 10:00:01,000 INFO  (tomcat-http--5) [NUMBER@TENANT;-; 10.0.0.10] com.vmware.horizon.directory.ldap.LdapConnector - Query Completed for SearchDN -  SearchFilter - (&(objectCategory=person)(sAMAccountName= sAMAccountName)) 2017-01-01 10:01:02,000 INFO  (tomcat-http--5) [NUMBER @ TENANT;-; 10.0.0.10] com.vmware.horizon.directory.ldap.LdapDirectoryService - User sAMAccountName not found under base DN  - FAILURE

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.

/opt/likewise/bin/ldapsearch -D "CN=Account,OU=SomeOU,OU=SomeOtherOU, DC=customer,DC=local " -w Password -p 3268 -h 10.0.0.10 -s sub '(&(objectCategory=person)(sAMAccountName=sAMAccountName))'

 

The solution: switching to UniversalPrincipalName

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.

Screen Shot 2017-06-14 at 16.03.22.png

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.

Screen Shot 2017-06-14 at 16.04.19.png

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.

Adding a second Directory using the IP address

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).

Screen Shot 2017-06-14 at 16.06.14.png

The procedure would be the following.

  1. Add a second Directory, using either hostname or IP address – whichever remained unused in the first place.
  2. Sync the exact same users and groups.
  3. Wait for the sync to finish successfully.
    1. You will notice that 0 users and 0 groups are synced, but in the sync log you will see that it attempted to add users but failed to do so – this is perfectly normal as they are already synced over with the other Directory.
  4. Remove the first Directory – the one with sAMAccountName binding.
  5. Trigger another sync of the second Directory - with UPN binding. 
  6. You will notice that users and groups are being synced.

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 (username@domain.com). Your entitlements and settings for Business Groups, Fabric Groups, etc. are all left untouched, with the same users/groups configured as before.

The impact on vRealize Orchestrator

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.

Screen Shot 2017-06-14 at 14.49.23.png

This is not an issue for vRA portal itself, as the username would be username@domain.com 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 username@domain.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.

Screen Shot 2017-06-14 at 15.57.07.png

Remarks:

  • This also means your Endpoint in vRA must be edited so the Credentials are configured to use the @domain.com@domain.com notation as well for data collection of vRealize Orchestrator.
  • The two domain names might not match. Sometimes, username@somethingelse.domain.com@domain.com must be used. This username with double-domain-notation can be found in Directory Users and Groups in the vRA portal. Consult there in case it doesn’t work.

Disclaimer
This is not an official VMware procedure. Perform at own risk, and ensure you can revert to snapshots

Watch the demo for free here


By William De Keyzer on 24 - 07 - 2017

Let’s discuss your situation