darrenoid
Enthusiast
Enthusiast

How to allow access to business group items without service entitlement

Jump to solution

Hello vRealize Community,

I am having a little trouble wrapping my head around the entitlements, services and business groups. We are trying to figure out a way to provision items into a business group, without allowing the business group users the ability to see or request the catalog item. The use case is for our lab team to be able to provision certain custom blueprints from the catalog that will end up in a business group that the main users are entitled to. However, we don't want the main users to be able to provision those custom blueprints or even see them in the catalog.

If I remove their entitlement, then they cannot manage the item in vRA.

Regards,

Darrenoid

0 Kudos
1 Solution

Accepted Solutions
SeanKohler
Expert
Expert

I might differ from the last response a bit...

"From what I am understanding, in order for a user to manage an item, they have to have an entitlement to it. If they have an entitlement to it, then they can also see it and request it from the catalog."

This isn't entirely correct.

BG Makeup

Users - Can see their own Resource Items

Support Users - Can see all Resource items

Managers - Can see all resource items.. an be used for filters, approvals, etc.  (to be honest, we don't use this BG role at all... we get better results through programmatic practices)

-- ALL OF THESE USERS CAN OWN A RESOURCE  (important to keep this in mind)

Entitlements come in 2 +1 varieties.  I say that very specifically due to a Support Checkbox I asked (downright pleaded) to be added when they changed the behavior of the entitlements to mirror 5.x capability  (which granted entitlements specifically to the Blueprint)

So what do I mean by 2?  There are two capabilities provided by entitlements:

1. Ability to Request something as a thing (through either pre-arranged service or direct catalog item)

2. Ability to request a change to a thing (day 2 resource action)

Why +1? For Resource Actions, you can decide "Actions only apply to items defined in this entitlement".

This is checked by default and does exactly as it says.  (it aligns with your current understanding)

But when it is unchecked, that grants us the ability to have a "Support User" (who can see all machines due to BG makeup) with the ability to run all assigned resource actions against any applicable resource in the business group.  (think of machines as resources) It also gives us the ability to have users who can request a resource action on an item that they didn't build or have access to build.  (hopefully you are starting to see the benefit to this checkbox)

----------------------------

More prescriptive of what you are looking to do.

Entitlement 1

Your "Lab Team" is a support user role in any business group.  They need to see the catalog items to request (sort of, I think I have a better way for you using a BG Properties & Machine Owner input field and post machine provision event moves) and they need to be able to manage all day 2 activities.  They get a dedicated entitlement per business group that defines the services of catalog items they can request from and the machines that are provisioned can be worked on.  You can choose to check or uncheck the +1 box.  (but you would want to uncheck it if you follow a build-then-move strategy.

Entitlement 2

Strategically, you need to decide a couple more things.

1. Can users see all machine resources in their business group?  Then they are Support User role. If they can see all resources, can they perform resource actions on all they can see?

2. Can users only see their own machine resouces in the business group? Then they are User role. And resource ownership becomes an important priority.  (you have to make sure the machine gets owned by the individual post-build)

In both cases:  To grant these users the ability to perform resource actions, you would create an entitlement that only has Resource Actions in them and UNCHECK the +1 box defined above.  If the answer to the second question in number 1 is "NO", then there are further practices we need to take... but it is still doable.

-------------------------

Side note - because sometimes it helps to see how others are doing things:

We have a somewhat complicated strategy that supports both self-service for technical evaluation and Engineering builds to same business group(s).

1. The Base users have machines they can request, see their own, and run resource actions on their own.  They have the traditional entitlement: Catalog items tied to resource actions via checkbox. The Engineers can run resource actions on those machines, but cannot request those machines in the customer business group.

2. The Engineers can request machines in their business group assigned to a service for global builds.  These machines requests have properties that determine what destination business group the machine belongs to, and an event subscription moves the machine.  The owner can also be changed, but by default a service account owns the machine in the destination.

3. A central vRA service account can OWN machines that Engineers build for a business group.  This means that the service account has an entitlement of resource actions against machines so we can make programmatic changes from vRO.  Since the service account owns the machine(s), users cannot see them.  (and their entitlement doesn't grant them access anyway)  Engineers can see the machines and run the resource actions due to their entitlement. (but they cannot request them)

4. We then have a set of OpsBridge support users who have the Support User role in all business groups and an entitlement that consists of ONLY resource actions (and the checkbox unchecked).  They can do support related practices against the machines in the business group.

We achieve these practices through custom built entitlements management that is built based off of vRO workflows tied to vRO element Attribute arrays that hold the services, catalog items, and resource actions that belong to specific entitlements for the business group. Change the values in the array... change the values in the entitlements across the board (or individually through snowflake exclusion).

This is how we came up with a way to manage 7 mostly-uniform entitlements across 80+ business groups.

View solution in original post

0 Kudos
7 Replies
nikolayn
VMware Employee
VMware Employee

How about you just create a new business group with the lab team only and then create a new entitlement with the blueprints in question?

0 Kudos
darrenoid
Enthusiast
Enthusiast

Hello Nikolayn,

That would give me a single business group to deploy things into for the lab team only. Sorry if I did not explain my question very well. I am trying to find a way that the main business group users can see their items and have entitlements to them, without being able to see them in the catalog or request them. From what I am understanding, in order for a user to manage an item, they have to have an entitlement to it. If they have an entitlement to it, then they can also see it and request it from the catalog.

Lab Team will see the catalog items and request them. The items will be deployed to the main business group. End users in the main business group can manage the items, but they cannot see them or request them from the catalog.

Thanks,

Darren

0 Kudos
nikolayn
VMware Employee
VMware Employee

Okay, I think I get what you mean. You want only a specific AD group that's a member of the Business Group to request items, but another AD group with ordinary users can only manage provisioned items?

Then, what you should do is set the Lab team as Bussiness Group Managers, and also on the Entitlement configuration page, instead of clicking "All users and groups" specify only the lab team group. And assign the lab team group Day-2 actions, so they can change the ownership to the End users. After they change the ownership, specific end users can manage the item.

0 Kudos
darrenoid
Enthusiast
Enthusiast

on the Entitlement configuration page, instead of clicking "All users and groups" specify only the lab team group

This is the problem for me. If I do not put the main end users in the entitlement, they will not be able to manage the VMs. The entitlement assigns permissions for the actions power on, power off, etc. If they are not in there, they can see the VM, but they have no actions to use. I guess there is no separation between provisioning actions and day 2 actions. The best I can come up with is to set the catalog item as "inactive" until I want to provision from it, and then quickly enable the catalog item, request the item, and then set it to inactive again.

~ Darrenoid

0 Kudos
SeanKohler
Expert
Expert

I might differ from the last response a bit...

"From what I am understanding, in order for a user to manage an item, they have to have an entitlement to it. If they have an entitlement to it, then they can also see it and request it from the catalog."

This isn't entirely correct.

BG Makeup

Users - Can see their own Resource Items

Support Users - Can see all Resource items

Managers - Can see all resource items.. an be used for filters, approvals, etc.  (to be honest, we don't use this BG role at all... we get better results through programmatic practices)

-- ALL OF THESE USERS CAN OWN A RESOURCE  (important to keep this in mind)

Entitlements come in 2 +1 varieties.  I say that very specifically due to a Support Checkbox I asked (downright pleaded) to be added when they changed the behavior of the entitlements to mirror 5.x capability  (which granted entitlements specifically to the Blueprint)

So what do I mean by 2?  There are two capabilities provided by entitlements:

1. Ability to Request something as a thing (through either pre-arranged service or direct catalog item)

2. Ability to request a change to a thing (day 2 resource action)

Why +1? For Resource Actions, you can decide "Actions only apply to items defined in this entitlement".

This is checked by default and does exactly as it says.  (it aligns with your current understanding)

But when it is unchecked, that grants us the ability to have a "Support User" (who can see all machines due to BG makeup) with the ability to run all assigned resource actions against any applicable resource in the business group.  (think of machines as resources) It also gives us the ability to have users who can request a resource action on an item that they didn't build or have access to build.  (hopefully you are starting to see the benefit to this checkbox)

----------------------------

More prescriptive of what you are looking to do.

Entitlement 1

Your "Lab Team" is a support user role in any business group.  They need to see the catalog items to request (sort of, I think I have a better way for you using a BG Properties & Machine Owner input field and post machine provision event moves) and they need to be able to manage all day 2 activities.  They get a dedicated entitlement per business group that defines the services of catalog items they can request from and the machines that are provisioned can be worked on.  You can choose to check or uncheck the +1 box.  (but you would want to uncheck it if you follow a build-then-move strategy.

Entitlement 2

Strategically, you need to decide a couple more things.

1. Can users see all machine resources in their business group?  Then they are Support User role. If they can see all resources, can they perform resource actions on all they can see?

2. Can users only see their own machine resouces in the business group? Then they are User role. And resource ownership becomes an important priority.  (you have to make sure the machine gets owned by the individual post-build)

In both cases:  To grant these users the ability to perform resource actions, you would create an entitlement that only has Resource Actions in them and UNCHECK the +1 box defined above.  If the answer to the second question in number 1 is "NO", then there are further practices we need to take... but it is still doable.

-------------------------

Side note - because sometimes it helps to see how others are doing things:

We have a somewhat complicated strategy that supports both self-service for technical evaluation and Engineering builds to same business group(s).

1. The Base users have machines they can request, see their own, and run resource actions on their own.  They have the traditional entitlement: Catalog items tied to resource actions via checkbox. The Engineers can run resource actions on those machines, but cannot request those machines in the customer business group.

2. The Engineers can request machines in their business group assigned to a service for global builds.  These machines requests have properties that determine what destination business group the machine belongs to, and an event subscription moves the machine.  The owner can also be changed, but by default a service account owns the machine in the destination.

3. A central vRA service account can OWN machines that Engineers build for a business group.  This means that the service account has an entitlement of resource actions against machines so we can make programmatic changes from vRO.  Since the service account owns the machine(s), users cannot see them.  (and their entitlement doesn't grant them access anyway)  Engineers can see the machines and run the resource actions due to their entitlement. (but they cannot request them)

4. We then have a set of OpsBridge support users who have the Support User role in all business groups and an entitlement that consists of ONLY resource actions (and the checkbox unchecked).  They can do support related practices against the machines in the business group.

We achieve these practices through custom built entitlements management that is built based off of vRO workflows tied to vRO element Attribute arrays that hold the services, catalog items, and resource actions that belong to specific entitlements for the business group. Change the values in the array... change the values in the entitlements across the board (or individually through snowflake exclusion).

This is how we came up with a way to manage 7 mostly-uniform entitlements across 80+ business groups.

View solution in original post

0 Kudos
darrenoid
Enthusiast
Enthusiast

Thanks SeanKohler!

That totally worked. This is what I was missing:

To grant these users the ability to perform resource actions, you would create an entitlement that only has Resource Actions in them and UNCHECK the +1 box defined above.

Now I have 2 entitlements, one with all resource actions and the catalog service (with the checkbox checked) for the lab team. Then I have a second entitlement for the general end users with resource actions only (the checkbox unchecked). Now my Lab Team user can request the item from the catalog on behalf of the end user, and when it is done the end user can manage all the day 2 actions. The end users, however, cannot see the catalog item or request it themselves. They cannot even see the service.

Regards,

Darrenoid

0 Kudos
SeanKohler
Expert
Expert

Groovy man.  Glad it worked out for you!

0 Kudos