9 Replies Latest reply on Jun 17, 2013 8:19 PM by Ryan Koziel

    Sharing VGPs and VGJs between roles

      Hello - Let me start by explaining the environment and then the situation. We are on BSA 8.2 SP3 and have a vCenter server hooked up to BSA. The application servers are RHEL 5.5 with the database being SQL Server (2008 STD) on a Windows 2008 cluster. The vCenter server is 5.0 and has the latest RSCD agent installed and the latest "VMware vCenter Server" configuration objects have been pushed to it using a DCO job.


      We are able to generate virtual guest packages (VGPs) based off of a vmware template and also create and run the virtual guest job (VGJ) derived from the VGP. This works great as either a role that has the authorizations to do this or in the BLAdmins role. The VM is created as expected.


      However we would like to provide other roles access to this VGJ in order to execute it only; without allowing them to make any changes to the VGJ. In other words, one or more roles are the creator of these VGPs and VGJs with another role(s) being the consumer of them.


      Our RBAC setup is utilizing ACL policies for most everything except for the situations where a specific authorization is warranted. Each role has it's own ACL policy. The creating roles appear to be fine in terms of what authorizations are assigned: the role can create, edit, execute, etc. without issue. The consuming role in this case has the following authorizations courtesy of the role's ACL policy:

      • VirtualGuestPackage.Read
      • VirtualGuestJob.[Cancel|Execute|ModifyACL|ModifyProperties|PauseResumeExecution|Read]
      • VirtualizationConfiguration.Read


      When the consuming role attempts to execute or even open the VGJ, the error.png (attached) is received.



      The VGP and VGJ in question both have the consuming role's ACL policy applied (with the authorizations mentioned above). I even added the specific authorizations to the VGJ and VGP but that did not resolve it.


      I have ISS04102659 opened with BMC support to address, but we haven't found anything definitive yet as to what is causing it.


      Has anyone run into this before? I am wondering if it's our RBAC setup, how the VGP and VGJ are generated, or even a potential bug in BSA.


      That ticket has a bunch of information on it, for those that are able to get to that info. I attached some of the pertinent items here though.


      Additionally in working with support yesterday I was asked to take a look at the effective permissions as the consuming role. I ran into a similar, but different error, when attempting to do that. I was able to pull up the effective permissions as BLAdmin. These are attachments ISS04102659_20130408.docx and ISS04102659_20130408_stackTraces.txt.


      Thanks in advance!





      UPDATE 1:


      Using the search functionality within BSA, I happened to pull up even the hidden BLPackages behind the scenes when searching the depot for the VGP. I found the same object referenced in the error message but it's a BLPackage not a virtual guest package per what the error is stating. I went ahead and set the consuming role's ACL policy and also the specific authorizations on this hidden BLPackage but that did not resolve the issue either.



        • 1. Re: Sharing VGPs and VGJs between roles
          Bill Robinson

          I believe you need to setup an ACL Template that includes the ACL Policy you want to apply, and then make this ACL Template the Default Object Permission Template for the role creating the objects.

          • 2. Re: Sharing VGPs and VGJs between roles

            That is what we are doing, except that each role has it's own ACL template used as the default object permissions template. The contents of this ACL template are the role's ACL policy and BLAdmin's ACL policy. Since our environment is very fluid, with objects being created and shared between multiple varying teams, we opted to not include any other role's ACL policy in the creating role's default object permissions template. All permissions on objects generated are set after-the-fact manually using either the ACL policy or specific authorizations (depending upon the situation).


            In situations where we do have a 1:1 relationship between a role creating the objects and a role consuming them, we would do as you suggest. However, 1:1 situations like that are an edge case in our environment.


            I am going to try your suggestion though to see if that resolves the issue.

            • 3. Re: Sharing VGPs and VGJs between roles
              Bill Robinson

              the only other option is that when you create the new objects, you can manually set the object permissions.


              if you don't know what roles need access to the object during object creation, i'm not sure how you can automate applying permissions.  how do you determine who gets access to the objects ?

              • 4. Re: Sharing VGPs and VGJs between roles

                Exactly Bill. When the role creates the objects they should set the proper permissions at that time manually. That process works just fine for every object we have dealt with thus far. However that process does not work when it comes to virtual guest jobs, which is what the issue, and this post, is about.


                To answer your question: when an object is created we do know at that time who (what role) needs access to it. The situation though is that some roles generate objects for many other roles. So we opted to not add the proper ACLs to the creating role's default ACL template in favor of the permissions being set manually.

                • 5. Re: Sharing VGPs and VGJs between roles
                  Bill Robinson

                  but you're saying this is a process issue - if you set the proper permissions during the object creation, that techincally works in bsa ?


                  how do you know what roles will need access to right package ?

                  • 6. Re: Sharing VGPs and VGJs between roles

                    I just got done running a series of 6 tests, with the first 5 unsuccessful with the same error (different pkg/job names) as this discussion here and the support incident. The first 5 tests were all done with the creating role's object permissions template containing the consuming role's ACL policy (which contains the auth profiles/auths for virtualization & server among others). The permissions available to the consuming role, in terms of what it can do with virtualization, incremented closer to the creating role's settings each test. If you can read my scratch it's attached (testNotes.20130416.txt).


                    We do know what role(s) will need access to which pkgs/jobs. But, things change and a pkg/job may need to go to another role later or a role may need to share a pkg/job. I hope I'm answering your question...?


                    I'll have more information on the support incident tomorrow morning.


                    Thanks Bill.

                    • 7. Re: Sharing VGPs and VGJs between roles
                      Bill Robinson

                      did we get this sorted out on the webex or is this still an issue ?

                      • 8. Re: Sharing VGPs and VGJs between roles
                        Jim Wilson

                        Hi Ryan NameToUpdate


                        Did this get resolved?

                        If so, please can you update the discussion thread with details so that is can be marked as answered.


                        Thanks & Regards,

                        Jim (Forum Manager/Facilitator)

                        • 9. Re: Sharing VGPs and VGJs between roles

                          Bill/Jim - Yes, our situation was resolved. Apologies for the late response.


                          The workaround consisted of using specific authorizations rather than ACL policies for applying the correct authorizations during object creation (via default object permissions template using ACL policies) with virtual guest packages and jobs. This was on the "creating" role's default object permissions template, containing the authorizations for the "consuming" role.