In this recipe, we will look at how Orchestrator uses the Active Directory (AD) plugin.
We split this recipe into multiple parts.
You can add AD to Orchestrator without using SSL; however, you will not be able to create users, change passwords, or use any other more secure options. If you decide not to use SSL, skip this step.
First, we will install Active Directory Certificate Services.
To activate SSL for AD, follow these steps:
central.mylab.local
, with domain administrator rights.
gpupdate
/force
command.C:WindowsSystem32ldp.exe
). Start ldp and connect to the domain controller using SSL (port 636
). If this test is successful, continue. If not, check out
http://technet.microsoft.com/en-us/library/cc875810.aspx
.TCP 389
(with SSL TCP 636
) to pass.Now, we add AD to Orchestrator:
389
without SSL and 636
with SSL.DC=mylab,DC=local
.@[FQDN Domain name]
format, for example, @mylab.local
.There is an additional workflow that lets you define some additional settings for AD. The workflow is Library | Microsoft | Active Directory | Configuration | Configure Active Directory Plug-in options. Here, you can define a default AD server (if you are using multiple) as well as a maximum number of returned items:
The AD plugin comes with a lot of great workflows that work without a problem. The following table shows you which workflows exist:
Workflow |
Use |
Computer |
Create, destroy, disable, and enable a computer. |
Organizational unit |
Create and destroy. |
User |
Create, destroy, disable, enable, change password, add, and remove from groups. |
User groups |
Create and destroy groups and add and remove users, computers, and groups to/from groups. |
As long as you have added the domain controller to your Orchestrator, you can run and integrate all these scripts into your own workflows.
The Microsoft plugin is quite easy to use; however, as you may have noticed, setting it up isn't as straightforward. The main issue is using SSL with the domain controller; as soon as this is working, you're home free.
The drawback of an SSO-configured Orchestrator should now be apparent, making it necessary to use a shared session. Some clients have argued that it would make more sense to use an LDAP integration rather than an SSO one, so they can use a Session per User. My argument is that SSO integration is the way forward with VMware and that the same customers are happy to use vCloud Director or VMware View with a dedicated user.
Microsoft integration allows a range of possibilities, user management being the prime target. There are more possibilities that the plugin offers; explore the AD API object.
When you are using a large AD directory you might like to consider using a different base for your AD connection. You could, for instance, use an OU such as the following:
OU=acme,DC=mylab,DC=local
Refer to the Managing AD users with vRA recipe in Chapter 13, Working with vRealize Automation.