Working with Active Directory

In this recipe, we will look at how Orchestrator uses the Active Directory (AD) plugin.

Getting ready

We need an AD server for this recipe as well as access to the AD server OS itself.

How to do it...

We split this recipe into multiple parts.

Preparing AD for SSL

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.

Note

Microsoft does not recommend that you run a CA server on a domain controller; however, for a lab, it is totally okay.

To activate SSL for AD, follow these steps:

  1. Log in to the Windows server that will host the CA. In my case, this is my domain controller, central.mylab.local, with domain administrator rights.
  2. Add the Active Directory Certificate Services server role.
  3. Just click on Next and accept all the default settings. In the following screenshot, you'll find all the settings I used (the default ones for my domain):

    Preparing AD for SSL

  4. After the wizard has finished, open up Group Policy Manager and edit Default Domain Controller Policy.
  5. Navigate to Computer Configuration | Policies | Windows Settings | Security Settings | Public Key Policies | Automatic Certificate Request Settings and then go to New | Automatic Certificate Request Setup.
  6. Finish this wizard again by just clicking on Next, which forces the creation of a certificate for your domain controllers.
  7. Wait a few minutes or force a policy update on the domain controller using the gpupdate/force command.
  8. Start the Certification Authority tool and check in Issued Certificates whether the domain controller was issued with a certificate.
  9. To test the SSL configuration connection, we will use Microsoft's ldp tool (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 .
  10. Last but not least, make sure that the Windows firewall allows TCP 389 (with SSL TCP 636) to pass.

Registering AD with Orchestrator

Now, we add AD to Orchestrator:

  1. Start the workflow by navigating to Library | Microsoft | Active Directory | Configuration | Add an Active Directory server.
  2. Give the connection a name.
  3. Enter the FQDN of your AD server.
  4. Enter the port you are using: 389 without SSL and 636 with SSL.
  5. The root is written in the LDAP format, for example, DC=mylab,DC=local.
  6. Choose whether to use SSL or not. If you are using SSL, you can choose to be asked when importing the certificate.
  7. The default domain is written in the @[FQDN Domain name] format, for example, @mylab.local.
  8. If you have configured Orchestrator with SSO, you have to choose a Shared Session. Enter domain-administrator credentials.
  9. In Options you can choose to follow referrals, meaning that if the AD doesn't have a given object in its own tree it might know the right domain controller. You can also specify a timeout to reduce the amount of time you spend waiting for an object in a large AD structure.

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:

Registering AD with Orchestrator

Working with AD

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.

How it works...

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

See also

Refer to the Managing AD users with vRA recipe in Chapter 13, Working with vRealize Automation.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset