For this part of our learning curve, which follows on from Part One, we're going to be looking at composing a simple Service that allows the creation (and management) of an Active Directory (Directory Services) User account.

Integrating vCO with MS Active Directory / Directory Services

This part involved a little time from my side because I kept crashing into brick walls at every turn, but I'm going to try make things easier for you and share what I've learned.

First, there are 3 important things to remember regarding the integration with Active Directory:

The user account you use for this must be a Domain Admin and Administrator on the AD server
If you are going to create users WITH passwords, you MUST use SSL to connect to AD
If you wish to create user WITHOUT password (blank passwords), you are going to have to change the default password policy on AD to allow blank passwords

For setting the password policy on the Active Directory Server:

On the DC, Open "Active Directory Users and Computers".
In the console tree, right-click the domain or organizational unit that you want to set Group Policy for.
Click Properties, and then click the Group Policy tab.
Click an entry in Group Policy Object Links to select an existing Group Policy object (GPO), and then click Edit. You can also click New to create a new GPO, and then click Edit.
In the console tree, click Password Policy.
Where?
- Group Policy Object [computer name] Policy/Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy
In the details pane, right-click the policy setting that you want, and then click Properties.
If you are defining this policy setting for the first time, select the Define this policy setting check box.
Select the options that you want (in this case, set the Minimum Length to 0), and then click OK.

So, on to the fun stuff - First off, you need to configure Active Directory in vCO. There are a few article on the web about this too, but put simply: You need to Add an AD Server by running one of the Config Workflows in the Configuration Folder, under Library->Microsoft->Active Directory->Configuration. It's pretty straightforward. I used a non-SSL config for my AD, and I also used a Shared Session and specified credentials.

Feel free to comment and let me know if you need details on how to achieve this.

Next, once configured, we'll create our own Workflow that includes the built-in workflow to create a user.

So, in the Dev Folder we created in Part One, let's go ahead and create a new workflow.
Editing this Workflow, we can drag in the following Workflow as a step from this location:

The built-in Workflow "Create a user in an organizational unit" allows us to create a user with a blank password

So go ahead and drag the above workflow as a step into your new Workflow. It should look like this now:

Our new Workflow in the Dev Folder, with a single step in it.

Next, you should create these Inputs on your workflow (in the General Tab) as follows:

Create inputs on your Workflow: UserName (string) and DisplayName (string)

For the output, I've set mine to a type of "AD:User" which is a built-in vCO type that is created upon installing the Active Directory plug-in. This is a pretty important step, because it follows on to allow us to interact with this type / resource in vCAC later.

So, once we've done this, we need to configure the only step in our new Workflow.
Ok, so pay attention here. This step is easily misconfigured.
The workflow we dragged onto our own workflow has its own inputs. One of these inputs is the OU in which we want to create the user.

Since we don't necessarily want to allow the Developers consuming this service to select which OU the new Test User belongs to, we want to ensure we set this up beforehand.

We go into AD and create a new OU. I've called my OU "Development Users". This is where all the Test Users that the Developers create will reside.

Create a new Organizational Unit called "Development Users"

Next, we set the input for the workflow Step to the above OU. Note the green arrow below, pointing to the step in the workflow which I am configuring. The Yellow Arrow points to the OU in the vCO Object Browser.

Select the Development Users OU we created earlier.

Next, we set the output of the Workflow Step to the Output of our Workflow. This means that the Workflow Step will output the new User, and we will use this output as the output for our whole Workflow. Confusing? I hope not...

Set the Output of the AD Step  to the Output of our Workflow — Set the Output of the AD Step to the Output of our Workflow

Similarly, we'll set the inputs for the step to the inputs for our Workflow, except the OU, which we've already defined. Overall, this means that our workflow will pass the inputs it received into this step, and the output produced by the step will also be the output for our workflow.

To clarify this, we'll go ahead and create our Advanced Service, using the Advanced Services Tab. Note the green arrow pointing to our new Workflow, and the orange arrows showing our inputs on the workflow. The blue arrow shows the Active Directory User as output.

Browse for our newly created Workflow in vCAC, connected to vCO

The next step is simple: give our Service a name and Description:

The Names and Description of our new Service

Use Friendly Inputs on your form:

In the next step, things start to become a little different from what we did in Part One.
Here, if you followed these steps, your drop-down list might look different. You probably won't see AD:User type in your list. This is because we first need to create the Resource. You can select "No Provisioning" here, and we'll come back and edit this later, once we've created what we need.

Create a Resource and Actions for the Resource

To create the Resource so that we can set it above, navigate to "Custom Resources" and let's create a new Resource first:

Creating a new Resource, the first step is to select the corresponding vCO Type. For this article, we'll use AD:User:

Select the vCO defined "AD:User" type as our Resource Type.

Te Details Form can be left as default for the purposes of this article.

The next Step is to create Actions associated with these Resources.

So, we've just told vCAC: Here's a resource called a User. When you call the previous workflow, vCAC is now aware of the type AD:User that has been provisioned. Now we're also telling vCAC what actions we're allowing our developers to perform on these resources. Such actions might involve enabling and disabling or even deleting these provisioned users.

If you're feeling a little overwhelmed at this point, don't worry. The end result on this article will clarify everything for you. Let's push on.

Navigate to Resource Actions. When you're done with the next step, you'll have something like this:

Resource Actions associated with Resources

Let's go ahead and create two Custom Actions for our new Resource. The first will Disable a user (as seen below in the image), and the next follows exactly the same steps, but we'll Enable a user in the second action):

For the "Input Resource" type, we'll select the "AD User" Resource we just created in the previous step:

Select the Resource we created as input.

Fill in details and describe the action, and you can leave the Form (last tab as above) blank for now.

When you've done step above, repeat it for Enabling a User. When you're done, your Custom Resource Actions window should look like mine, 3 screenshots up.

Back to our Service Blueprint

In the previous steps, go the Service Blueprint we were creating, and edit it.

On the "Provisioned Resource" tab, now select our newly created Custom Resource:

Our provisioned Resource is the object we just created

Is it starting to make sense? Awesome stuff, right?

Let's move on.

Once you've saved your new Service, publish it:

The next thing you need to do is provide Entitlements, defining who can access this Service. This follows exactly the same procedure as previously detailed in the Service we created in Part One, so I'm not going to repeat it here. Take a look here for reference.

Moving on: Once entitled, we should have something like this: