vRA 7.3 AD Integration with a Disjointed Namespace – Part 1

During a recent vRA 7.3 enterprise deployment at a customer site, I was required to configure vRA Directories Management to support AD user authentication. The customer had the following constraints, which impacted the expected outcome of this configuration.

  • Non-Windows machines were not allowed to register their DNS A or PTR records in the Active Directory integrated DNS domain.
  • Active Directory integration must be configured using Integrated Windows Authentication if the product supports IWA and LDAP is not permitted
  • Computer objects will be pre-staged in the Active Directory domain
  • vRA appliances and vRA IaaS nodes DNS records were located in different namespaces

This meant we needed to configure an Active Directory IWA to support user authentication using the Directory Management feature however, the AD domain name and DNS zone was a different namespace to the FQDN of the vRA appliances.

In this blog post, I will recreate this use case using the domains below to demonstrate the impact of configuring vRA Directories Management using IWA in a disjointed namespace. I will cover the procedure to remediate the configuration in a part 2.

For further information on disjointed namespaces, please refer to the Microsoft article: Disjoint Namespace

  • vRealize Automation appliances and vRA IaaS nodes are using an AD domain named testlab.com. All these host are configured as <hostname>.testlab.com and name resolution is provided by AD integrated DNS. The vRA IaaS Windows servers are members of the testlab.com domain.
  • vRA is required to support user authentication from an Active Directory domain named offprem.cloudtest.com, as such, considering the constraints, vRA Directories Management will be required to use offprem.cloudtest.com as an identity source for synchronisation

Configure a vRA Active Directory over IWA Connection for Directories Management

Login to the vRA default tenant as a local user with Tenant Administrator privileges

1.9.1

Select Administration > Directories Management > Directories

1.9.2

Click Add Directory and select Add Active Directory over LDAP/IWA.

1.9.3

On the Add Directory page, specify the following:

Enter a Directory Name for the AD domain in the Directory Name text box.

Select the Active Directory (Integrated Windows Authentication) radio button

Select the primary vRA appliance as the Sync Connector from the dropdown list

Do you want this Connector to also perform authentication? Select the Yes radio button

Select sAMAccountName  as the Directory Search Attribute

Enter the name of the AD domain to join and the domain admin credentials.

Enter the Bind User Details in UPN format

Click Save & Next

1.9.4

1.9.5

On the Select the Domains page, select the domains which should be associated with this AD connection.

Click Next

1.9.6

The Directories Management attributes are mapped to the Active Directory attributes. Review and update as required.

Click Next

1.9.7

Select the groups you would like to synchronise from Active Directory

Click Next

1.9.8

Select the users you would like to synchronise from Active Directory

Click Next

1.9.9

Review the page to see how many users and groups will be syncing to the directory.

Click Sync Directory

1.9.10

1.9.11

1.9.12

Symptoms of Configuring Active Directory IWA with a Disjointed Namespace

Configure Directories Management for High Availability

When configuring Directories Management for High Availability, you add the secondary connector to the identity provider, save the settings successfully but the configuration does not remain persistent.

Select Administration > Directories Management > Identity Providers

1.9.13

Click the Add a Connector drop-down list, and select the connector that corresponds to your secondary vRealize Automation appliance.

Enter the appropriate password in the Bind DN and Domain Admin Password fields.

Click Save.

1.9.14

1.9.15

The connector configuration is not saved. This could but just be a UI issue but is an observed symptom I have only witnessed in this use case.

vRA Appliance Hostname

The vRA Appliance hostname in the VAMI network tab has been updated to use the short name.

1.9.17

The hostname of the appliance in the OS has been updated with the FQDN of the IWA AD domain, which in my use case is not resolvable.

1.9.18

vRealize Automation VAMI Cluster

When viewing the vRA Cluster information in the VAMI, the node list is empty.

1.9.19

vRA IaaS Management Agents

The vRealize Automation Management agents config file is updated to the changed FQDN for the vRealize Automation appliance on every vRA IaaS node in the deployment.

The file is located at: <install_path>\VMware\vCAC\Management Agent\VMware.IaaS.Management.Agent.exe.Config

1.9.20

In part 2 of this blog, I will demonstrate how to remediate this use case, and complete the configuration of vRA Directories Management using Active Directory with Integrated Windows Authentication in a disjointed namespace.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s