In this recipe, we will see how to control access to Orchestrator. You will learn how to give and control access to users outside the Orchestrator administrator group.
We need a running Orchestrator configured either with vSphere / vRA authentication or AD. Check the recipe Configuring an external Authentication in Chapter 1, Installing and Configuring Orchestrator.
Also, we need either access to a user management system (LDAP, SSO, or AD) or to have other users and groups on a given user management system. If you are using the Orchestrator appliance without any external authentication you can use the local LDAP user vcoadmin
and vrouser
which are set out in the recipe Configuring an external Authentication in
Chapter 1, Installing and Configuring Orchestrator.
We have three parts to this recipe, each for different tasks.
Giving restricted access to users is better than just adding everyone to the Orchestrator administrative group. Please note that you can only add LDAP/AD groups. To grant non-administrative access to Orchestrator, follow these steps:
After we are granted non-administrator access to Orchestrator, we can now modify the user rights of other Orchestrator elements:
As Orchestrator administrators have access to all Orchestrator elements as well as having all user rights (including delete), you might want to restrict the access that users have.
The best thing is to create a dedicated Orchestrator administrator group in AD and configure this group as the Orchestrator admin group in the External Authentication in Control Center. See Configuring an external Authentication in Chapter 1, Installing and Configuring Orchestrator, and add one or more user groups for Orchestrator non-administrative access (such as vRO-test and vRO-production) to your AD and then to Orchestrator. This will result in a user structure you can manage through AD instead of Orchestrator.
The user management in Orchestrator can be a bit tricky. Here are some of the more common problems.
If you have a user that is a member of the user group as well as a member of the admin group, then the user will have the rights of the admin group.
The highest right will be used.
Well...you can't. The only thing you can do is delete the right and then add it again.
The user rights that are given to one Orchestrator element will automatically be inherited by all its child elements. You cannot break the inheritance. However, you can extend or restrict the rights. Because of this, it is prudent to give only View rights to a group on the My Orchestrator level and extend the rights as needed in the child elements.
To extend or restrict the rights of a user group, just add the same user group to the element again and adjust the rights as required. Have a look at the following screenshot. You find the inherit right (Parent) and the current right for this element (This object) there. The right of the This object element will always overwrite the inheritance. Please note that when you expand or restrict the user rights, all children will again inherit this setting:
This is a very typical problem. Let's assume you have a workflow called mainWorkflow that calls the workflow subWorkflow. The user has execute rights for mainWorkflow but not for subWorkflow. The result would be that the mainWorkflow can't be executed by this user.
The only way around that is to use the Switch Credentials workflow element we discussed in the recipe Changing credentials during runtime in Chapter 5, Visual Programming.
Have a look at the following screenshot. You will notice that we have two Administrator groups. One is from mylab.local
and the other one from vsphere.local
; however, you can't distinguish between them. The only thing we can do here is to use user/group names that are more descriptive:
The following are the existing Orchestrator user rights:
User right |
Description |
View |
Base access to Orchestrator Client and view elements but not their schema, presentation, script, and parameter references. |
Inspect |
View schema, presentation, script, and parameter references in elements. |
Execute |
Able to run a workflow. If this right is not given, every user can still use the Run As feature by right-clicking on it. This right also allows you to answer a user interaction. |
Edit |
Able to edit elements. |
Admin |
Able to set permissions on elements. |
Here are some more notes of interest.
To log into Orchestrator, you can use one of the following syntaxes:
Username
(only if you are using vSphere or vRA setup)username@FQDN-Domain
Domainusername
This is a list of the most typical login error messages:
If you want to turn off the possibility of any non-administrative access to Orchestrator, have a look at the section System Properties in the recipe Control Center Titbits in Chapter 2, Optimizing Orchestrator Configuration.