In this blog post, I am going to cover the setup of the Active Directory integration with vRealize Automation using LDAPS.

Cloud Assembly supports integration with Active Directory servers to provide out of the box creation of computer accounts in a specified Organizational Unit (OU) within an Active Directory server prior to provisioning a virtual machine.

Note: to join to AD within the Guest OS, you can use CloudConfig properties or vSphere CustomizationSpec.

The VMware official documentation doesn’t really call out LDAPS configuration, only LDAP. So after helping a customer configure this, I thought I’d quickly write something up.

To get started, login into vRealize Automation and select Cloud Assembly.

• Select the Infrastructure Tab
• Select Integrations under the Connections header
• Click the Add Integration button
• Select Active Directory

• Provide a name for the integration
• Input the LDAP Host
  • For LDAPS, you must provide the FQDN of your Active Directory host, an IP address won’t work.
  • You don’t need to specify a port
  • Alternative hosts are not supported for LDAPS configuration
• Select the running environment
  • In my example screenshots, I am using vRA Cloud, so I select the Cloud Extensibility Proxy which has connectivity to my domain controllers.
• Input your LDAP User account for the integration
• Input the LDAP Password account for the integration
• Set the Base DN
• Click to Validate
  • If connectivity is successful, you’ll be asked to accept the certificates of the Domain Controller.
• Click Add to finish the process.

Now the integration has been created, click into it.

Select the Projects Tab and click “Add Project” button to associate this integration to the project.

• Select your project
• the Relative DN where all computer objects will be placed by default
• Select if you want to allow the Cloud Template inputs to override the Relative DN
• Select if you want to allow the Cloud Template configuration to ignore adding a deployed machine resource to Active Directory
  • To do this, you would use the following value in the cloud template machine resource object:
    • ignoreActiveDirectory: ‘true’
• (Optional) Input tags, which can be used to define only when this integration is used in this project, as an additional layer of configuration.
• Click Add

Now we move into the Design tab on Cloud Assembly and create a Cloud Template.

Below I’ve provided a simple Cloud Template which I used for this blog post.

The special call out here, is using the “activeDirectory” property, and “finalRelativeDN” sub-property, which will place the computer account in a specified OU which is different to the one configured (CN=Computers) in the Integration.

formatVersion: 1
inputs: {}
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      name: veducate
      image: deanl-win19-temp
      cpuCount: 4
      totalMemoryMB: 4096
      activeDirectory:
        finalRelativeDN: ou=RDS-Test

Below you can see this configuration visually in vRA.

When I deploy the Cloud Template, I can see under Custom Properties, the metadata from the Cloud Template for the AD configuration. I’ve also highlighted the machine name, so we can reference it within AD in the next screenshot.

Below is my computer account created within the specified “RDS-Test” OU in Active Directory.

It’s all very simple and just works, however the integration capability isn’t listed in the history of the deployment.

To find more information within the platform of this integration, for troubleshooting purposes:

• Click the Extensibility Tab
• Click Action Runs, under Activity, within the left-hand navigation
• Click the “User Runs” blue text and change the filter to Integration runs.

The activity list will now refresh, showing you different actions to previous, including “Action > ad_machine”.

It’s at this point you probably notice the AD integration is python modules running as ABX actions within the Extensibility proxy.

Select one of the actions.

Within the action, you are going to see the python module inputs and outputs from the runtime of the action.

As well as tables for logs to see the console outputs as the code ran, and a trace of feedback of the steps.

And that’s a wrap, setting up LDAPS is as easy as LDAP. And the feature works well out of the box. I do know of some customers who want more power and functionality from interacting with Active Directory when building VMs, and this can be achieved either using custom extensibility in ABX or vRO, or via CloudConfig as in this example from Simon Conyard’s blog post.

Regards

Follow @Saintdle

Dean Lewis