vRA 7.2 DIG – 07, Initial Tenant Configuration
Browse to the vRA URL (e.g. https://vrademo.mgmt.local)
To access vRA’s default tenant, click the link forvRealize 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.
To log into vRA, use the SSO administrator account and password configured during the wizard:
- UN: Administrator
ClickSign into log in…
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)…
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 – [email protected]
- User name – vraadmin
- Password –
- Confirm PW –
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…
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…
Navigate to Administration tab Directories
Click on + Add Directory and select Add Active Directory over LDAP/IWA
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 –
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…
If not already selected, select the target domain from the list (default for single domain)
Click Next to continue…
You can modify user attribute mappings as needed. This can also be done at at a later time.
Click Next to continue…
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.
(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…
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 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.
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.
Navigate to the Connectors section
Review the available connectors. Notice the primary VA is already configured and belongs to the default Identity Provider (IdP)…
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…
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)…
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…
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
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
Click Sign in to log in…
In the Tenants section, click on vsphere.local to edit…
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, [email protected], to the Tenant Administrators and IaaS Administrators roles.
You can also add AD groups to either role (e.g. [email protected]).
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…