Automation Assembler 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. Active Directory supports an LDAP connection to the Active Directory server.

An Active Directory policy that is associated with a project is applied to all virtual machines provisioned within the scope of that project. Users can specify one or more tags to selectively apply the policy to virtual machines that are provisioned to the cloud zones with matching capability tags.

When an Active Directory integration is created, some properties are set during the creation of the computer object in Active Directory and cannot be changed. In particular, the following default properties cannot be changed: 
WORKSTATION_TRUST_ACCOUNT	0x1000
PASSWD_NOTREQD (No password is required)	0x0020

For on-premises deployments, Active Directory integration enables you to set up a health check feature that shows the status of the integration and the underlying ABX integration on which it relies, including the required extensibility cloud proxy. Prior to applying an Active Directory policy, Automation Assembler checks the status of the underlying integrations. If the integration is healthy, Automation Assembler creates the deployed computer objects in the specified Active Directory. If the integration is unhealthy, the deploy operation skips the Active Directory phase during provisioning.

Prerequisites

  • Active Directory integration requires an LDAP connection to the Active Directory server.
  • If you are configuring an Active Directory integration with vCenter on-premises, you must configure an ABX integration with an extensibility cloud proxy. Select Infrastructure > Connections > Integrations > then click Add Integration and choose Extensibility Actions On Prem. See Configure an on-premises action-based extensibility integration in Automation Assembler for more information.
  • If you are configuring an integration with Active Directory in the cloud, you must have a Microsoft Azure or Amazon Web Services account.
  • You must have a project configured with appropriate cloud zones, and image and flavor mappings to use with the Active Directory integration.
  • If you are running an on-premises Active Directory, verify that you have installed and configured a cloud extensibility proxy. See Download and deploy a cloud extensibility proxy.
  • The desired OU on your Active Directory must be pre-created before you associated your Active Directory integration with a project.
  • The user configured for the Active Directory integration must have permissions to create/delete/search for computer objects in the configured OU.

Procedure

  1. Select Infrastructure > Connections > Integrations and then New Integration.
  2. Click Active Directory.
  3. On the Summary tab, enter the appropriate LDAP host and environment names.
    If you are running an on-premises Active Directory, the running environment must be the name of your extensibility proxy. If you are running Active Directory on Microsoft Azure or Amazon Web Services in the cloud, enter the account name.
    The specified LDAP host is used to validate the Active Directory integration, and it is also used for subsequent deployments if no alternative hosts are specified and invoked due to errors or unavailability.
  4. Enter the name and password for the LDAP server.
  5. Enter the appropriate Base DN that specifies the root for the desired Active Directory resources.
    Note: You can specify only one DN per Active Directory integration.
  6. Click Validate to ensure that the integration is functional.
  7. Enter a Name and Description of this integration.
  8. Click Save.
  9. Click the Project tab to add a project to the Active Directory integration.
    On the Add Projects dialog, you must select a project name and a relative DN, which is a DN that exists within the Base DN specified on the Summary tab.
  10. Under the Extended Options selection, provide a comma separated list of Alternate Hosts that will be used if the initially selected server is unavailable during deployment. The primary server is always used for initial validation of the integration.
    Note: If the format of the primary host is LDAP, LDAPS is not supported for alternative hosts.
  11. Enter the time in seconds to wait for the initial server to respond before trying an alternate server in the Connection Timeout box.
  12. Click Save.

Results

You can now associate the project with Active Directory integration to a cloud template. When a machine is provisioned using this cloud template, it is pre-staged in the specified Active Directory and Organizational Unit.

Initially, Active Directory integrations are deployed to a default OU with little user restrictions. The OU is set by default when you map an Active Directory integration to a project. You can add a property called FinalRelativeDN to blueprints to change the OU for Active Directory deployments. This property enables you to specify the OU to use with an Active Directory deployment.

formatVersion: 1
inputs: {}
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: CenOS8
      flavor: tiny
      activeDirectory:
        finalRelativeDN: ou=test
        securityGroup: TestSecurityGroup

As shown in the preceding YAML example, users can add a property to an Active Directory integration deployment that adds a computer account to the security group so that appropriate permissions are assigned to access the shared resource over a network. The Active Directory virtual machine is initially deployed to a fixed OU but when the machine is ready to release, it is moved to a different OU with the appropriate policy as applicable for users.

If a computer account is moved to a different OU after deployment, Automation Assembler attempts to delete the accounts on the initial OU. Deletion of computer accounts succeeds only in the case of virtual machines moved to a different OU within the same domain.

You can also implement a tag-based health check for on-premises Active Directory integrations as follows.

  1. Create an Active Directory integration as described in the preceding steps.
  2. Click the Project tab to add a project to the Active Directory integration.
  3. Select a project name and a relative DN on the Add Projects dialog. The relative DN must exist within the specified base DN.

    There are two switches on this dialog that enable you to control Active Directory configuration from cloud templates. Both switches are off by default.

    • Override - This switch enables you to override Active Directory properties, specifically the relative DN in cloud templates. When switched on, you can change the OU specified in the relativeDN property in the cloud template. When provisioned the machine will be added to the OU specified in the relativeDN property in the cloud template. The following example shows the cloud template hierarchy in which this property appears.
      activeDirectory:
     relativeDN: OU=ad_integration_machine_override
    • Ignore - This switch enables you to ignore the Active Directory configuration for the project. When switched on, it adds a property to the cloud template called ignoreActiveDirectory for the associated virtual machine. When this property is set to true means that the machine is not added to the Active Directory when deployed.
  4. Add appropriate tags. These tags are applicable to the cloud zone to which the Active Directory policy may apply.
  5. Click Save.

The Status of the Active Directory integration is displayed for each integration on the Infrastructure > Connections > Integrations page in Automation Assembler.

You can associate the project with Active Directory integration with a cloud template. When a machine is provisioned using this template, it is pre-staged in the specified Active Directory and OU.