No Roles Management at Administration

[itmI11]

Author : mbanov

URL : http:////docs.vmware.com/en/vRealize-Orchestrator/7.6/com.vmware.vrealize.orchestrator-using-ops-cli...

Topic Name : Assign Roles in the vRealize Orchestrator Client

Publication Name : Using the VMware vRealize Orchestrator Client

Product/Version : vRealize Orchestrator/7.6

Question :

I logt in to the vRealize Orchestrator HTML 5 Client as an administrator and I want to assign a new role. But I can't find at the administration menu the roles management. How can I find this?

[manfriday]

Unfortunately I have the same issue.

Even more unfortunately I came across this little gem:

“ Role- and group-based permissions are only available if you configure your Orchestrator instance with vRealize Automation authentication.”

https://docs.vmware.com/en/vRealize-Orchestrator/7.6/com.vmware.vrealize.orchestrator-using-ops-clie...

I am hoping that I am misunderstanding something, but it really seems like they removed the ability to manage roles in orchestrator unless you are using vRealize Automation.

[manfriday]

So, I am pretty furious. I have been speaking with a VMWare support rep about this issue and he confirmed what I thought.

VMWare has removed permissions and roles for Orchestrator UNLESS you are using vRA for authentication.

I have spent a lot of time implementing this feature that was included in the product we have purchased and paid maintenance on for YEARS.

The workflows i have created have become part of our business practices, and our OS admins have come to rely on them.

Now VMWare has removed this feature, and in order to get it back we have to spend an enormous amount of money on additional licensing and maintenance for vRA?

What are they going to do next? remove vMotion so they can sell that back to us in another product?

Sorry. I'm super ticked. All the workflows I have created for our OS admins no longer work. Thanks a lot VMWare!

[daphnissov]

Why not just roll back to vRO 7.5? What really are you gaining with 7.6 in that case?

[manfriday]

Yeah, I am going to roll back to 7.5

But thats not really a long-term solution is it?

Eventually future vCenter versions will no longer be supported by 7.5

[daphnissov]

It's probably not a long term solution, no, but you can expect 7.5 to probably work with vCenter for quite enough time. Gives you enough lead time to figure out how (or if) you can modify vRO to your needs given the removal of that feature.

[randomname]

I also noticed that in the release notes recently, installed 7.6 to check it out, and noticed that permissions management is missing from the vRO thick client. The options are simply not in the menus anymore. I've been meaning to ask our TAM about this because it just doesn't seem right. I thought I had to be misunderstanding something or missing a feature somewhere.

This leads me to believe that the effect is that it is now not possible to delegate the ability to execute vRO workflows from vCenter. As in, it is 100% impossible to grant a user read (or any other role) in vCenter, grant that user permission to a workflow, and allow that user to execute the workflow from vCenter, whether through context menu action or from the vRO plugin from the home screen. If I'm understanding things correctly and that is really what was done, then this ranks slightly below vRAM licensing as one of VMware's dumbest blunders to date. In fact, this would be so stupid that I could hardly believe such a direction would be approved for the product suite.

Please tell me I'm wrong about this. Delegating workflow execution and vRO/vCenter integration with context sensitivity has been the "killer app" for vRO since its inception. It's quite literally the only reason we use vRO. If I can't present workflows to users, what's the point of having workflows in the first place?

[manfriday]

That is exactly what it means, and is how I found out.

I had created many workflows for our OS Admins.

These OS Admins had read and execute permissions, but not Administrator rights in vRO.

I didnt read the docs adequately before upgrading, and did not notice a problem until my customers started coming to me saying their workflows were not running.

I thought maybe the upgrade had hosed the permissions on some actions the workflow called, and when I went to fix the permissions... SURPRISE!

The permissions edit tabs were gone!

It really does feel like VMWare is trying to strong-arm their customers in buying vRA.

It's not the first time they have removed a feature only to try selling it back to us in another product, but it is the first time I have personally invested a lot of time into developing processes with one of the features they have done this with, so I am more than a little annoyed.

My recommendation is to do what I have done and contact your account manager and raise holy hell.

[xian_]

I do not use standalone vRO but does this help (from the same document)?

Note:

Users from the Orchestrator identity provider with no defined roles can still log in to the client, but have limited access to client features. If they are part of a group, they can view and run content associated with that group.

The same restriction seemed to be applicable in 7.5, what is changed in 7.6?

Prerequisites

