Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
Overview
A common extension requested for vCloud Automation Center is the ability to pre-create computer account objects in Active Directory in a specific Organizational Unit, and also to decommission the accounts in different ways along with the virtual machine. Without a custom workflow, you can have the computer join the domain during the customization phase, but this will only create the computer account in the default Computers container. Also, while there is an out-of-the box AD machine cleanup plugin which can be enabled, it will likely never support the multi-tenancy introduced in vCAC 6.0. vCO does not support it today either, but it is more likely to gain support in the near future.
This solution implements these functions using vCenter Orchestrator and its plugins for vCAC and Active Directory.
The rest of this article contains instructions on installing and configuring the vCAC AD Computer Account Management Extension. This extension allows administrators to model very specific OU structures for their AD machine accounts using vCAC custom properties, and supports dynamic OU Distinguished Name building based on combinations of properties derived from different areas of vCAC (compute resources, reservations, groups, blueprints, etc.).
This extension is proof-of-concept or demo grade. While it runs well and consistently, it has not been put through a formal quality assurance process, so please use with caution. Please see the disclaimer and other information in the readme.txt file in the package.
Changelog
v1.0
- Initial release
Download
vCAC AD Computer Account Management Extension 1.0
Installation
These installation instructions assume the following:
- You have a working vCenter Orchestrator in your environment.
- You have a working knowledge of administering vCO.
- The vCloud Automation Center 5.2 or 6.0 plugin for vCO has been installed, and a vCAC host has been added.
- The Active Directory plugin for vCO has been installed, and a domain controller host where you’d like to create machine accounts has been added.
- You have the vCenter Orchestrator instance configured as an endpoint in vCAC.
- vCAC 5.2 or 6.0 is preconfigured with at least one working Blueprint.
Follow the steps below to perform the installation:
- Download com.dailyhypervisor.vcac.ad.computeraccountmgmt.package from the link above and copy it onto the local filesystem of the system where you will run the vCenter Orchestrator client.
- Import com.dailyhypervisor.vcac.ad.computeraccountmgmt.package into your vCO instance.
- Run the workflow Daily Hypervisor > vCAC > AD Computer Management > Install pre-create AD computer extension.
- Choose the vCAC host where you’d like to install the extension and click Submit.
- Follow the instructions described by the workflow to download and install the external workflow XML file into vCAC.
- Repeat steps 3 through 5 for the workflow Daily Hypervisor > vCAC > AD Computer Management > Install AD computer cleanup extension.
Configuration
To configure vCAC to use the AD computer account management extension, perform the following steps:
- Go to Infrastructure > Blueprints > Build Profiles.
- Click on New Build Profile.
- On the New Build Profile page, click the drop down for “Add from property set”, and choose PreCreateADComputerPropertySet. Click Load.
- Repeat step 3 for the AdMachineCleanupPropertySet.
- You will now have all of the AD computer management extension properties in your Build Profile. Below is an explanation of each property.
Custom.PreCreateAdComputer.Execute
The existence of this property triggers the workflow which handles creation of AD computer accounts to run.
Note: The value is set to “true” by default, but this is just aesthetic. Setting it to “false” will not stop the workflow from running. This property only needs to exist to trigger the workflow, regardless of its value.Custom.PreCreateAdComputer.OU
This property’s value represents the distinguished name of the container where you would like to create the AD computer account. The format of this string should be similar to the example value provided in the property set, which is the default location for computer accounts in an Active Directory domain corp.local: CN=Computers,DC=corp,DC=local. You can also add references to other custom properties by specifying the property name enclosed in curly brackets. This will cause that custom property’s value to be inserted into that slot. Anything not in curly brackets is placed in the DN as-is. This is useful if you would like to generate dynamic distinguished names based on other attributes of the machine, such as what group the requester is a member of, or which computer resource the machine lands on.Custom.AdMachineCleanup.Execute
The existence of this property triggers the workflow which handles decommissioning of AD computer accounts to run.
Note: The value is set to “true” by default, but this is just aesthetic. Setting it to “false” will not stop the workflow from running. This property only needs to exist to trigger the workflow, regardless of its value.Custom.AdMachineCleanup.Delete
This property tells the AD machine cleanup workflow to delete the machine’s AD computer account when it is decommissioned.Custom.AdMachineCleanup.Disable
Adding this property tells the AD machine cleanup workflow to disable the machine’s AD computer account when it is decommissioned. This property can be used in conjunction with the one below, if desired, by specifying both properties.Custom.AdMachineCleanup.RenamePrefix
This property tells the AD machine cleanup workflow to rename the machine’s AD computer account when it is decommissioned. It will use the value as a prefix for the new name, and append to original name to that. So, if the value of this property is “destroyed_”, a machine named vm01 will be renamed to destroyed_vm01. This property can be used in conjunction with disabling the account, if desired, by specifying both properties. - Let’s configure an example AD computer account management configuration to get a working understanding of the functionality. The next step is to refine the property set in our build profile. Since we are going to be interested in renaming and disabling the machine account when decommissioned, delete the Custom.AdMachineCleanup.Delete property altogether.
- Edit the Custom.PreCreateAdComputer.OU property value to model the following use case:
- The OU distinguished name has two parts: the domain DN, and then a group DN, in that order in the AD tree structure.
- Use DomainDN for the domain part and GroupDN for the group part.
- Disable the computer account upon decommissioning.
- Also add the prefix “destroyed_” to the machine’s name upon decommissioning.
Your Custom.PreCreateAdComputer.OU property value should look like this: {GroupDN},{DomainDN}. Name your Build Profile. You will end up with a new Build Profile as shown below.
- Now we need to configure the custom properties for each property variable in the OU’s DN. For no particular reason, let’s specify the domain DN in the Compute Resource.
I set DomainDN to DC=corp,DC=local to represent the corp.local domain.
- Group will be specified at the business group level, so in my Production Admins business group, I created a property named GroupDN with the value “DC=Production Computers”.
So, if I request a machine on the Compute Resource with our DomainDN property, as a member of the Production Admins group, my resulting OU distinguished name should be…
OU=Production Computers,DC=corp,DC=local
Testing a machine build reveals that the pre-create AD computer account workflow does its job.
Destroying the machine reveals that the AD machine cleanup workflow also performs its duty.
Nice Work Tom.
I already have a customer who asked me about this yesterday,
Thanks for sharing.
Thanks Chris. Hope you get good use out of it!
When building a machine in the log I’m getting the following error message, any idea why I might be receiving this?
Workflow “PreCreateADComputer” failed with the following exception: Error executing vCenter Orchestrator workflow: TypeError: Cannot read property “organizationalUnits” from null (Workflow:Pre-create AD computer account in OU / Get OU & domain name (item3)#31)
When I go to vCO I’m seeing the following in the Logs of the Pre-create AD computer account in OU
“[2014-04-02 10:24:44.737] [I] Search Result Array Size: 1
[2014-04-02 10:24:44.737] [I] Running Distinguished Name: OU=Machines,dc=corp,dc=amdocs,dc=com
[2014-04-02 10:24:44.738] [I] TypeError: Cannot read property “organizationalUnits” from null (Workflow:Pre-create AD computer account in OU / Get OU & domain name (item3)#31)”
It seems for some reason I have to put all my variables for the OU path in the Business group. When I go to Catalog > Request > Properties, not all the properties are there. When this happens it fails with the above messages. I’m still trying to test a few other things out, but doesn’t seem to be normal behavor.
So a few things, it looks like each property must contain just 1 OU in it… IE: OU=Servers and can’t have OU=Servers,OU=Somethingelse Also tried using setting properties in Endpoint and it does not work there for the computer account creation for the setting properties.
Hi there Andrew
Nested OU’s are possible as long as they are defined as the GroupDN portion of the Custom.PreCreateAdComputer.OU property
I have used the extension provided by Tom to create a GroupDN that is driven by a dropdownlist and then created the DomainDN within the blueprint manually
This the dropdownlist in the blueprint defined via a propety dictionaty populates the GroupDN as OU=Servers,OU=Applications,OU=TestApp,OU=Dev and then DomainDN is manually specified within the blueprint as DC=corp,DC=co,DC=za
In our environment this is working as expected.
Just want to note here that you aren’t limited to GroupDN and DomainDN. These are simply what I used in my example. You can use anything, as long as it matches a custom property name. So it will always replace an expression {AnyPropertyName} with the value of that property.
Nested OUs worked fine during my testing. My guess is that there is something else happening there. Let me know if you still need help. We can do a screen share and figure it out.
We are seeing the same issue. We have tried it several ways, on all of them the logs show
“Running Distinguished Name: OU=firstou,DC=na,DC=ds,DC=acme,DC=local”
then permission failed.
it appears as if the DN is being truncated to the first OU where the account has no rights..
it only has rights on the destination OU. If we use the VCO microsoft create computer account in OU it works fine
When we look at the dn string in vCO it shows what it should be
ou=finalou, OU=thirdou,OU,=secondou,OU=firstou,DC=na,DC=ds,DC=acme,DC=local
It looks like the script looks for the last DC then only takes the next OU
this is on VCAC 6.01.1 built in vco
I modifed the Get OU & Domain Scriptable task to move the AD lookup related items after the loop that parses the DN. All is working now.
for (var i = dnParts.length – 1; i >= 0; i–) {
runningDnParts.push(dnParts[i]);
var dnPartParts = dnParts[i].split(“=”);
var childType = dnPartParts[0];
var childName = dnPartParts[1];
if (childType.toUpperCase() == “DC”) {
domainNameParts.push(childName);
}
else if (childType.toUpperCase() == “CN” || childType.toUpperCase() == “OU”) {
if (lastWasDC) {
domainNameParts.reverse();
domainName = domainNameParts.join(“.”);
// Removed code here that started searching the first OU after the DC
lastWasDC = false;
// Removed ifelse Code Here that doesn’t need to be performed
}
}
}
//Moved Code here that was needed after enumerating the entire DN
runningDnParts.reverse();
var runningDn = runningDnParts.join(“,”);
var objectType = childType.toUpperCase() == “OU” ? “OrganizationalUnit” : “Group”;
parent = searchADForExactDnMatch(childName, objectType, runningDn);
To try to test a failure with the existing code.. Try an OU structure that is 4 OU’s deep with a OU in the middle made up of only numbers…
Hi there Tom
Thank you for sharing this. Used it on our environment with very good success
Excellent! Great to hear it.
Goo Stuff Tom, Have this deployed in a customer POC.
Nice!
You may have 2 now John
Hi there Tom
I have come across a potential bug in the workflow that I hope you can assist with. When an Active Directory OU contains certain characters in is mandatory that those characters are escaped with a backslash “” as per https://social.technet.microsoft.com/wiki/contents/articles/5312.active-directory-characters-to-escape.aspx
So in the case when we use the workflow to create a computer in an OU structure like
OU=DEV,OU=VMWare,OU=Virtualization,OU=#Servers,OU=Servers,DC=Corp,DC=local
Then the GroupDN must be specified as:
OU=DEV,OU=VMWare,OU=Virtualization,OU=#Servers,OU=Servers
And the DomainDN is specified as:
DC=Corp,DC=local
Now when the workflow executes the computer account is created in
OU=Servers,DC=Corp,DC=local instead of the full DN
When I examine the workflow run that created the computer account I notice the following:
dnString variable is correct
OU=DEV,OU=VMWare,OU=Virtualization,OU=#Servers,OU=Servers,DC=Corp,DC=local
But the logs show that it is processing the following
Running Distinguished Name: OU=Servers,DC=Corp,DC=local
This only seems to happen when an OU name contains one of the special characters that has to be escaped.
This is a good solution Tom – thanks for sharing
I have custom Properties for user input/Dropdown for Project and Tier to allow the builder to precreate the computer into specific OU’s.
my Custom.PreCreateAdComputer.OU is set to OU={Custom.Project},OU={Custom.Tier},{GroupDN1},{DomainDN1}
If the OU “XYZ” exists it works… if not.. the computer ends up in OU=ServerS
Would it be possible to modify your workflow to check if OU exists and if not it creates it?
Example..
Custom.Project XYZ (Drop down)
Custom.Tier Dev (Drop down)
DomainDN1 DC=MyDomain,DC=com
GroupDN1 OU=ServerS
precreate XYZ and create computer object in XYZ.Dev.ServerS.MyDomain.com
It is certainly possible. I will let Tom reply as to when he could add that feature to the workflow. It would make sense to have in my opinion.
Sweet and thanks!! Excellent package!
I have installed the plugin on VCO, but I don’t see any post related to VCO workflow once its integrated. Can somebody share the example?
Getting below error now..
Illegal GUID format (Dynamic Script Module name : getVirtualMachineEntityFromId#3)
will it work for Multi-AD forest scenario where you have different domain controllers??
So where would the XML files be installed to if you are using the VCAC appliance?
vRealize Automation a.k.a vCAC has multiple components. There is the virtual appliance and then there is the IaaS server which is the installable components that get installed on Windows. The xml goes on the WIndows server, not the appliance.
Sid/Tom/Mark,
Can you please help me to on this worfklow?
Will it work with multiple domains ?
I don’t see any xml files as mentioned in 5th step “Follow the instructions described by the workflow to download and install the external workflow XML file into vCAC”
Looks like you are passing only the Virtual machine ID to create/delete computer account. How did you pass the Virtual Machine ID variable to the workflow? I don’t see any instructions on it.
I tried to execute manually in VCO by providing the Virtual Machine ID from DB table but I am getting the below error. I am giving the complete OU DN in the custom properties.
TypeError: Cannot read property “organizationalUnits” from null (Workflow:Pre-create AD computer account in OU / Get OU & domain name (item3)#31)
While running the installer workflow, there is a User Interaction that pops up where you download the file and follow the on-screen directions on how to install it. If you didn’t read and just clicked “Submit,” you might have missed it.
Tom,
Thanks for quick reply. I rechecked it again, looks like I have already copied the xaml files.
Can you please answer my other questions? I am trying to use this workflow with another one, need help to get the Virtual machine ID (input variable). Will it work for multi-AD forest with assumption that service account has access to other domains?
getting the below error.
TypeError: Cannot read property “organizationalUnits” from null (Workflow:Pre-create AD computer account in OU / Get OU & domain name (item3)#31)
I modified the Get OU & Domain Scriptable task (as per Mark reply). Now, I am getting the below error. All the variables Domain DN & Group DN,etc are added to Provisioning group
17:09:49.573] [I] TypeError: Cannot call method “createComputer” of null
AD object is returning only the AD domain which is configured for VCO. But, I am trying create a computer account in different forest/domain B. Looks like the below function is trying to get only one domain. Does it work for multi AD forests?
var adObjects = ActiveDirectory.searchExactMatch(objectType, objectName, 999999);
Nice workflow, just the one I needed 🙂
But is there a way to abort VM-provisioning if the workflow would fail like it normally does if I connect a stub to a blueprint?
Adding Disposing to External-CleanupADComputer.xml did the trick..
I really like this workflow, but having an issue with it and cant figure out where to look on what it is dying on.
java.lang.NullPointerException (Workflow:Pre-create AD computer account in OU / Get OU & domain name (item3)#41)
Any help with this would be greatly appreciated.
Even i get the same error. Let me know if you find any solution!
I am getting the same NullPointerException as well. I checked the vRO server.log and see this …
2015-04-06 14:59:03.516-0700 [WorkflowExecutorPool-Thread-13029] ERROR {xxxxxx@ad.yyy.zzz:Pre-create AD computer account in OU:aaaaaaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbbbbbbbb:[906f1d14-1bf4-4554-879c-c427
ff5255c0]} [MSPluginFactory] Unable to create initial LDAP Context
javax.naming.AuthenticationException: [LDAP: error code 49 – 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1^@]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3087)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2835)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
BTW, “data 523” means invalid credentials
What’s strange is that if I copy the script “Get OU & domain name” in the workflow and paste it into a new workflow “as is” and create a service blueprint to call the new workflow, it runs fine, so not sure what “invalid credentials” it is complaining about in the original workflow as none are ever passed in as far as I can tell.
It seems there are some changes to some of the OOB workflow sin vCO. We will be testing and updating the extensions we have posted, stay tuned for more info.
Hello Tom/Everyone,
Is this only in business group level? What do i exactly do to get things working in blueprint level?
Do i still add the DomainDN in compute resources?
And what do i add in business group level?
I have my Blueprint OU like ” OU=Servers,OU=Windows,OU=Non-Prod,OU= Application,DC=corp,DC=local
Please help!
You do not need to complete the default vRA fields in the business groups. What you need to do is create the OU structure you want like so:
{BLUEPRINTDN){GROUPDN}{DOMAINDN}
Let’s say you will always use the same {DOMAINDN} You might place that as a property at the endpoint. Like so:
Proeprty: DOMAINDN Value: DC=corp,DC=local
Then maybe you will have a different ou for each groups so you would add something like so on each group with a different value for each:
Property: GROUPDN Value: OU=GROUP,OU=WHATEVERYOUWANT
The if you want to add to it for Blueprint you would add to the blueprint:
Property: BLUEPRINTDN Value:OU=Servers,OU=Windows
In this example when the machine is built they would get added ttogether to build the complete OU (OU=Servers,OU=WIndows,OU=Group,OU=WhateverYouWant,DC=Corp,DC=local)
The important part is that the property name match what you declared in the {}. If you need more info in please see:
http://dailyhypervisor.com/vcloud-automation-center-vcac-5-1-custom-properties-demystified/
http://dailyhypervisor.com/vcloud-automation-center-vcac-5-1-using-custom-properties/
http://dailyhypervisor.com/vcloud-automation-center-vcac-5-1-custom-property-overrides/
They may help.
Thank you so much for the response Sid,
Do you have any idea why we would get this error?
“java.lang.NullPointerException (Workflow:Pre-create AD computer account in OU / Get OU & domain name (item3)#41)..”
This is the error that i come across : vCenter Orchestrator workflow Pre-create AD computer account in OU failed with error: Error executing vCenter Orchestrator workflow: java.lang.NullPointerException (Workflow:Pre-create AD computer account in OU / Get OU & domain name (item3)#41)..
Can somebody confirm if this works for multiple AD forests/domains?
The “Pre-create AD computer account in OU” workflow in this extension relies on the configuration associated with the Microsoft AD plug-in in vCO (i.e., see the “System.getModule(“com.vmware.library.microsoft.activeDirectory”).createComputer()” call in the “createComputer” action). Since the current (v1.0.5) Microsoft AD plug-in only supports a single AD server, I would assume that this extension has the same limitation. Perhaps the author can confirm or explain otherwise. Also, I’ve heard that VMware is updating their AD plug-in to support multiple AD domains, but I have no idea when it might be made available.
As a side note, it seems that the current Microsoft AD plug-in supports the same computer account create/delete/disable/rename capabilities that this extension offers. So, I guess the added benefit of this extension is it’s ability to install calls to the extension workflows into the vCAC state change workflows. Perhaps when this extension was published, its installation capabilities offered valuable convenience. However, my impression is that use of the Infrastructure Administration Extensibility workflows of the vCAC plug-in in vCO are considered the current best practice for installing calls to vCO workflows into vCAC state change workflows. I’m still somewhat new to vCAC/vCO (or vRA/vRO if you prefer), so comments to confirm or refute my understanding are welcome.
I use this particular Extension as well as the Custom Hostname Extension religiously in my vCAC/Dev environments. They work well and are very much appreciated!! However I appear to be in the same position as others above and now have a requirement to use this Extension in more than 1 AD environment. Is it possible to confirm whether this Extension, Workflows within, and/or the related Custom Properties can indeed be modified to target multiple AD Domains? If not, would anyone have any suggestions as to how best to approach this issue to satisfy multiple Domain use?
Thx Ron
VMware recently updated their AD plugin to version 2. It now supports multiple AD servers. It is available to customers when they log into myvmware,com. You might want to have a look and see if it meets your needs. We plan on transitioning to it in the near future,
Thanks for the update, Marty. I’ve just installed it and will now assess its functionality. Much appreciated!
If you have multiple domain controllers and want to use ldaps, only the certificate from one domain controller is added when the Configure Active Directory workflow is run.
Then when you run a AD-workflow it will fail if one of the other domain controllers used.
vCenter Orchestrator workflow Pre-create AD computer account in OU failed with error: Error executing vCenter Orchestrator workflow: java.lang.NullPointerException (Workflow:Pre-create AD computer account in OU / Get OU & domain name (item3)
/var/log/vco/app-server/server.log
4-1bf4-4554-879c-c427ff5255c0]} [MSConnectionHelper] InitialLdapContext connection retry : ( 3 / 3 ) reason : CommunicationException:simple bind failed: xx.example.net:636
You need to import the other certificates manaully to the keystore.
You can list the certificates in the kesytore with
# keytool -list -keystore /etc/vco/app-server/security/jssecacerts -storepass dunesdunes
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 10 entries
ssl:_imported__5, Feb 10, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
ssl:_imported__4, Feb 10, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
ssl:_imported__3, Jan 15, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
ssl:_imported__2, Jan 14, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
ssl:_imported__1, Jan 14, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
dunes, Dec 9, 2014, PrivateKeyEntry,
Certificate fingerprint (SHA1): AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
vco.cafe.component-registry.ssl.certificate, Dec 11, 2014, trustedCertEntry,
Certificate fingerprint (SHA1): AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
ssl:_imported_, Jan 14, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
vco.sso-ssl.certificate, Dec 11, 2014, trustedCertEntry,
Certificate fingerprint (SHA1): AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA
To import a certificate, copy the pem file with the certificate to the vCO server and import it
# keytool -importcert -alias “ssl:_imported__6, Mar 19, 2015” -file /tmp/ad.pem -keystore security/jssecacerts -storepass dunesdunes
Hi,
I have installed and it runs fine – however my machines are not using the pre-created objects and are creating an object in the default OU. Any ideas?
Thanks
Gavin
please ignore my comment. was a permissions issue!
Found out if you run the AD plugin 2.0.3 or higher in Orchestrator you will need to run an additional workflow within the AD configuration called “Configure Active Directory plug-in options” to set the default AD server. Without this you will not be able to pre create computer accounts before the machines get provisioned in vRA. May want to update the documentation you have for future users or anyone that upgrades the AD plugin.
Including the error you may see in Orchestrator when the workflow runs – “Default Active Directory server not set”
Has anyone tried to port this over to vRA 7.0? I used this in our 6.0 deployment but now need to port to 7.0.1 deployment.
Keep on writing, great job!