
VMware vRealize Orchestrator Cookbook
By :

To use Orchestrator to its fullest possibilities we should configure it with an external authentication.
We need an up and running Orchestrator and access to the Control Center (root account). Also see, the recipe Deploying the Orchestrator appliance in this chapter.
You should have an AD/LDAP group for your Orchestrator Administrators with at least one user in it. I will use the AD group vroAdmins
with its member vroAdmin
and my domain is called mylab.local
. My PSC/SSO is on vcenter.mylab.local
.
If you are using AD/LDAP, then you need only to know the LDAP path to your vroAdmin user and group.
If you are using SSO or vSphere(PSC), you should either have configured SSO to use AD or created a local SSO group and user.
We are splitting the recipe into multiple parts, one for each authentication method.
For both vSphere 6 and vRA7, the entry forms look alike and follow the same pattern. However, there are some really important considerations to take into account for both. Please see the How it works... section of this recipe.
To set either vSphere (PSC) or vRealize Automation (vIDM), follow these steps:
vro
) and click on Search.If you are using vRO7 with vSphere 5.5 (minimum update 2) you need to use the SSO configuration:
https://vcenter.mylab.local:7444/sso-adminserver/sdk/vsphere.local
. https://vcenter.mylab.local:7444/sts/STSService/vsphere.local
.vsphere.local
for all 5.5 systems.
vro
) and click on Search.mylab.local\vroAdmins
. SSO 5.5 has a preconfigured Orchestrator group called [email protected]
.Please note LDAP will be discontinued in further Orchestrator releases and should not be used anymore. Furthermore, using LDAP won't allow Orchestrator to use all its awesome features.
If you are using LDAP, you can choose from the In-process LDAP (ApacheDS), the built-in LDAP, Active Directory, or OpenLDAP.
Please note that LDAP entries are case sensitive. To configure Orchestrator with Active Directory, follow these steps:
389
.dc=mylab,dc=local
.Users
is not an OU but a CN, cn=vroAdmin,cn=Users,dc=mylab,dc=local
.dc=mylab,dc=local
. However, if your AD or LDAP is large, it might be better performance-wise to choose a different root.cn=vroAdmins,cn=Users,dc=mylab,dc=local
.
Configuring Orchestrator to work with an external authentication enables AD users to log in to the Orchestrator Client. The alternative would be to either have only one user using it or adding users to the embedded LDAP. However, for a production Orchestrator, the embedded LDAP solution is not viable.
PSC/vIDM/SSO is a highly integrated part of vSphere, it can proxy multiple AD and/or LDAP domains and lets you integrate Orchestrator directly into vCenter as well as other corner pieces of VMware software offerings.
If you are using vSphere or vRealize Automation authentication, you have the additional benefit of having Orchestrator automatically licensed. If you are using LDAP or SSO you have to assign a license to Orchestrator.
When using SSO or vSphere, Orchestrator will register in SSO as a Solution User with the prefix vCO.
The entry masks look the same, however, they are not. vSphere uses SSO and vRA 7 uses vIDM and those are very different beasts indeed.
When you register Orchestrator with vRealize Automation or you use the vRA embedded Orchestrator you will not be able to use a per-user session with vCenter as the SSO token and the vIDM token are incompatible at this time. I have been informed that the ability to configure the vRA embedded Orchestrator version will not be able to use PSC configuration anymore. The best way to solve this is to use a secondary Orchestrator.
With the test login, you can test if you can log on to Orchestrator using the Control Center:
If you get a reply in yellow saying Warning: The user does not have administrative rights in vRealize Orchestrator. Login to the Orchestrator client depends on the user view permissions, it means that the user has been found by Orchestrator but he is not a member of the Orchestrator admin group. See also, the recipe User management in Chapter 7, Interacting with Orchestrator.
The internal LDAP has the following preconfigured entries:
Username |
Password |
Group membership |
|
|
|
|
|
|
The LDAP installation is protected to only allow local access to it. Using the internal LDAP is not recommended at all.
Changing the Authentication Provider is quite easy. If you choose LDAP and now want to change it to something else, just select the new provider.
If you chose vSphere SSO or vRealize Automation you need to first unregister the existing Authentication Provider. To do this, follow these steps:
Recipes in Chapter 11, Additional Plugins, depict which authentication is the most preferable for the plugins discussed there.
Change the font size
Change margin width
Change background colour