How to create an Automation Assembler template that adds users to Active Directory

In addition to the Automation Assembler cloud template resources that you use when you create cloud templates, you can also create your own custom resources.

Custom resources are Automation Orchestrator or extensibility action objects that you manage through Automation Assembler with the lifecycle actions defined in the custom resource. The cloud template service automatically calls up the appropriate Automation Orchestrator workflows or extensibility actions when the operation associated with a specific lifecycle action is triggered. You can extend the functionality of the resource type by also selecting Automation Orchestrator workflows or extensibility actions that can be used as day 2 operations.

This use case uses built-in workflows that are provided in the Automation Orchestrator library. It includes prescriptive values or strings to demonstrate how to perform the process. You can modify them to suit your environment.

For reference purposes, this use case uses a project named DevOpsTesting. You can replace this sample project with any project in your environment.

Prerequisites

Verify that you configured an Automation Orchestrator integration. See Configure an Automation Orchestrator integration in Automation Assembler.
Verify that the workflows that you are using for the create, update, destroy, and day 2 actions exist in Automation Orchestrator and run successfully from there.
In Automation Orchestrator, locate the resource type used by the workflows. The workflows included in this custom resource must all use the same resource type. In this use case, the resource type is AD:User. For more information on resource type validation, see Custom resource types for Automation Assembler cloud templates.
By using the built-in Active Directory workflows in your Automation Orchestrator integration, configure an Active Directory server.
Verify that you know how to configure and deploy a machine cloud template.

Procedure

Create an Active Directory custom resource for adding a user in a group.

This step adds the custom resource to the cloud template design canvas as a resources type.

In Automation Assembler, select Design > Custom Resources, and click New Custom Resource.

Provide the following values.

Remember, except for the workflow names, these are sample values.


Setting	Sample Value
Name	`AD user` This is the name that appears in the cloud template resource type palette.
Resource Type	`Custom.ADUser` The resource type must begin with `Custom.` and each resource type must be unique. Although the inclusion of `Custom.` is not validated in the text box, the string is automatically added if you remove it. This resource type is added to the resource type palette so that you can use it in the cloud template.

To enable this resource type in the cloud template resource type list, verify that Activate option is toggled on.
Select the Scope setting that makes the resource type available to any project.
Under Based on, verify that vRO Inventory is selected as the lifecycle action provider.

Select the workflows that define the resource and the day 2 actions.

Note: The selected day 2 workflows must have an input parameter that is of the same type as the external type. The external type input is not displayed in the day 2 custom form requested by the user, as it is automatically bound to the custom resource.


Setting	Sample Value
Lifecycle Actions - Create	Select the Create a user with a password in an organizational unit workflow. If you have multiple Automation Orchestrator integrations, select the workflow on the integration instance you use to run these custom resources. After selecting the workflow, the external type drop-down menu becomes available and is automatically set to `AD:User`. Note: An external source type can be used only once if shared and once per project. In this use case, you are providing the same custom resource for all the projects. It does mean that you cannot use `AD:User` for any other resource types for all projects. If you have other workflows that require the `AD:User` type, you must create individual custom resources for each project.
Lifecycle Actions - Destroy	Select the Destroy a user workflow.
Additional Actions	Select the Change a user password workflow. On the Add Action window, add a name for the action, such as `password_change` and click Add. To modify the action request form that the user responds to when they request the action, click the icon in the Request Parameters column. Note: For additional action workflows, verify that the workflow has a input parameter that is of the same type as the external type.

In this example, there is no appropriate application of an update workflow. A common example of an update workflow, which makes changes to the provisioned custom resource, is scaling in or scaling out a deployment.

Review the schema key and type values in the Properties tab so that you understand the workflow inputs so that you can configure the inputs in the cloud template.
The schema lists the required and optional input values defined in the workflow. The required input values are included in the cloud template YAML.
In the Create a user workflow, accountName, displayName, and ouContainer are required input values. The other schema properties are not required. You can also use the schema to determine where you want to create bindings to other field values, workflows, or actions. Bindings are not included in this use case.
To finish creating your custom resource, click Create.

Create a cloud template that adds the user to a machine when you deploy it.
1. Select Design > Cloud Templates, and click New from > Blank canvas.
2. Name the cloud template Machine with an AD user.
3. Select the DevOpsTesting project and click Create.
4. Add and configure a vSphere machine.
5. From the custom resource list on the left of the cloud template design page, drag the AD user resource type onto the canvas.
  
  Note: You can select the custom resource by either scrolling down and selecting it from the left pane, or searching for it in the Search Resource Types text box. If the custom resource does not appear, click the refresh button next to the Search Resource Types text box.
6. On the right, edit the YAML code to add the mandatory input values and the password.
  Add an inputs section in the code so that users can provide the name of the users that they are adding. In the following example, some of these values are sample data. Your values might be different.
```
inputs:
  accountName:
    type: string
    title: Account name
    encrypted: true   
  displayName:
    type: string
    title: Display name   
  password:
    type: string
    title: Password
    encrypted: true 
  confirmPassword:
    type: string
    title: Password
    encrypted: true   
  ouContainer: 
    type: object
    title: AD OU container
    $data: 'vro/data/inventory/AD:OrganizationalUnit'
    properties:
        id:
            type: string
        type:
            type: string    
```
7. In the resources section, add ${input.input-name} code to prompt for the user selection.
```
resources:
  Custom_ADUser_1:
    type: Custom.ADUser
    properties:
        accountName: '${input.accountName}'
        displayName: '${input.displayName}'
        ouContainer: '${input.ouContainer}'
        password: '${input.password}'
        confirmPassword: '${input.confirmPassword}'       
        
```
Deploy the cloud template.
1. On the cloud template designer page, click Deploy.
2. Enter the Deployment Name AD User Scott.
3. Select the Cloud Template Version and click Next.
4. Complete the deployment inputs.
5. Click Deploy.
Monitor the provisioning request on the Deployments page to ensure that the user is added to Active Directory and that the deployment is successful.

What to do next

When your tested cloud template is working, you can then begin using the AD user custom resource with other cloud templates.