vIDM is policy-driven and adds a significant amount capability over the IDVA. vRA 7 customers will gain many of the OOTB capabilities of the stand-alone vIDM product and be able to configure and manage these features directly with the vRA UI. For anyone who has used vIDM as a stand-alone solution or as part of another product (e.g. Horizon Workspace), configuring vIDM will be just as straight forward. But even if you’ve never configured it before, it is intuitive and walks you through the logical steps of setting up auth sources and advanced policies…

For Active Directory integration, vIDM Directories are configured to sync with one or more domains. AD can be configured as the exclusive provider, a backup (e.g. when 2FA fails), or as part of a more complex authentication policy. Several AD-specific policies are available to fit most use cases. vRA itself does not query AD directly. Instead, only the vIDM Connector communicates with the configured AD providers and performs a database sync (AD -> Local vPostgresDB) based on the configured sync policy. In addition to AD, vRA 7.1 added support for LDAP auth stores.

More on vIDM: http://www.virtualjad.com/2015/11/vrealize-automation-7-part-5-identity-management.html

Checklist:

  • Configure local admin access to default tenant (vsphere.local)
  • Add Auth Directory (Active Directory) in vIDM
  • Sync target AD Users and Groups
  • Configure user and group access
  • Modify vIDM services for high availability

Video

Detailed Steps

Configuration Detail Screenshots
Log in to the vRA Console

