Windows servers require Microsoft AD, it is an integral part of the server architecture. I am not going to get into much detail on the directory service since this blog is focused on how SovLabs interacts with it.
The module has many features which can viewed on the website here, but some of the highlights are:
- Handles simple to complex globally distributed multi-domain, multi-site MS AD environments
- Registers/cleans computer account with Active Directory
- Supports placement in a “build OU” during provisioning in order to facilitate software deployments/configurations that require a less restrictive Group Policy
- Supports dynamic creation and removal of OUs
- Employs several methods to improve reliability of registration/cleanup to mitigate failures, such as retry logic and post validation checks
Prerequisites:
- Identify the Domain Controllers to be used, or if policy dictates no direct connections are allowed then identify a proxy server.
- If using a proxy server then make sure the environment setup is complete by following these steps
- Windows 2012 R2 required
- Setup WinRM
- WinRM must be enabled for SovLabs modules utilizing any Windows servers in the environment (for AD, DNS, IPAM, Puppet and etc.)
- Follow these steps
- Install AD Webservices on all the DC’s that will be used.
- Verify NTP settings
- “Shell access type” for the user account with permissions must be set to Command Prompt.
Active Directory Example:
I am going to initially deploy the computer object in the following OU which is used for pen testing: (BUILD OU)
- OU=vra_BuildDeployment,OU=Servers,OU=Lab,DC=sovsys,DC=com
Then after pen testing is completed, I will move the computer object to the following OU:
- OU=vra_Deployment,OU=Servers,OU=Lab,DC=sovsys,DC=com
Since I have production and development(lab) environment I would like create the computer object in different OUs. This I can handle through a custom property and SovLabs Template engine.
SovLabs.AD.Environment.OU – defined on Business group
This will update my OU to following:
- OU=vra_BuildDeployment,OU=Servers,OU={{SovLabs.AD.Environment.OU}},DC=sovsys,DC=com
- OU=vra_Deployment,OU=Servers,OU={{SovLabs.AD.Environment.OU}},DC=sovsys,DC=com
Configuration:
- Add Microsoft Endpoint
- Login to vRA Tenant
- Select Catalog -> SovLabs vRA Extensibility
- Click Request button on “Add Microsoft Endpoint”
- Enter Configuration label
- Only AlphaNumeric characters, no spaces or special characters except:
-
and_
- Only AlphaNumeric characters, no spaces or special characters except:
- Select connection method
- Select how the SovLabs modules will connect to the target or proxy Microsoft server
- Enter hostname
- FQDN of AD server
- Use non-standard ports = no
- Is a proxy host = no
- for my instance I am connecting directly to the AD server.
- Enter username and password
- Advanced configuration is only necessary when local administrator access cannot be given to the service account.
- temporary directory = blank
- share path = blank
- Click Submit
- Add Active Directory Configuration
- Select Catalog -> SovLabs vRA Extensibility
- Click Request on Add ActiveDirectory Configuration
- Enter configuration label
- Only AlphaNumeric characters, no spaces or special characters except:
-
and_
- Only AlphaNumeric characters, no spaces or special characters except:
- Select Microsoft Endpoint
- created earlier
- Select Computer name case
- Choose whether or not the computer name added in AD is all uppercase or lowercase
- If you are using the Puppet module set this to lowercase since it will cause problems with authentication due the certificates created for the Puppet agent is always in lowercase.
- Use Build OU
- Select yes if computer needs to be placed in an interim OU.
- If yes, fill in create and remove OU, otherwise leave those blank.
- OU=vra_BuildDeployment,OU=Servers,OU={{SovLabs.AD.Environment.OU}},DC=sovsys,DC=com
- OU
- ActiveDirectory Organizational Unit (OU) in DN format for computer/VM to join
- OU=vra_Deployment,OU=Servers,OU={{SovLabs.AD.Environment.OU}},DC=sovsys,DC=com
- Security Group
- List all AD security groups the server should join
- Delete computer account
- If you select yes it will try to find computer account and delete it, regardless of which OU it is in.
- Click Submit
Enable the module:
Now we need to enable the custom properties module on our blueprint:
- Click on Design -> Blueprint
- Edit Blueprint
- Click on the blueprint vSphere machine on the Design Canvas.
- Click on properties tab
- In the properties group section click +Add
- Check the box for:
- SovLabs-EnableLifecycleStubs
- Microsoft Active Directory property group (starts with SovLabs-AD-)
- Do not attach more than 1 Microsoft Active Directory property group to a blueprint vSphere machine object.
- Click OK
- Repeat these steps for all blueprints that should use this custom naming.
Now deploy a VM and watch the magic happen. Effortless, predictable, consistent and best of all no manual input of placing the created computer object in a specific OU.