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:
- Log in to Orchestrator Client as an Orchestrator administrator.
- The MyOrchestrator (the house symbol) page opens up by default. Select the Run mode if not already selected.
- Click on the Permissions tab.
- Click on Add access right (the group with a green plus).
- Select the correct Domain from the drop-down menu.
- In the Search field, either just press Enter to see all existing groups or enter a string to filter for groups and press Enter.
- Select the group you want to add.
- Select the rights you want this group to have (View is the lowest-needed right).
- Click on Select.
- Log in to Orchestrator Client with a user that is a member of the user group you added in step 6.
- You are now logged in as a non-administrative user.
After we are granted non-administrator access to Orchestrator, we can now modify the user rights of other Orchestrator elements:
- Log in to Orchestrator Client as an Orchestrator administrator.
- Select an element (for example, a workflow or folder).
- Click on Edit (the pencil symbol).
- Click on Permissions and then on Add access right (the group with a green plus).
- In the Filter field, either just press Enter to see all existing groups or enter a string to filter for groups and press Enter.
- Select the group you want to add.
- Select the rights you want this group to have (View is the lowest-needed right).
- Click on Select.
- Click on Save and Close.
- Log in and test.
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-DomainDomainusername
This is a list of the most typical login error messages:
- Node not Active: This could mean that Orchestrator isn't fully up yet, or that the connection from Orchestrator to the external Authentication isn't up yet. Waiting or restarting the Orchestrator service helps.
- [002] User [username] is not authorized: Here, the user is not a member of the Orchestrator administrator group or doesn't have the View right in My Orchestrator.
- Smart client connection is disabled by server security: Here, non-administrative access to Orchestrator has been disabled.
- Invalid user/password: This is one of those error messages that can mean a lot, starting with the obvious typo in the username or password to the fact that the user doesn't exist. A typical problem here is that a user exists and has access rights to Orchestrator. In this case, this message means that the user management system can't find him, indicating that something in the external Authentication is not working correctly.
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.