Join VM to AD with vRealize Automation 8 or Cloud (Part 1)

Joining Virtual Machine to Active Directory domain is a very common use case when building a vRA blueprint. vRealize Automation 8 / Cloud supports several ways to join VM to Active Directory. Depending on the cloud platform we are targeting, whether it is Azure, AWS, vSphere or other platforms, different approaches might be needed to join Virtual Machines provisioned through vRA8 / Cloud to Microsoft Active Directory.


In this article, I outlines 3 different approaches that I use:

1. VM Custom Specification (with built-in vRA integration)

In vRA 7, to join VM to AD, we normally use the built-in AD integration combine with VM Custom Specification. vRealize Automation 8 or Cloud still supports this approach, the configuration in vRA 8 is slightly different compare to vRA 7, to do this, you will need to create the AD integration in vRA 8

And link it to project, you can link more than 1 project for this

Custom specification also needs to be created in vCenter for every Active Directory Domain

The Cloud Assembly blueprint in vRA 8/Cloud can be as simple as this

formatVersion: 1
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      customizationSpec: 'marwin.lab'
      image: 'windows2019'
      flavor: small
      constraints:
        - tag: 'location:sydney'

This approach is really straight forward to set up, could probably be setup in less than 1 day depending on the numbers of datacenter and domain we are targeting, but problem is this only works for vSphere environment, but not for public cloud

2. CloudBase Init

The second approach I tried is to use CloudBase-Init.

CloudBase-init is a tool to perform early-initialization of actions for Windows VM. CloudBase-init is the equivalent of Cloud init for linux, with different modules.

With this approach:

  • we don’t need to configured AD integration in vRA, because CloudBase-init support placing the machine in certain OU when the command is executed
  • we also don’t need to configured custom spec per domain, only 2 custom spec needed: 1 windows and 1 linux

vRA 8 supports triggering of cloud init modules from Cloud Assembly blueprint. To use this approach, CloudBase-init modules/plugin need to be installed in the VM template. This blog by VMware outlines the steps required to setup the VM template

https://blogs.vmware.com/management/2019/11/cloudbase-init-windows-initialization.html

Once template has been setup, the blueprint to join AD is as follow

formatVersion: 1
resources:
  Cloud_Machine_1:
    type: Cloud.Machine
    properties:
      image: 'windows2019'
      hostname: testmm0006
      flavor: small
      constraints:
        - tag: 'location:sydney'
      cloudConfig: |
        #cloud-config
        set_hostname: '${resource.Cloud_Machine_1.hostname}'
        runcmd:
         - 'netsh interface ipv4 add dnsserver "Ethernet0" address=10.0.0.1 index=1'
         - 'netdom join ${resource.Cloud_Machine_1.hostname} /d:marwin.lab /OU:OU=windows,OU=Servers,DC=marwin,DC=lab /ud:administrator@marwin.lab /pd:xxxxx  /reboot'
      remoteAccess:
        username: cloudadmin
        password: xxxxx
        authentication: usernamePassword

While this approach works with multi cloud including private and public cloud, there are few caveats with this way:

  • CloudBase-init need to be setup in all Windows Template including both private and public cloud
  • For vSphere environment, cloudbase-init will not work with static IP assignment in vRA 8
  • To join domain, we need to specify password as part of the command to join domain in the blueprint. This might be a security concern

Conclusion

I managed to get my VM join to AD domain using the two steps above, but it does not satisfy my use case requirements, which is to create a cloud agnostic blueprint and will pass the security team requirement. Custom Specification approach does not work with every clouds, and CloudBase-init approach will need to have the join domain password stored in the Cloud Assembly blueprint. One more issue I found with CloudBase-init approach is I could not get it working with static ip assignment in vSphere environment, I think this is to do with custom specification restarting the VM after it assign the IP address to VM.

I will show the third approach on the next article.

This Post Has 7 Comments

  1. Luke

    Thank you, this is helpful. We would like to change the host name prior to adding the machine to the domain. Have you attempted this and did you have success? If so, how did you do this?

    1. Marwin Ma

      Hi, are you referring to approach 1 or 2? for the first one, you can always overwrite the hostname with hostname property. For second approach, you need to specify the hostname, you might be able to overwrite it with vRO, if needed to, but will become quite messy, i would say use the ansible approach, thats the best amongst all.

  2. Andres

    is the AD integration successfully working for you? I am using AD integration with customization specifications files which fails to use the computer object created by vRA during domain join execution inside the spec file. I end up with two computer objects.

    1. Marwin Ma

      It works for me, and i dont see this issue. How did the computer objects appear in AD? two computers with different name?

  3. Stephen Mak

    it does not work with static ip assignment because vRA runs its own custom specification if you did not specify one. vRA takes the NIC offline before reip which is in conflict with cloudbase init, Your solution is to configure cloudbase init to disable customization specification or add no customization spec to BP.

    resources:
    Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
    Infoblox.IPAM.Network.dnsView: Internal
    image: ‘${input.template_type}’
    cpuCount: 1
    totalMemoryMB: 1024
    hostname: ‘${input.MachineName}’
    newName: ‘${input.MachineName}’
    customizeGuestOs: false

  4. Morti

    Hi, I cant get it to work with the first approach. We are using it like that in current vRA 7.6 installation.
    In our new vRA 8.2 environment
    – I created the AD integration for the wanted AD
    – I linked the project within this AD integration
    – I created a custom spec in vCenter with domain name, user and pass (basically I am using the working one from vRA 7.6)
    – I added “customizationSpec: vRA_Windows_Default” in the bluepront designer

    But when I start a deployment, there is no AD computer object created. Once the VM starts and the custom spec in vCenter is applied to it, it will join the domain but with the object created in default OU “Computers”. And once I delete the deployment that computer account is also not automatically deleted from AD, like it would be if created by the integration.

    So, the user is able to join objects to the AD and I also tested creating manually objects in the OU I want them to be created. So its not a lack of permission 🙁

  5. Vivek

    How can we provide administrator access to a domain user once machine is joined to AD? Is there any way to perform this without vRO or Ansible?

Leave a Reply