vRA8 with OneFuse: Active Directory Integration

In this article we are going to create a vRA8 blueprint that utilizes the OneFuse Active Directory module to provide AD integration for provisioned workloads.  We will utilize the Active Directory (AD) policy that we created in the “Creating a OneFuse Active Directory Policy” article.  I will also be leveraging the same blueprint that was used in the “vRA8 with OneFuse: DNS Integration” article to build on the previous example.

By the end of this article we will have added the OneFuse Active Directory (AD) policy to a vRA8 blueprint that is deploying a vSphere machine.  This will be a simple example that we will build upon in future articles.

Before we begin, there are prerequisites you will want to have ready.

Prerequisites

• The OneFuse appliance should be deployed and configured, see the following articles if you need to walk through the OneFuse deployment and configuration.
  • Deploying the OneFuse Appliance
  • Configuring the OneFuse Appliance
  • Creating a OneFuse Active Directory Policy
• The OneFuse Workflow package needs to be installed and configured within vRA8.  The following article can walk you through is you have not completed this yet.
  • Installing the OneFuse Workflow Package into vRA8
• vRA installed and a working vSphere Blueprint

While not required to follow along I will be starting off using a blueprint I had previously utilized in my article vRA with OneFuse: DNS Integration.  If you are just getting started and want to follow along from where we left off in that article you will want to read the below articles before continuing.

• Creating a OneFuse Naming Policy
• vRA8 with OneFuse: Custom Naming
• Creating a OneFuse IPAM Policy
• vRA8 with OneFuse: IPAM Integration
• Creating a OneFuse DNS Policy
• vRA8 with OneFuse: DNS Integration
• Creating a OneFuse Active Directory Policy

Adding the OneFuse Active Directory Integration to a vRA8 Blueprint

I am going to use the blueprint that I walked through in the previous article vRA8 with OneFuse: DNS Integration. To begin you will need to open the blueprint for editing so we can add the appropriate items for consuming the Active Directory integration. Before we begin we will want  to create a new version so we can make a record of the blueprints current state. 

If you are not familiar with how to do this please see the previous article “vRA8 with OneFuse: DNS Integration” for step by step instructions.

Now that we have a tracked version of the current state we can go ahead and add the properties needed to integrate Active Directory into our blueprint.

1. We need to add the following property to our blueprint: OneFuse_ADPolicy
2. Next we need to set the value for the property.  The value is broken up into 2 parts separated by a colon as outlined below.
   1. OneFuse_Endpoint:Policy_Name
      • For my environment this will be onefuseblog:default  This will result in the following being added to the blueprint:
      • OneFuse_ADPolicy: ‘onefuseblog:default’
   2. If you recall in the article “Creating a OneFuse Active Directory Policy” some new inputs were introduced within my AD policy and they were flagged as required. In this example I’m  configuring these as properties on my blueprint so they are passed in as part of the request.   There are many different ways to handle these including taking them as vRA8 inputs into the blueprint.  We will dive deeper into the various options in future articles.
      • The inputs I need to add are:
        • ouGroup
        • ouEnv
        • sgEnv
   3. You can see both the OneFuse_ADPolicy and the added properties in my screenshot below.
      
   4. The complete yaml for my blueprint is below:

formatVersion: 1
inputs: {}
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      #vRA Properties
      imageRef: Centos7
      cpuCount: 1
      totalMemoryMB: 1024
      #OneFuse Module Properties
      OneFuse_NamingPolicy: 'onefuseblog:default'
      OneFuse_IpamPolicy_Nic0: 'onefuseblog:default'
      OneFuse_DnsPolicy_Nic0: 'onefuseblog:default:{{dns_suffix}}'
      OneFuse_ADPolicy: 'onefuseblog:default'
      #Additional Properties used to generate name
      nameGroup: pp
      nameLocation: atl
      nameEnv: prod
      nameOS: l
      nameApp: web
      dns_suffix: infoblox851.sovlabs.net
      #Additional Properties used for Active Directory Integration
      ouGroup: PiedPiper
      ouEnv: PRD
      sgEnv: prod

3. Once you have completed adding the properties to your blueprint select “Deploy”
   • 
4. Give your deployment a name and select “Deploy”
   • 
   • Now that the deployment has been started I want to talk about something that I haven’t discussed yet.  vRealize Orchestrator.  If you launch the vRO web UI and navigate to “Workflow Runs” you will be able to see the OneFuse workflow runs as they execute.  I bring this up now because my Active Directory Policy includes the build OU option which will initially place the AD computer object in a temporary build OU and then move it to it’s final OU once the deployment is complete.  You can see this in the screenshot below.  You will also see the Naming, IPAM, and DNS workflow runs as well.
   • 
5. Now let’s switch back to the OneFuse Appliance and have a look at what objects we have available for each of the modules.
   • First we will look at naming and see the name that was generated for my deployment which is ppatlprodweb015.
     
   • If we next look at IPAM for this deployment we will see the IP Address of 10.30.29.45 reserved for the machine ppatlprodweb015.
     
   • We can then jump over to DNS and see that a host record has been created for the machine ppatlprodweb015 with it’s IP Address of 10.30.29.45.
     
   • Finally if we look at the Managed Active Directory Computer We can see the final OU that the computer object is located within.
     
   • If we look at the “Job” details by selecting the “eye” under the job column we can get additional details including the build OU it was in as well as any security groups that it has been joined to.
     
6. Within vRA8 you can view the details of your deployment and view the name, IP Address, DNS Records, and AD OU that the workload was placed into under the properties sections of the deployment.  Below is a sample of the output data that is returned to vRA8 from OneFuse.

{"_links":{"self":{"href":"/api/v3/onefuse/microsoftADComputerAccounts/1/","title":"ppatlprodlweb015"},"workspace":{"href":"/api/v3/onefuse/workspaces/2/","title":"Default"},"policy":{"href":"/api/v3/onefuse/microsoftADPolicies/1/","title":"default"},"jobMetadata":{"href":"/api/v3/onefuse/jobMetadata/57/","title":"Job Metadata Record id 57"}},"name":"ppatlprodlweb015","id":1,"state":"final","buildOu":"OU=PiedPiper,OU=PRD,OU=build,DC=2k19ad,DC=sovlabs,DC=net","finalOu":"OU=PiedPiper,OU=PRD,OU=final,DC=2k19ad,DC=sovlabs,DC=net","securityGroups":["CN=prodDemoComputers,OU=Groups,OU=SovLabs,DC=2k19ad,DC=sovlabs,DC=net"],"trackingId":"18238259-1687-4b4c-b3ca-e26ab2fa7a43","endpoint":"onefuseblog"}

We have now successfully added and tested Active Directory within vRA8.  While this is a basic example of consuming a simple Active Directory Policy, it is possible to drive the Active Directory (AD) integration more flexibly.  In future articles I will discuss not only how to drive the OneFuse module dynamically, but vRA8 as well.

Want to try out OneFuse with vRA for yourself? Check out the WWT Hands on Lab Accelerating vRealize Automation 8.x with OneFuse.