Browse to the vRA URL (e.g. https://vrademo.mgmt.local)

To access vRA’s default tenant, click the link for vRealize Automation console

This link will direct you to the default tenant login, which can also be directly accessed by going to https://vrademo.mgmt.local/vcac/org/vsphere.local directly (good idea to bookmark your direct URL).

The vRA URL from this point forward is the VIP/CNAME FQDN of the appliances. This is the entry point for all vRA management and consumption.

At this point, that URL is still pointing to the primary VA.

 

vRealize Automation Console

To log into vRA, use the SSO administrator account and password configured during the wizard:

  • UN: Administrator
  • PW: <sso_admin_pw>

Click Sign in to log in…

 

vRealize Automation Console

Once logged in, the only Tenant that should be visible is the default Tenant – vsphere.local.

Logging in with the administrator account is required for all system-level configurations, including creating Tenants and granting the initial admin permissions to each.

Click on vsphere.local to edit it (or highlight and select Edit from the menu)…

 

Create a Local Admin User

Click on the Local users tab

Click the + to add a new local user

Enter the User Details for your new local admin:

  • First name – vra
  • Last name – admin
  • Email – admin@vsphere.local
  • User name – vraadmin
  • Password – <password>
  • Confirm PW – <password>

In this example i’m creating a local user name “vra admin” – this can be whatever you want it to be.

Also note Email does not have to be a valid address.

Click OK to accept…

 

Grant Local Admin Rights

Click on the Administrators tab

Add your new user to the Tenant Administrators and IaaS Administrators roles (being typing the name in the Search field and hit Enter).

Click Finish to add the user.

Once added, go ahead and Logout (top-right corner) of the console…

 

Log back in to vRA console using the newly create local admin account…

 

Add an AD Directory

Navigate to Administration tab → Directories

Click on + Add Directory and select Add Active Directory over LDAP/IWA

 

Add an AD Directory

Enter the required configuration details:

  • Directory Name – choose a name that represents your AD (e.g. domain name)
  • Select AD over LDAP (default)

Directory Sync and Auth

  • Sync Connector – ensure your primary VA is selected
  • Authentication – Yes (default)
  • Directory Search – sAMAccountName (default)
  • Server Location – select DNS Service location (if supported), otherwise uncheck this box and enter the FQDN of an AD host
  • Certificates – leave blank unless STARTTLS is required

Bind User Details:

  • Base DN – enter the full DN path of the active directory base DN. If you’re unsure, use the root DN (e.g. DC=mgmt,DC=local)
  • Bind DN – enter the full DN path of the account that will be used to query AD (I like to stick to the vRA service account).
  • Bind DN Password – <pw>

 

NOTE: You can quickly find the DN path of any AD object in the Attribute Editor tab in Active Directory Users and Computers:

Click Test Connection to validate the settings

Click Save & Next to continue…

 

Select the Domains

If not already selected, select the target domain from the list (default for single domain)

Click Next to continue…

 

Map User Attributes

You can modify user attribute mappings as needed. This can also be done at at a later time.

Click Next to continue…

 

Select Groups to Sync

You can specify a specific DN path (e.g. a specific OU) as the starting point for group search. This is a good thing in large environments that don’t necessarily want the entire AD synced with vIDM.

Enter the DN path you want vIDM to query for AD group sync. If you’re unsure (or don’t need the granularity), enter the root DN (e.g. DC=mgmt,DC=local)

Once entered, vIDM will return the total number of AD Groups found at the target path.

Click Select

(you can also opt to Select All instead)

 

Select Groups to Sync

Browse the list of AD groups and select only the groups you want to sync with vIDM.

 

NOTE: Only groups that are synced can be added directly to vRA for any role or function. It may be easier to simply sync with the root DN and add all groups, but some limitations may apply.

This is fine for most environments, but some might need/want the granularity of pinpointing groups (and users for that matter).

Click Save to accept the selections

Review the groups, then click Next to continue…

 

Select Users to Sync

Similar to Groups, you must enter the DN path to the target AD users you want to sync with vIDM.

Enter one or more DN paths to the target user accounts

Click the + to add another DN path if needed

 

NOTE: Be sure to the path includes all AD users that will need access to vRA services (admin, consumer, anything). If the user account is not synced, you will not be able to add it any roles or functions in vRA.

If you’re unsure, you can simply add the root DN to include all AD users.

Click Next to continue…

 

Review

Review the sync details and make any necessary modifications if needed.

You will be notified if target users belong to groups that are not selected for sync. This is okay, assuming you’ve made sure to cover your bases.

Once reviewed, click Sync Directory to initiate the sync of the target AD Users and Groups to vIDM.

 

Sync Status

You can monitor the sync status. The initial sync can take seconds to hours, depending on the number of target users and groups.

Click Refresh to update the status until you get the green check and Last Sync column is updated.

In this environment, syncing 12 groups and 134 users took about 10 seconds.

 

NOTE: vRA leverages vIDM for all things authentication and access control. Rather than hitting AD each time, vIDM stores the account object in the local database and syncs with the directory on a scheduled basis.

Only the object and it’s relationships are stored…vIDM does not store or manage the account password.

The sync schedule can be configured as needed (default once every 24 hrs). If you need to immediately add a new AD user account, come back to this screen and select Sync Now.

 

vIDM High-Availability

Next we’ll add the vIDM connector from the secondary vRA VA and pass authentication to our load balancer VIP vs. the primary VA.

Navigate to the Connectors section

Review the available connectors. Notice the primary VA is already configured and belongs to the default Identity Provider (IdP)…

 

Add Secondary Connector

Navigate to the Identity Providers section

Notice the default Identity Provider, WorkspaceIDP_1, lists only the primary connector (Connectors column)

Click on WorkspaceIDP_1 to edit…


 
Enable IdP HA

In the IdP Hostname section, replace the existing hostname (defualt should be the FQDN of the primary VA) with the load balancer VIP / CNAME FQDN (e.g. vrademo.mgmt.local)…

 

Add Secondary Connector

Navigate to the Connector(s) section immediately above IdP Hostname

Use the Add a Connector drop-down to select the secondary VA

Once selected, enter the Bind DN Password (this is the PW to the account used during the initial directory bind).

Click Add Connector to add the secondary node…

 

 

Add Secondary Connector

Confirm the new connector is added to the list of Connector(s).

Confirm the IdP Hostname is pointing to the VA’s VIP FQDN

Click Save to save the changes.

Back in the Identity Providers section, both Connectors should now be listed for the default Identity Provider, WorkspaceIDP_1

 

Next, you’ll want to assign AD users and/or groups to vRA tenants for administration.

Open a new tab and browse to the vRA login screen (default tenant in this example).

Notice there is now a domain drop-down available, which allows you to select the new directory. However, no accounts from the new directory have been given access yet, so we need to log in to the vsphere.local domain first.

Log in to vsphere.local using the local SSO admin account:

  • UN: administrator
  • PW: <pw>

Click Sign in to log in…

 

Add AD Accounts to defaul Tenant

In the Tenants section, click on vsphere.local to edit…

 

Add AD Accounts to default Tenant

Go to the Administrators tab

You can now add users and groups from the configured AD directory. In this example, i’m adding my domain account, jelzein@mgmt.local, to the Tenant Administrators and IaaS Administrators roles.

You can also add AD groups to either role (e.g. CloudOps@mgmt.local).

Once you’ve added all the desired AD users and groups to either role, select Finish to save.

Click Logout to log out of the admin session.

 

You can test AD integration by logging back into the vsphere.local Tenant using an AD user account that was granted Tenant Administrator access in the previous step.

From the login screen, click Change to a Different Domain

Select your AD domain from the drop-down menu, then click Next to log in.

Sign in with the desired AD account…

 

And there you have it…

Review

While we’re sticking to the default tenant (vsphere.local) throughout this guide, you are free to add additional Tenants as needed. Any number of tenants can share a common directory…or be configured with one (or more) unique directories.

And now that we’ve got an initial set of users, we can move on to building out the remaining IaaS Fabric.

Next Step: 08 – IaaS Fabric

 

+++++
@virtualjad

1 Comment
  1. Jahid khan

    Excellent

Leave a Reply