vRealize Automation – Forest Trusts

This article is going to cover an issue I came across when testing out an authentication scenario with vRA 7.5 for one of my customers.  The scenario was as follows.

My customer currently uses a single forest and single domain where vRA currently resides and leverages Active Directory IWA authentication using the embedded vIDM.  Before moving this environment to a production status they have a company requirement for user accounts to be based in a separate forest and domain to computer accounts, which is trusted by the forest/domain that vRA currently uses and vRA permissions to be granted through the forest/domain that vRA is connected to.  Lets show this as a diagram.

cross-forest trusts with vra

In the above diagram the vRA users are in domain 1, placed inside Global Groups also within domain 1.  The Global Groups are placed inside Domain Local Groups in domain 2.  There is only a 1-way forest trust.

We state in our documentation that a 2-way trust is required however my customer wanted to test whether this actually was required as it would mean making directory level changes within their production environment which they were not keen to do.

In order for users to be visible within vRA and for permissions to be granted and controlled via the Domain Local Groups in domain 2, the trusted domain 1 needs to be added into the existing directory configuration rather than creating a separate vRA directory for domain 1.  This should allow domain 1 users to be visible and login to vRA by granted access to domain 2 groups.

The first issue that is apparent is that although the configuration from the above diagram (1-way trust) allows the directory and group level configuration to be made, it does not allow vRA to add domain 1 into the domain 2 vRA directory configuration.  Trying to do this results in an error similar to this.

Screenshot 2019-01-09 at 12.31.54.png

In this example the domain “corp.local” is our domain 1 we are trying to add to the existing directory configuration.  In reality the above error can have numerous causes even though it implies there is a resolution issue.

My first attempt at resolving the issue focused on DNS and directory level issues.  The use of zone replication rather than using conditional forwarders between domain DNS servers did not change anything.  Looking at the horizon logs in vRA resulted in the following error every time I tried to save the directory configuration.

2018-12-21T14:32:07,705 ERROR (resourceSyncTaskExecutor-2) [;;;] com.vmware.horizon.directory.ldap.LdapCrossRefService – com.vmware.horizon.directory.DirectoryServiceException: Authentication failed for the given user name and password
2018-12-21T14:32:07,705 ERROR (tomcat-http–24) [VSPHERE.LOCAL;configurationadmin@VSPHERE.LOCAL;;] com.vmware.horizon.directory.ldap.TrustedForestSearchService – Unresolvable host and port for cross ref object for – corp.local
2018-12-21T14:32:07,718 INFO (tomcat-http–24) [VSPHERE.LOCAL;configurationadmin@VSPHERE.LOCAL;;] com.vmware.horizon.directory.ldap.dc.service.context.JNDIContextFetcher – LDAP Context env Json Values: {
“java.naming.provider.url” : “ldap://corp2dc.corp2.local”,
“java.naming.factory.initial” : “com.sun.jndi.ldap.LdapCtxFactory”,
“com.sun.jndi.ldap.connect.timeout” : “10000”,
“java.naming.security.authentication” : “GSSAPI”,
“com.sun.jndi.ldap.read.timeout” : “600000”,
“java.naming.ldap.attributes.binary” : “objectGUID pae-IconData objectSid securityIdentifier”

The bind account being used was verified as having rights within both domains so a permissions error within the directory was unlikely.  The account was also working fine with just domain 2 so a wrong password was also ruled out.

On examination of dcdiag on both domains (dcdiag /e) I found directory partition errors in domain 1 that I was trying to add.  Demoting my single domain controller back to a stand alone box, performing a metadata cleanup and re-creating the domain (including re-forming the forest trust) enabled me to get rid of all the partition errors however it still did not allow me to save the directory configuration in vRA.

Attempt number 2 focused on forest trust configurations and sure enough moving to a 2-way forest trust instantly resolved the issue.  Through the use of snapshots and reverting back to a pre metadata cleanup state of domain 1, I was able to try creating the 2-way trust with the partition errors still in place and then re-try applying the configuration within vRA.  This did not fix the issue.

So in this particular case, resolving both the partition errors AND implementing the 2-way trust between forests enabled me to use domain 1 within the existing directory configured in vRA.