Configure a vRealize Orchestrator server with vRealize Automation authentication. For more information, see Installing and Configuring vRealize Orchestrator.

[manfriday]

For the support rep I have been in contact with:

"I finally tracked down the Project Manager for the product and they have a problem report opened with our developers for this issue: "vRO7.6 does not allow AD admins to configure ROLE/GROUP management options in html5 web client"

I am told they have looked at it and are releasing a patch that should enable groups for vSphere users"

[oendelm]

Hello,

Do you have some information about the patch?

thank you.

[manfriday]

https://upload.vmware.com/download?domain=UPLOAD&id=0ce9a64d2b4f4a5b9e4ce5547da2e5be-d4f377a1949c468...

[manfriday]

I have not tried the patch yet myself, but they claim that fixes the issue

[daphnissov]

Unless you received this from a public KB, people reading this should probably check with GSS before they go about slinging patches onto their systems, especially without any notes or guidance of any sort.

[manfriday]

daphnissov is correct. I actually regretted posting that right after I did it, but I couldn't find a way to delete it.

In any case, don't bother installing it as it does not fix the issue.

[manuelperrot]

Hello,

I received a patch from the VMware support team: VMware-vRO-Appliance-7.6.0.783-13917939-updaterepo.iso

When you are an Admin (part of the admin AD group in the VSPHERE authentication setup) you can see a new section "Groups" in the HTML5 UI under "Administrator"

This allow you to create "vRO Groups" and to assign AD Users or AD Groups + defining which Workflows this vRO group can run.

However it seems to only supports "run" role at the moment.

If you need edit, I think you must be an Admin.

Unfortunately for us this is a blocker as we have many AD groups that needs "edit" role to create workflows.

[manfriday]

They had screwed up the import of groups in the fix they sent me.

After some back and forth they fixed it in a more recent .iso.

However, after drilling into things more, it has become clear they broke much more under the hood.

They simplified the roles into "admin" and "run"

That's not enough.

I created workflows that enabled our OS admins to run workflows against the VMs under THEIR groups/folders.

The Linux guys couldn't run their workflows against the VMs in the windows folders and vice versa.

Now, with the "simplified" roles the Linux guys can see and run workflows against any VMs in the infrastructure.

That's not going to fly AT ALL.

I brought this to the developer's attention and their response was:

"The connections to >  vSphere must be configured to use session per user instead of a shared session. This means the user cannot escalate his/her permissions >  when performing vSphere operations."

That is also NOT going to fly. My workflows simply will not work anymore.

In essence, they have completely broken all of the work I put into this and rendered Orchestrator useless in our environment.

Worse, they have proven I can't trust VMWare not to take away a feature I came to rely on in order to sell it back to me in some other product.

[manfriday]

So, I had a conversation with a couple of the devs yesterday.

I'm not sure if it was fruitful or not, but they are at least now aware of how the changes they made have broken my orchestrator environment.

I asked them "What was the reason you guys removed roles from Orchestrator?"

At first, they dodged the question, but when I persisted they said "We removed roles from Orchestrator in order to add value to vRealize Automation"

In other words, they removed roles from vRO so they could sell them back to us in vRA.

[gkostova]

Hi,

The roles and permissions for vRO are two separate and different things. Roles are something totally new that we did not have in the past and in the java client, so I would not consider this as a missing feature. Roles are administrator and workflow developer and they have predefined set of permissions on what they can see and do. Admin can see all the functionalities in vRO, including administrative ones. Workflow developer can see a limited set of functionalities excluding almost all administrative ones(allowing just git history and inventory from Administration section). So, roles are the functionalities scoped limitations.

Groups functionality is the one related to permissions and content scoped and could be treated as a new permission model in the html 5 vRO client. Using groups you can create a group, to add users to it and add specific content to be visible just for the users in this group. And here comes the difference between vRA licensed and vSphere licensed vRO - vRA license allows admin to give the users in the group edit permissions to the content, vSphere license allow the admin to give just run permissions for this content in the group. This limitation came as part of License restriction limitations for vSphere licensed vRO instances we started two years ago. You can always put manually vRA license in your vSphere authenticated vRO and to get the full features set.

Regards,

Galina

[manfriday]

Oh, so it's not the roles that you took away, it's the groups. But the end result is the same.

And unless you guys are giving away free licenses of vRA, the upshot of it is that you still took away functionality that we HAD, and some of us built services around.. and are now suggesting we buy it back?